I will let the readers decide for themselves whether they agree or not.) The workaround (However, refer to the reader comments below, which provide insight into the reasoning of what’s going on here, and contend that this is actually the expected behavior. However, if we load MainClass.m in the Matlab editor, we get a somewhat-cryptic MLint warning that hints at this: Unfortunately, no run-time warning is issued to alert us of this. The reference handle’s value1 property remains unmodified because whenever we try to set 1 to any value, we’re just updating the struct variable in the local workspace.
Still, due to Matlab’s internal precedence rules, the MainClass class overshadows the new variable MainClass, and so when we try to read (as opposed to update) MainClass.inner we are actually referencing the inner reference handle of the MainClass class, rather than the corresponding field in the new struct.
In fact, this creates a new struct variable named MainClass in our current workspace. This being the case, Matlab’s internal interpreter reverts to the simplistic understanding that 1 means “the value1 field of the struct inner, which is itself a field of the outer struct named MainClass“. value1) in the same Matlab expression is too complex for MCOS, and it does not properly understand it. Matlab does understand MainClass.inner to mean “the inner property of the MainClass class”, but adding another dereferencing level (. The underlying problem is that Matlab does not understand 1 to mean “the value1 property of the inner property of the MainClass class”. Understanding this oddity/bug then leads to a very simply workaround. It turns out that all these strange behaviors can be attributed to a single Matlab oddity (I call it a “bug”) in its class object system (MCOS) implementation. What the heck is going on here? did Matlab’s MCOS flip its lid somehow? Well, apparently not. value1 = 9 % one last attempt, that also fails! inner % strange - now we have both value1 & value2, but value1 is not updated! setInnerValue ( 7 ) % looks ok, no error. setInnerValue ( 7 ) % another strange run-time error! Reference to non-existent field 'setInnerValue'. inner % strange - value1 appears ok here, but where is value2 ?! value1 % strange - value1 appears unmodified! value2 % causes a strange run-time error! Reference to non-existent field 'value2'.