Why can't a concrete subclass use size and validator functions on abstract superclass properties?

Hello all,

I will throw together a little example here; lets create an abstract super class (containing mixed abstract and concrete properties),

classdef (Abstract) abstractSuper
   properties
       conc (:,1) = zeros(10,1)
   end
   
   properties (Abstract)
      abst  
   end
end

where conc is a concrete property initially set for all sub-classes, and I have some abstract property that may have abstract methods associated with it.

Now I create a concrete sub-class.

classdef concreteSub < abstractSuper
   properties 
       abst (1,3) char = 'tst';    
   end     
end

where I want to enforce the property abst as being a 1x3 char vector. Unfortunately, trying to instantiate a concreteSubObj returns

"Error using concreteSub

Size and validator functions not supported for properties defined as abstract in superclasses. Property 'abst' is defined as abstract property in

superclass 'abstractSuper'."

Question

I understand that I cannot use the size/validator in my concrete class, since I defined it as abstract in my super. I do not understand why, since I thought that the point of abstraction was to define an interface, while leaving complete freedom to the concrete subclasses. I also cannot partially define abst in abstractSuper and override it in concreteSub, (e.g. define it in the super, and then add the size/validator function to the sub-class).

I had hoped to do something like force the property to be a character vector in the super, and then be 3 chars long in the sub, but that is even further beyond where I am stuck in this example.

TLDR: Why does defining an abstract property in a superclass prevent me from using size/validator functions in the concrete sub-class?

Answer 1

[per isakson]

The R2019b doc on Validate Property Values says

[...]

Abstract Property Validation

You can define property validation for abstract properties. The validation applies to all subclasses that implement the property. However, subclasses cannot use any validation on their implementation of the property. When inheriting validation for a property from multiple classes, only a single Abstract property in one superclass can define the validation. None of the superclasses can define the property as nonAbstract.

Try this

>> cs = concreteSub
cs = 
  concreteSub with properties:
    abst: 'tst'
    conc: [10×1 double]

where

classdef (Abstract) abstractSuper
   properties
       conc (:,1) = zeros(10,1)
   end
   properties (Abstract)
      abst (1,3) char
   end
end

classdef concreteSub < abstractSuper
   properties 
       abst = 'tst';    
   end     
end

[Thomas Michiels]

This DOES NOT answer the question. the OP clearly states that he knows he cannot do the described situation, meaning he most likely knows this solution. He asks for a reason why this is designed the way it is, as it is contradictory in nature and thus near impossible to use decently.

ALSO the given solution does not work, which is clearly a bug given your documentation link. I have put a validation on a property of my abstract class (checks mustBaA(prop,'myclass')) and when i don't satisfy that condition, it just passes anyways.

[per isakson]

@Thomas Michiels

"This DOES NOT answer the question" Answers are not exclusively for the OP.

"asks for a reason why this is designed the way" The MathWorks rarely justifies design decisions in public.

"[...] is clearly a bug" I fail to reproduce the bug you report. I've added the line

color {mustBeMember( color, {'yellow','green','blue'} )}

to abstractSuper and run this script

%%
cs = concreteSub;
%%
cs.color = 'red';

Error setting property 'color' of class 'abstractSuper'. Value must be a member of this set:
'yellow'
'green'
'blue'

%%
cs.abst  = '12345'; % this statement isn't executed, since the previous errors

I get the same result here and on R2018b.

[per isakson]

Ok, R2018b doesn't have mustBeA

Now, I've added the line

prop {mustBeA( prop, 'MyClass' )}

to abstractSuper and run

%%
cs = concreteSub;
%%
cs.prop

ans = 
  MyClass with properties:

    A: 1
    B: 2

cs.prop = MyClass(3,4);
cs.prop

ans = 
  MyClass with properties:

    A: 3
    B: 4

%%
cs.prop = table(5,6);

Error setting property 'prop' of class 'abstractSuper'. Value must be one of the following types: 'MyClass'.

Isn't this the expected behavior?

Answer 2

[Nikolaus Koopmann]

i have the same question

Answer 3

[Sören Kohnert]

You can use a set method in comination with assert() in your subclass to define different validators for each subclass.

classdef (Abstract) abstractSuper
   properties (Abstract)
      abst  
   end
end

classdef concreteSub < abstractSuper
   properties 
       abst   
   end 
   methods
       function obj = set.abst(obj,value)
           assert(ischar(value) && all(size(value) == [1,3]))
           obj.abst = value;
       end
       
   end
end

[Nikolaus Koopmann]

or like

classdef concreteSub < abstractSuper
   properties 
       abst   
   end 
   methods
       function obj = set.abst(obj,value)
           validateattributes(value,{'char'},{'size',[1 3]});
           obj.abst = value;
       end
       
   end
end

[Thomas Michiels]

both very good solutions, but OP asks for a design reason, not a workaround

Answer 4

[Marco Schmid]

I want to use class validation in my subclass for a abastract property.

The Workaround is not a solution because I want to use the autocomplete in my subclass for the property.

When will you offer a solution for this?

Answer 5

[Jan Kappen]

Same question here. Is this something being subject to change or is it fixed?

Background of this question is not about validation functions but overloading or making the type more concrete in the subclass.