Solving a Matlab MCOS bug

10 Responses to Solving a Matlab MCOS bug

1. Sven says:

   December 2, 2015 at 12:24 pm

   There was something like this bug in R2015a, which seems to have been fixed in R2015b.
   In order to access the elements of a cell-type variable, you would first need to store a copy of that variable locally.

   T = cell2table({'a';'b';'c'},'Var',{'myCell'})
   sprintf('%s,',T.myCell{:})
   ans =
   a,b,c,

   The above now works in 2015b. In 2015a however, the result was:

   sprintf('%s,',T.myCell{:})
   ans =
   a,

   Whereas you could work around with:

   tmpCell = T.myCell;
   sprintf('%s,',tmpCell{:})
   ans =
   a,b,c,

   Reply
   • Sven says:

     December 2, 2015 at 12:25 pm

     And to clarify: the above bug was limited to “cell-typed variables of *tables*”.
2. Dave Foti says:

   December 2, 2015 at 2:12 pm

   I can understand Yair’s confusion, but there is a simple explanation the behavior described in this post (with Constant properties). MATLAB doesn’t have variable declarations. When a name appears on the left of an equal sign, that statement always create a variable from the left-most name. Try “MainClass.inner = 1” and you will see that it doesn’t matter how complex the indexing expression is, assignment always introduces a new variable that hides any function or class of the same name. In this case the dot indexing means that MainClass will be a struct. It is important that variables have highest precedence so that scripts and functions don’t have to worry about collisions between the variable names used in the code and functions and classes on the path (a set of names that is very large and always growing).

   Reference to a name that has not been introduced as a variable will find the class. It doesn’t matter how many dots you have or how complex the indexing expression is. Here are some functions you can try that show how MATLAB consistently treats assignment as creating a variable. Note that the last two functions produce the same results whether or not MainClass exists on the path.

   function useClassConstants
      X = MainClass.inner  % MainClass is not a variable, so find inner property of MainClass class
      Y = MainClass.inner.value1 
   end

   function createStruct1
      MainClass.inner = 2 % Create a struct variable named MainClass
      isa(MainClass, 'struct')
   end

   function createStruct2
      MainClass.inner.value1 = 3.5 % Create a struct variable named MainClass
      isequal(MainClass.inner.value1, 3.5) % See that we are only using this struct
   end

   This comes down to the fact that preserving the meaning of variables independent of what is on the path is considered more important than making it easy to create mutable per-class state (which is often problematic anyway because it can lead to unwanted cross-talk between applications that share the same libraries).

   Reply
   • Yair Altman says:

     December 2, 2015 at 3:21 pm

     @Dave – thanks for your clarification, but the inconsistency here between the assignment and reference precedence rules is confusing. I contend that the following precedence rule might be more intuitive and consitent in such cases, while still preserving the default behavior for the remainder of the cases:

     1. try to understand MainClass (in both assignment and referencing) as referring to variable MainClass on the local workspace. If successful then continue to use this variable.
     2. otherwise, try to understand MainClass as a class/package name. If successful and no error, then continue to use this. Note that this does not break your requirement for MainClass=5 to override the class definition and create a local variable named MainClass, because assigning to a class is illegal and therefore raises an error and falls-through to the following rule:
     3. otherwise, in an assignment create a new workspace variable named MainClass, and in a reference raise an error about trying to use an unrecognized identifier.

     These precedence rules will ensure that variables always take precedence over function/class/package names (as you have rightfully pointed out), but only when they exist – otherwise the existing function/class/package name should obviously take precedence over the non-existing variable. The behavior now becomes fully consistent across assignment and reference, and I think is much more intuitive in run-time than the current situation.
   • Dave Foti says:

     December 3, 2015 at 7:22 am

     Hi Yair,
     The problem is that it isn’t enough for “MainClass = 1” to ensure that MainClass is a variable. As long as structs have existed in MATLAB, it has been possible to create structs using the syntax “MainClass.inner = 1” just as numeric arrays can be created using indexing as in “X(1:10) = 1” Thus, your proposed rules would still mean that a function or script (like the 2 createStruct examples I provided) could be written using local struct variables that later got re-interpreted as referring to a class and its property that happened to be on the path.
3. Brad Stiritz says:

   December 2, 2015 at 9:02 pm

   Hi Yair, thanks for a super-interesting post. Thanks to Dave as well for the helpful clarification. Just to clarify your workaround, Yair, here’s a revised implementation of the static function, and the expected result
   produced by the new code:

   classdef (Abstract) MainClass
       properties (Constant)
           inner = InnerClass
       end
       methods (Static)
           function setInnerValue(newValue)
               innerObj = MainClass.inner;
               innerObj.value1 = newValue;
           end
       end
   end

   >> MainClass.setInnerValue(5)
   >> MainClass.inner
   ans = 
     InnerClass with properties:
       value1: 5
       value2: []

   Reply
   • Yair Altman says:

     December 3, 2015 at 12:16 am

     @Brad – indeed so
4. alexandre says:

   December 4, 2015 at 4:10 am

   cool post!

   I am confused about the following point:

   The inner class is declared inside the ‘constant’ properties – why would we be assigning to it in the first place? It seems to me that this is key for a problem to occur (there is no other attribute that I can see that could be accessed via the static function call – http://se.mathworks.com/help/matlab/matlab_oop/property-attributes.html)

   Reading the docs above suggeststhat Constant properties can be modified (but not by sub-classes). But this article suggests that they should be set at definition and not touched thereafter: http://se.mathworks.com/help/matlab/matlab_oop/properties-with-constant-values.html.

   So are matlab (Constant) properties what other OO languages call ‘static’ properties?

   Reply
   • Yair Altman says:

     December 4, 2015 at 4:16 am

     The property is constant in the sense that its reference handle remains unmodified after being set, but its inner properties are not constant. It’s like saying that a company’s ID remains constant, but its employees, phone number, and physical address may possibly change over time. Or like saying that a house address remains constant but its occupants change over time.

     Related post: https://undocumentedmatlab.com/blog/handle-object-as-default-class-property-value
5. Jeroen Boschma says:

   January 7, 2016 at 4:35 am

   Hi Yair,

   I think this is certainly not a simple MCOS parser bug, even not a bug at all, but since I have limited knowledge about the inner things of MATLAB classes I may be on thin ice here…

   Try the following as your very first statement:

   MainClass.inner.value2
   ans =
        []

   So that rules out that there is only a simple MCOS parser bug just because there would be too many dereferencing levels. Since there is no variable MainClass, MATLAB correctly dereferences all levels within the class MainClass.

   The underlying problem, I think, is that you cannot change class definitions, only instances of classes. What in this case happens is the following:

   1) Within ‘setInnerValue()’ there is no variable named MainClass, and MATLAB detects the reference to the class, correctly taking all reference levels into account (my example above shows that this is not the problem).
   2) MATLAB detects the assignment statement.
   3) MATLAB falls back on the rule “modifying class definitions (i.e. its properties) is not possible”.
   4) MATLAB falls back on the only remaining option: create a new struct variable ‘MainClass’ and execute the assignment.

   So I think the bottom line is that MATLAB has a strict interpretation of “modifying class definitions is not possible”, and that therefore every direct assignment via the class definition is prohibited. This is not a bug at all in my opinion, but you end up in a discussion how tight the underlying fields of ‘inner’ are related to MainClass itself. The fact that you can change the fields of ‘inner’ using a workaround does not mean that MATLAB should allow doing this directly via the class definition itself. For this matter, I tend to agree with MATLAB’s choice.

   Reply