I assume your alternative with specific get methods is something like this:

classdef superClass
properties (Access=private)
state_data
end
properties (Dependent)
state
end
methods
function tf = get.state(obj)
tf = getState(obj);
end
end
methods(Access=protected)
function getState(obj)
tf = strcmp(obj.state_data, ‘Happy’);
end
end
end
classdef subClass < superClass
methods(Access=protected)
function tf = getState(obj)
tf = strcmp(obj.state_data, 'Sad');
end
end
end

I do see your point about not “making it hard” and I agree we could make improvements. Sometimes enforcing rules makes some things easier but we want to do it in a way that doesn’t make other things harder. For example, if a superclass can guarantee what kinds of values may be returned by that property, it is easier to write general-purpose functions that use the superclass without knowing about all possible subclasses. If changing a property to Dependendent and adding a get-function doesn’t open up the property to reimplementation in subclasses, there is one less consideration for the superclass author making this change.

classdef superClass
properties (Access=private)
state_data
end
properties (Dependent=true)
state
end
methods
function tf = get.state(obj)
tf = strcmp(obj.state_data, ‘Happy’);
end
end
end

classdef subClass < superClass
methods
function tf = get.state(obj)
tf = strcmp(obj.state_data, 'Sad');
end
end
end

(sorry not really performance related)

To work around and get the type of behaviour I want means I have to write specific get methods. Yes I know there is risk in overriding set methods, but leave it to the programmer to Do It Right, rather than enforce rules that Make It Hard

I agree with the idea that the OO group needs a blog!

I should clarify the statement about obj.f(data) being slower than f(obj, data). The overhead is higher for obj.f(data) but this will generally not be noticeable if the function execution time is significant so I can’t say that you will notice a difference for any particular function. The overhead is higher because of the way MATLAB currently interprets syntax involving dots.

Also, I tried testing this:

f(obj, data) is generally faster than using obj.f(data)

But saw no difference in my test. Why is it supposed to be faster, should I be using f(obj, data) as best practice irrespectively?

I’m curious about the order-of-magnitude difference between the performance of the SimpleCylinder and NewCylinder examples:

SimpleCylinder (loop outside) : 0.112309 seconds.
SlowCylinder (custom set/get): 0.174094 seconds.
NewCylinder (loop inside constructor): 0.006654 seconds.

I would have expected the SimpleCylinder time to be closer to the NewCylinder time. I assume the discrepancy is because the SimpleCylinder loop goes from 1:1000, whereas the NewCylinder loop goes from numel(R):-1:1? (in the former case, the array size grows continually, whereas in the latter case it is effectively preallocated?)

Thanks,
Gautam

Secondly, a good design requires avoiding problems, including use of try/catch/finally statements. I have seen just a few examples. Please point me to other examples or tutorials, especially for the Matlab specific error messages that are available.

Thanks in advance.