Class Unexpected Behaviour with Properties and Type Casting

Hello Community,

Is this the expected behavior when having a property in a class that is type declared and then re-assigned to a different type?

classdef Blah

properties

meh char = '';

end

methods

function obj = Blah()

obj.meh = {'Bleah!', 'Bleah, again'};

end

end

end

Here is the screenshot of the result of the class instantiation:

Shouldn't this code produce at least a runtime error when meh is assigned to a cell object instead of forcing this automatic typecasting?

This gives an error (expected)

Is this my old version on matlab2018b that works in this confusing way?

It defeats the purpose of declaring the type because accidental/wrong assignments to different types go undetected.

Answer 1

[Steven Lord]

Shouldn't this code produce at least a runtime error when meh is assigned to a cell object instead of forcing this automatic typecasting?

No. From the most recent documentation (but I believe the documentation for release R2018b should read basically the same):

"Defining the class of a property can reduce the need to test the values assigned to the property in your code. In general, the value assigned to the property must be of the specified class or convertible to the specified class. An exception to this rule is for subclasses. If you specify a user-defined class as part of validation, subclasses of that class pass validation without error, but they are not converted." [Emphasis added.]

If you wanted to disallow that conversion process, use mustBeA instead.

type sampleclass2179908.m

classdef sampleclass2179908
    properties
        text {mustBeA(text, 'char')} = '';
    end
    methods
        function obj = sampleclass2179908(in)
            obj.text = in;
        end
    end
end

y = sampleclass2179908('abcde')

y = 
  sampleclass2179908 with properties:

    text: 'abcde'

y = sampleclass2179908({'abcde'})

Error using sampleclass2179908 (line 7)
Error setting property 'text' of class 'sampleclass2179908'. Value must be one of these types: 'char'.

[Bob Randall]

@Steven Lord

So, this is the way the matlab class has been designed. Autocasting to me is just a potential source of errorswhen a type is explicitly declared. And it is confusing. I think that the principle of the least surprise is a pragmatic and very useful principle and should always be applied when possible. This class implementation doesn't seem to follow it.

Thank you for the thorough answer, and moreover, for finding a solution.

Bob

[Steven Lord]

If you declared that a property was supposed to contain, say, an int32 would you expect to be able to store a literal 1 in it? What class is the literal 1?

classOfLiteralOne = class(1)

classOfLiteralOne = 'double'

We could have forced you to explicitly convert the literal 1 into an int32 in order to store it into the property of the array.

oneDouble = 1

oneDouble = 1

oneInt32 = cast(oneDouble, 'int32') % or

oneInt32 = int32
1

oneInt32 = int32(oneDouble)

oneInt32 = int32
1

whos one*

  Name           Size            Bytes  Class     Attributes

  oneDouble      1x1                 8  double              
  oneInt32       1x1                 4  int32               

If you use the mustBeA approach, you will in fact be forced to do the explicit conversion.

try
    mustBeA(1, 'int32')
    fprintf("mustBeA call succeeded.")
catch ME
    fprintf("mustBeA call failed with error:\n%s\n", ME.message)    
end

mustBeA call failed with error:
Value must be one of these types: 'int32'.

But in this case, it's clear what you intend to do: store the value one (I'm using this to refer to the value independent of the class used to store it) in the property. So MATLAB does the conversion for you. There are other places where we do this type of implicit conversion as well: should we force you to use oneInt32 instead of oneDouble in the code below that creates a variable B?

A = ones(2, 'int32')

A = 2×2

1 1 1 1

<mw-icon class=""></mw-icon>

<mw-icon class=""></mw-icon>

B1 = A + oneDouble

B1 = 2×2

2 2 2 2

<mw-icon class=""></mw-icon>

<mw-icon class=""></mw-icon>

●

B2 = A + oneInt32

B2 = 2×2

2 2 2 2

<mw-icon class=""></mw-icon>

<mw-icon class=""></mw-icon>

whos A B*

  Name      Size            Bytes  Class    Attributes

  A         2x2                16  int32              
  B1        2x2                16  int32              
  B2        2x2                16  int32              

Your case is slightly different but very similar. There are at least three different ways to store textual data in MATLAB: char arrays, cell arrays containing char vectors (also known as cellstrs), or string arrays. You can see this category in the documentation for an explanation of the differences between the three representations. Each has its pros and cons. But generally speaking, most MATLAB functions ought to be able to handle each of the three representations in a relatively reasonable way (where "relatively reasonable" could include converting between the representations.) See this documentation page for some guidance, and note that most of our functions follow the guidance on this page.

[Bob Randall]

And that is exactly what is confusing and makes code prone to errors. For example, adding doubles to integers is not a good idea in general. If you get an error message or maybe a warning, then you are aware that you can loose the decimal part during the conversion, and maybe, you start wondering how the rounding is done (e.g. the bias issue.) Moreover, these conversions that are made automatically fail when you write codegen compatible code.

I have been using quite intermittently matlab for more than 20 year and I maybe understand the way it evolved and the constant problem of having to be backward compatible. I bet Matworks is back to drawing board working on the new version of the language (with a powerfull compiler) that will make even better that it is now.

Thank you , Steven

Bob