Setting class property types – take 2

13 Responses to Setting class property types – take 2

1. Martin Afanasjew says:

   April 28, 2016 at 10:58 pm

   @Yair – Addressing your “In fact, aside from the fact that the new syntax is documented, I can see no advantages that it offers over the older syntax, only disadvantages. Or am I missing something? Please do tell if you see any important advantages that I’ve missed.”

   Some may see it as an advantage, but I think the following is making things even worse. In addition to different syntax there is also different semantics of the old (undocumented) and new property type declarations. Assuming obj is an instance of a class with the following properties block

   OldStyle@char = 'old'
   NewStyle char = 'new'

   there is this interesting behavior:

   ›› obj.OldStyle = 65;
   While setting the 'OldStyle' property of 'Properties2016a': Value must be 'char'. 
    
   ›› obj.NewStyle = 65;
   ›› obj.NewStyle
   ans =
   A

   This means the new syntax automatically converts to the declared type, if possible. (To be fair, this is documented.) The old syntax is more strict and throws an error on type mismatch, something I find much more desirable.

   The following transcript reveals the difference in internal representation:

   ›› m = metaclass(obj);
   ›› m.PropertyList(1).Type.Name
   ans =
   char
   ›› m.PropertyList(2).Type.Name
   ans =
   char property

   This also means that writing NewStyle@char property is equivalent to NewStyle char and will give the new behavior using the old syntax. All of this feels pretty convoluted and like you I fail to see the benefit of creating yet another syntax instead of documenting (and extending) the old syntax that has existed for a long time.

   Reply
2. YishaiE says:

   April 29, 2016 at 3:53 am

   Isn’t inputParser a solution to the function input typecheck issue (kludgy and convoluted, but functional)?

   Reply
   • Yair Altman says:

     April 30, 2016 at 8:25 pm

     @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!
3. Ulrik says:

   April 29, 2016 at 8:57 pm

   Just a warning:
   The @ for properties only works well for built-in objects in the older versions of Matlab.
   If you use the @ for custom classes you can crash Matlab if the path to the classdef becomes unknown (e.g. you have not set it using addpath or the path is modified in a bad way).
   Some of the built-in stuff in Matlab is written a bit “alternative” (e.g. uigetdir) and can trigger and a bug where the Matlab UI path goes out of sync with the actual path.
   The bug seems to be (Matlab internal) event related.

   Now with the new functionality I am looking forward to testing if this bug has been fixed or not. If not Mathworks can expect a bug-report.

   Reply
4. Egon says:

   May 1, 2016 at 3:28 pm

   Cross compatibility – it is very confusing to users coming to Matlab from other programming languages, all of which (without any important exception) place the type name to the LEFT of the identifier name, not to its RIGHT. People coding in both Matlab and Java/C/C++ would easily get confused and frustrated.
   I disagree with this. There are quite a few languages that annotate the type to the right of variable names. Just have a look at Pascal (for an old language), and newer (and popular) languages such as Scala, Swift, Go, Rust, …: all of those define the type after the variable name.

   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.

   Reply
   • Yair Altman says:

     May 2, 2016 at 1:32 am

     @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.
5. Adam says:

   May 3, 2016 at 6:37 pm

   Thanks, this is certainly interesting. More so for me because I somehow missed your previous post from 3 years ago and knew nothing about the undocumented syntax (or the new documented one) previously! I did see some new appdesigner code recently though which included this new syntax and surprised me since I had never seen it before and thought it must somehow be special for appdesigner-produced code.

   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.

   Reply
6. Simon says:

   May 4, 2016 at 6:58 pm

   Matlab typing in general isn’t great. Try this;

   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…

   Reply
7. Chris Hoogeboom says:

   June 17, 2016 at 3:30 pm

   Hi Yair,

   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

   Reply
   • Yair Altman says:

     June 22, 2016 at 10:47 am

     @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
8. anonymous says:

   March 16, 2017 at 11:46 am

   Actually, Matlab has relased a new syntax to define property restrictions (Size, Class, Validation Functions):

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

   Reply
9. Kyle says:

   October 23, 2019 at 9:25 pm

   I have serious issues with the new syntax actually. If you want to have abstract classes, the old method would work. The new method does not. For example the below 3 classes work with the old way, but the new way does not. Also sorry for the formatting. I couldn’t seem to indent and add spaces properly

   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

   Reply
   • Martin Lechner says:

     October 31, 2019 at 1:59 pm

     Hi Kyle,

     I normally initialize the property with

     properties
         graphicToPrint Graphic = ConcreteGraphic.empty
     end

     and have no problems with the new syntax.