seems like a handle class nesting bug

classdef IqReader < handle

properties

fid=0

end

...

end

classdef InReader < handle

properties

reader=IqFileReader()

end

...

end

classdef T1Reader < InReader

...

end

classdef T2Reader < InReader

...

end

t1=T1Reader();

t2=T2Reader();

assert(t1.reader ~= t2.reader);

In the example above (when split into files as matlab requires), t1 and t2 get the same handle class object as a reader. e.g. changing t1.reader.fid changes t2.reader.fid

This does not seem right to me.

[Stuart MacGregor]

cut and paste bug in example: first class should be IqFileReader

[Image Analyst]

Then edit it to correct the first post rather than post the correction as a comment.

Answer 1

[Steven Lord]

Not a bug. See the "Handle Objects as Default Property Values" section on this documentation page for an expanation and an alternate approach to give each instance of the class a separate handle object as its property.

[Stuart MacGregor]

The doc is unclear re my example however. It says different instances get the same handle-derived property: ok, but my example did not have different instances of the same class, it had two different derived classes, each with a single instance.

This is not good, and not documented. Call it an undocumented feature rather than a bug possibly.

[Stuart MacGregor]

However, it does seem good practice to initialise handle derived properties in the constructor - the behaviour if you don't is very unlikely to be desired, or expected.