why can we not modify inherited properties

I do not understand the design filosofy behind not allowing to redefine properties when inheriting from a parent class.

this has 2 main arguments:

1. 1when subclassing, you might want to change default values, or access level, as the inheritted class is a specialisation and might handle more concerns than the parent class. the latter is currently impossible while the former would require you to overwrite the default values in the constructor of the object. If this is the intended usecase for default values, setting those default values in the initial class should be blocked, as we now have 2 places to do exactly the same. Conclusion, changing default values for properties should be possible in subclasses.
2. with the current situation, it is impossible to change a constant property in a subclass, while there might be cases where you don't want a property to change, but it might be different in a different subclass. As it is impossible to look into to future and predict what kind of subclasses might be made based on your class, these restrictions are limitting harsher than what i suspect is intended from a design perspective.

now my question:

can you explain to my why this was implemented (a.k.a. why i shouldn't do what i'm trying to do) in this way, and if there is a future where this might be allowed to change?

Answer 1

[Matt J]

Well, I'm not a Mathworks developer, but here are my thoughts:

1. Regarding default values, I believe they must be non-overridable because the super-class constructor is always called before the sub-class constructor is allowed to modify the object. The super-class constructor may depend critically on the original default values to function.
2. Regarding access levels, a 'private' access designation in the super class specifically means that the developer doesn't want sub-classes to have access to that property. If you allowed a sub-class to unlock access to the property in its own classdef, the notion of 'private' access would be nullified.
3. It is not immediately clear why you would want to redefine a Constant property. If you wanted it to be changeable, why make it Constant in the first place? Note also that a constant property is not supposed to require an object instance to access it. You access it by typing 'superclassName.propName'. If you're saying you also want to be able to type 'subclassName.propName' and obtain a different value, it is not clear why it is useful to give these properties the same name propName. Accessing the property would still require typing something partially different.

[Thomas Michiels]

hey Matt,

about 2. It indeed does not make sense to broaden a property, access method, but in many cases it does make sense to restrict it further. having no access to it, also means no access to the redefine options. This is usefull in the case where a subclass takes ownership of more subjects than the superclass by specialising it.

The reason for the property to be constant is because it should never change. This does not mean, that it cannot be a different value to begin with if a subclass whiches to change it. I know you can access them without instantiating an object form the class, that is the intention. I want all the instances to have the same value. But i also would like to have a subclass that has that variable set to something different.

If i wanted a constant value that couldn't be changed by a subclass, i would make it private, but it's not private. The fact that a construct MIGHT depend on it, is not a good reason to block it globally, as you should then block subclassing in general, becease every getter/setter/method might rely on some conditions. Blocking something because it might be used by poorly designed code, is not a real argument, it would be an argument if it wouldn't be usefull in good designed code, but that isn't the case here.

[Matt J]

is not a good reason to block it globally, as you should then block subclassing in general, becease every getter/setter/method might rely on some conditions

Note that Matlab does not let you overload set.property() and get.property() methods for this very reason.

In any case, a workaround would be to use Dependent properties,

classdef myclass
 properties (Dependent)
  prop   
 end

 methods
     function val=get.prop(obj)
         val=get_prop(obj);
     end
     function val=get_prop(obj)
         val=6;
     end     
 end
 
end

Then, in the subclass, you could just overload get_prop() either to return a different value or forbid access.

classdef mysubclass < myclass
  methods
     function val=get_prop(obj)
         val=5;
         % error ('Access forbidden');  %alternative behavior    
     end     
  end
 end
    
end

[Thomas Michiels]

I don't agree with matlab design choices here, but this is the correct answer, so i will accept this as the solution, thank you very much.