Why does subclassing a numeric type break its use as a property of a custom class?

I’m seeing some odd behavior while trying to use a subclassed numeric type in a custom class I’m creating. Within the custom class, if I specify a property as a vector of type double, I can specify a default value as a scalar and everything works as expected (it fills the vector with copies of the scalar value if I don’t provide an input). But as soon as I change the type to a subclass of double, such as the ExtendDouble example given in the documentation here, I can no longer use a scalar as the default value, even though the error message itself says I should be able to:

>> testClass([1;2;3])
Error setting default value of property 'param1' of class 'testClass':
Size of default value must match specified dimensions 3×1 or be scalar.

So I have two questions:

1. Why does my code work for double but not ExtendDouble?

2. Why is it even trying to use the default value at all, when I’ve explicitly provided the value as an input argument to the constructor?

My custom class code is as follows:

classdef testClass
    properties
        param1(3,1)  ExtendDouble = 0
    end
    
    methods
        function self = testClass(param1)
            if nargin > 0
                self.param1 = param1;
            end
        end
    end
end

Answer 1

[Matt J]

1. Why does my code work for double but not ExtendDouble?

The ExtendDouble example is old. It's subsasgn() method was not written to properly handle the newer property initialization features. The following modification will fix the issue.

           case '()'
               newd = subsasgn(double(obj),s(1),double(b));
               if isa(b,'ExtendDouble'), 
                 obj = ExtendDouble(newd,b.DataString);
               elseif isa(obj,'ExtendDouble')
                 obj= ExtendDouble(newd,obj.DataString);
               end

2. Why is it even trying to use the default value at all, when I’ve explicitly provided the value as an input argument to the constructor?

Constructor functions have special behavior. Within them, an initial version of the output object "self" gets created with default values as soon as the constructor workspace is entered. Therefore, anything you do to self in the body of the testClass() constructor is simply modifying that initial object. It doesn't create it from scratch.

As a simple way to see this, you can test the following simpler class,

  classdef myclass
    
    methods
        function self = myclass()
            disp ' '
            whos
        end

        
    end
end

Running the constructor shows that self has been created in its workspace, even though I did nothing to put it there:

>> obj=myclass;
 
  Name      Size            Bytes  Class      Attributes

  self      1x1                 0  myclass         

[David Sempsrott]

Brilliant! Your modification to subsasgn() did indeed fix the issue. Many thanks. Appreciate the background explanations on the constructor behavior as well; however, this behavior only seems to apply to an original class (not a subclass of double). If you put a breakpoint at the first line inside the constructor of ExtendDouble and try to instantiate the object, typing whos at the command line will show nothing. I’m not 100% sure where this difference in behavior is coming from, but I suspect it’s that the subclass object is waiting to be initialized until the superclass object is instantiated.

[Matt J]

If you put a breakpoint at the first line inside the constructor of ExtendDouble and try to instantiate the object, typing whos at the command line will show nothing

That is strange indeed. However, the object must be there, because within the constructor,

     function obj = ExtendDouble(data,str)
         if nargin == 0
            data = 0;
            str = '';
         elseif nargin == 1
            str = '';
         end
         obj = obj@double(data);
         obj.DataString = str;
      end

the first appearance of obj is on the right hand side of the line,

obj = obj@double(data);

Matlab would not be able to understand a variable referenced on the right hand side of a statement if the variable did not already exist.

[David Sempsrott]

Normally that’s true, but in the particular case of a call to the superclass constructor I’m not sure the normal logic about the right-hand side of a statement still applies. In this case I think obj@double is simply special notation for calling the superclass constructor to construct the precursor to obj, not trying to reference the “current value” of obj like a normal RHS would. See documention here. As for the left-hand side of that statement, I don’t think it’s even needed; you can omit it and the object is still constructed as expected.

[David Sempsrott]

OK so I just found something interesting. If you provide an input argument to the subclass constructor, the superclass (double) object will be constructed before entering the subclass constructor and will be visible in the subclass constructor workspace. If you don’t, it will just use the default superclass value (0) but will not create a variable for it in the subclass workspace. I tell you what, these class hierarchy interactions in MATLAB seem like a bunch of smoke and mirrors.

[Matt J]

If you provide an input argument to the subclass constructor, the superclass (double) object will be constructed before entering the subclass constructor and will be visible in the subclass constructor workspace.

I'm not seeing that. ExtendedDouble is itself an example of a subclass constructor that takes input arguments and we've already established that the object is not visible.

[David Sempsrott]

The object isn’t visible if you call the constructor without passing any input arguments to it. But if you do pass an argument, the superclass object (which I’m calling the “precursor” object) is visible. See the following, where the whos command is placed just inside the constructor entrance as you did in your previous example:

>> ExtendDouble;
 
>> ExtendDouble(1);
 
  Name      Size            Bytes  Class     Attributes

  data      1x1                 8  double

Notice the object created is a double not an ExtendDouble (i.e. it was created by the superclass constructor).

[Matt J]

The whos output that you have posted does not show the superclass object. That is the input argument "data" that you have passed to the constructor.