Hi Kyle,

I normally initialize the property with

properties
    graphicToPrint Graphic = ConcreteGraphic.empty
end

and have no problems with the new syntax.

classdef Printer
    properties
       %graphicToPrint Graphic  % doesn't work
        graphicToPrint@Graphic
    end
    methods
        function print(this)
            % do some printing acting on graphicToPrint
            this.graphicToPrint.print();
        end
    end
end

classdef Graphic
    methods (Abstract)
        print(this);
    end
end

classdef ConcreteGraphic < Graphic
    methods
        function print(this)
            disp('print on ConcreteGraphic happened')
        end
    end
end

>> p = Printer;
>> p.graphicToPrint = ConcreteGraphic;
>> p.print
print on ConcreteGraphic happened

https://de.mathworks.com/help/matlab/matlab_oop/validate-property-values.html

@Chris – nice to see you here!

Your report chimes with Martin’s comment above. The new syntax’s documented automatic type-casting can be replicated in the old (undocumented @) syntax using the property attribute:

classdef DayExample
    properties
        day@WeekDay property = WeekDay.Monday
    end
end

which allows setting the value as either an enumerated value or its char representation:

>> d = DayExample
d = 
  DayExample with properties:

    day: Monday

>> d.day = WeekDay.Tuesday
d = 
  DayExample with properties:

    day: Tuesday

>> d.day = 'Thursday'
d = 
  DayExample with properties:

    day: Thursday

I agree with you on all of your points, especially with regards to the backwards compatibility issue. One nice thing that I noticed while reading through the documentation is that you can now specify properties to be a part of an enumeration class, which then allows you to set those properties as strings. For instance, suppose I have an enumeration

classdef WeekDay
    enumeration
        Monday
        Tuesday
        Wednesday
        Thursday
        Friday
    end
end

Now I can define a class as such

classdef DayExample
    properties
        day WeekDay = WeekDay.Monday
    end
end

and now I can do

obj = DayExample();
obj.day = WeekDay.Monday;
obj.day = 'Tuesday';

where in previous versions of MATLAB, I would have to implement it as

classdef DayExampleLegacy01
    properties
        day@WeekDay = WeekDay.Monday
    end

    methods
        function this = set.day(this, d)
            if ischar(d) && isvector(d)
                d = WeekDay.(d);
            end
            this.day = d;
        end
    end
end

or

classdef DayExampleLegacy02
    properties
        day@char = 'Monday'
    end

    methods
        function this = set.day(this, d)
            WEEK_DAYS = {'Monday', 'Tuesday', 'Wednesday', 'Thursday', 'Friday'};
            assert(ismember(d, WEEK_DAYS), ...
                'DayExampleLegacy02:IllegalDay', ...
                '"%" is not a valid week day.', d);
            this.day = d;
        end
    end
end

inceptDate datetime = datetime([],[],[]);  % The period start date as datetime

Then set it like to the string –

'1-Jan-2010'

Matlab accepts this in both old and new ‘type checking’ formats. If you retrieve the inceptdate variable, it’s a character array, not a datetime.
Functionally then, you *still* need to roll your own type checking, whether you use the old or new style.

For small projects this is okay. For larger living projects, not having type safety is terrible…

I have been using assignments to e.g. someClass.empty in a properties block to act mostly as documentation about what is expected and help with certain array-based initialisations and always use a validateattributes block in property set functions, but using this syntax (well, the undocumented older one at least) is potentially something I will look at for new classes.

@Egon – surely you are not equating the importance of Pascal (which I love, don’t get me wrong) et al, with that of C/C++/C#/Java. By whichever measure that you choose, these 4 latter languages far outweigh the others in importance.

Moreover, even the sample languages that you cite use the : operator to separate the identifier from its type, and in this respect they are much closer to Matlab’s old (undocumented) syntax that uses the @ operator.

Finally, the @ syntax is actually consistent with Matlab classes: after all, Matlab classes use @ to indicate folders containing class methods that are implemented as independent m-files, and also to call super-class methods from a sub-class.

Technically, this simplifies semantic analysis and is easier when type inference is needed.
From a human point of view, I also think it makes more sense. Specifically: the important part is the name of a variable (what does it mean?) rather than its type (implementation detail).
More info also at StackOverflow.

I hence really like that in MATLAB the type declaration is after the field name (no need to replicate the behavior of languages such as C that were explicitly written to be really concise and have quite some peculiarities as a result: e.g. defining both a variable and a pointer on the same line is possible but confusing).

On the other hand, I fully agree with your main point that MATLAB should have just documented the old syntax and not create new ones that are not backwards compatible. But if I’m completely honest, I would rather have seen the syntax as in Pascal, Swift, Scala, …:

name : type = value

where the :type part is optional from the start.
I particularly dislike how the old syntax uses @while those types don’t have an obvious link to function handles, and how this only works for properties, not for function/method arguments.

@YishaiE – inputParser is simply a function that checks the validity inputs. It is essentially no different than using other programmatic solutions such as assert or isa() etc. The potential benefits of constricting the input args at the function declaration level is that it would avoid the need to add these programmatic checks, and also the overheads associated with the function/method call in case of a type mismatch. Moreover, the code becomes cleaner, smaller, more robust and more maintainable. These are basically the same benefits of constricting property types.

Hag Same’ach!