Hi Yair,

Do you agree with me that none of the above Attributes contribute to decent programming?

@neusgaten – While I agree that writing the case-sensitive non-truncated format of property names is generally preferable, I still think that the CaseInsensitiveProperties and TruncatedProperties attributes are useful, if only for the reason that we have to keep consistency between HG classes and user classes, and because using case-insensitive and truncated properties is such an ingrained practice for Matlab programmers in the HG context.

Regarding the other attributes, Enumeration and SupportClassFunctions, I’m not sure, but I don’t think they contribute to bad programming practices. Maybe when we will know more about them we can decide.

I really despise the possibility to abbreviate properties and ignore their proper case. While it might be convenient during code testing it really kills readability for you and those required to read your code later on. It’s also terrible once you wish to grep for these properties in a huge code base. I’m really happy that they decided to take a cleaner path for the “new” object-oriented stuff.

I really hope the sole reason why those hidden attributes exist is because The MathWorks intends to kill UDD some day and move their HG implementation to MCOS while retaining backwards compatibility for a huge part of the MATLAB community.

@Martin The MathWorks has indicated for years that UDD is a technology that they intend to replace. While the exact path they intend to take is not clear, the development of HG2 moves forward with each release. On the Simulink side of the UDD equation, much of the new functionality is implemented in MCOS. 2012 saw the switch of Simulink.Parameter and Simulink.Signal objects move from UDD to MCOS.

With R2010b, DAStudio.Dialog, once a dialog GUI system exclusively for objects derived from the UDD DAStudio.Object began allowing its use with MCOS objects which properly implemented the getDialogSchema.m method.

So I suspect that you are right that UDD will eventually be removed from MATLAB, but the process may be a slow and gradual one.

My 2 cents on this is that there is such an enormous code corpus implemented in UDD, that I simply can’t see everything being transitioned to MCOS anytime soon. I didn’t see any major refactoring of UDD code to MCOS so far. In fact, from one release to another I see the UDD code corpus grow, although not at the same rate as MCOS code. It would indeed be hard to justify the enormous dev effort required to redevelop & properly test all the existing UDD code in MCOS. So my personal hunch is that we will see new code being implemented in MCOS, but I suspect that existing UDD functionality will remain unchanged for some time to come.

All this excluding HG2 of course: Since HG2 is a major rework of the entire HG system, it does make sense to redo everything in MCOS, which I suspect is ^[13]. I for one will be happy to see the last of the unbelievably (and some might also say, unnecessarily) complex uimodes, scribe layer and their ilk. I just pray they won’t be replaced with similarly-convoluted mechanisms in HG2.

it seems that it (the classdef CaseInsensitiveProperties and TruncatedProperties) does not work with dynamic properties

I just found an undocumented syntax to specify property types in classes:
^[14]

I thought you might be interested 🙂

@Amro – thanks, interesting!

[…] a few days ago I was pleasantly surprised to read Amro’s comment about an entirely new and undocumented aspect of Matlab MCOS classes […]

I am currently writing a way of generating custom documentation from class files. I heavily rely on metaclass objects to do so, and have found them to be very useful. Unfortunately the Description and DetailedDescription puzzled me, until now! Thanks for this.

I am especially keen on using this for method and property descriptions. Unfortunately it seems that there is no way to specify descriptions for individual properties without a whole lot of work.

@Chris – take a look at the ^[15] utility on the File Exchange – no need to reinvent the wheel…

Regarding SupportClassFunctions, would that allow instances of a class to be used as a function? In the same manner as core class/functions like scatteredInterpolant?

@Ben – I don’t think I follow you – scatteredInterpolant is a simple Matlab class, not a function (see ^[16]).

@Yair – Sorry, I wasn’t clear. Each instance of scatteredInterpolant is a function.

foo = scatteredInterpolant (x, y, z); 
c = foo (a, b);

I don’t think their is a documented way to produce a class (via classdef) that supports the feature, c=foo(a,b). From the name of the attribute SupportClassFunctions I inferred this may needed to allow foo to be used as a function.

I see what you mean, but I don’t think it is related. scatteredInterpolant simply overloaded the subsref(), subsasgn(), end() methods for this functionality. You can do it in any user class.

Ok that makes sense, and explains the clumsy behavior below.

>> foo(3) = scatteredInterpolant
foo = 
  1x3 scatteredInterpolant array with properties:

    Points
    Values
    Method
    ExtrapolationMethod

>> foo(3)
ans =
     []

The use of the Description attribute in a classdef alters the behavior of the command line help. Normally

>> help classname

echoes the comments under the classdef line and

>> help classname.classname

echoes the comments under the function constructor. When Description is specified

I’ve been looking for ways to define custom attributes for classes and class methods/properties. I’ve noticed that some internal matlab classes define additional attributes, such as the unit test classes derived from matlab.unittest.TestCase. This can be nicely observed from its meta class:

>> mTestClass = meta.class.fromName('matlab.unittest.TestCase');
>> mTestMethod = mClass.MethodList(1)
mTestMethod = 
  method with properties:
                    Test: 0
         TestMethodSetup: 0
      TestMethodTeardown: 0
          TestClassSetup: 0
       TestClassTeardown: 0
    ParameterCombination: ''
                TestTags: {}
                    Name: 'TestCase'
             Description: ''
     DetailedDescription: ''
                     ...

The top 7 properties correspond to the method attributes that are available in the method definition blocks, for classes derived from matlab.unittest.TestCase. Apparently these have been added by subclassing the meta.method object to the new matlab.unittest.meta.method, which is indeed the meta class that is returned for classes derived from the superclass matlab.unittest.TestCase.

My question is: do you know of any (undocumented) means to define such attributes ourselves, such that you could do something like this?

classdef MyClass < MyBaseClass
    methods (CustomAttribute = "Custom attribute value")
       ...
    end
end

Any insight or directions would be highly appreciated!

Maarten,

No, you can’t do that, although MathWorks are considering the possibility for a future enhancement. A similar question was asked on StackOverflow a while ago ( ^[17]) and received a couple of answers, one of which was from Andy Campbell, a senior developer at MathWorks. See the comment thread under his answer.

In the meantime, it is sometimes possible to achieve your aims by abusing the undocumented attributes Description and DetailedDescription.
These are undocumented, but are always present (on class, method, property and event elements), and accept a string value that you can use to store essentially whatever you want. Some built-in classes such as containers.Map use them to store a description of the class.

Because they are undocumented, if you use them they will cause a red underline in the MATLAB editor (without any actual runtime error). You can suppress this using %#ok<ATUNK> at the end of the line.

Any updates on this development? I just raised a similar question there: ^[18] and after searching for “Description attribute” I ended up here 😀