- 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.
- 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.
- 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.
why can we not modify inherited properties
19 ビュー (過去 30 日間)
古いコメントを表示
I do not understand the design filosofy behind not allowing to redefine properties when inheriting from a parent class.
this has 2 main arguments:
- 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.
- 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?
0 件のコメント
採用された回答
Matt J
2021 年 11 月 17 日
編集済み: Matt J
2021 年 11 月 17 日
Well, I'm not a Mathworks developer, but here are my thoughts:
3 件のコメント
Matt J
2021 年 11 月 17 日
編集済み: Matt J
2021 年 11 月 17 日
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
その他の回答 (0 件)
参考
カテゴリ
Help Center および File Exchange で Construct and Work with Object Arrays についてさらに検索
Community Treasure Hunt
Find the treasures in MATLAB Central and discover how the community can help you!
Start Hunting!