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.

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: http://undocumentedmatlab.com/blog/handle-object-as-default-class-property-value

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?

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.

@Brad – indeed so 🙂

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: []

@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.

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).

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

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,