Undocumented Matlab
  • SERVICES
    • Consulting
    • Development
    • Training
    • Gallery
    • Testimonials
  • PRODUCTS
    • IQML: IQFeed-Matlab connector
    • IB-Matlab: InteractiveBrokers-Matlab connector
    • EODML: EODHistoricalData-Matlab connector
    • Webinars
  • BOOKS
    • Secrets of MATLAB-Java Programming
    • Accelerating MATLAB Performance
    • MATLAB Succinctly
  • ARTICLES
  • ABOUT
    • Policies
  • CONTACT
  • SERVICES
    • Consulting
    • Development
    • Training
    • Gallery
    • Testimonials
  • PRODUCTS
    • IQML: IQFeed-Matlab connector
    • IB-Matlab: InteractiveBrokers-Matlab connector
    • EODML: EODHistoricalData-Matlab connector
    • Webinars
  • BOOKS
    • Secrets of MATLAB-Java Programming
    • Accelerating MATLAB Performance
    • MATLAB Succinctly
  • ARTICLES
  • ABOUT
    • Policies
  • CONTACT

Undocumented classdef attributes

November 21, 2012 20 Comments

Matlab’s new (or should I say “renewed”) object-oriented paradigm, uses attributes to define class behavior. Not surprisingly, some attributes used by Matlab’s internal classes are not documented in the official documentation of the supported attributes. These attributes could well be useful when defining our custom classes:

MCOS (Matlab Common/Class Object System) classes

Attribute Name Class Default value if unspecified Description
CaseInsensitiveProperties logical (true/false) false If true, then such properties can be accessed using any case. For example, if the property is called myProp, then it can be called as myclass.myProp or myClass.MYPROP or any other variation.
If the class inherits hgsetget, then the property can also be used in this way within get/set functions:

get(myClass,'MYPROP')

get(myClass,'MYPROP')

If the attribute is unspecified or false, then trying to use a case-insensitive version of the property name would result in an error:

Error using MyClass/get
Property MYPROP not found in class MyClass, or is not present in all elements of the array of class MyClass.

TruncatedProperties logical (true/false) false If true, then such properties can be accessed using any substring that leads to a unique property. For example, if the property is called myProperty, then it can be called as myclass.myProperty or myClass.myProp or any other variation.
If the class inherits hgsetget, then the property can also be used in this way within get/set functions:

get(myClass,'myProp')

get(myClass,'myProp')

Note that if the class has another property called myProblem, then myClass.myPro would be ambiguous and result in an error message; we would need to use myClass.myProp or some other unique term:

Error using MyClass/get
Ambiguous MyClass property: 'myPro'.


If the attribute is unspecified or false, then trying to use a truncated version of the property name would result in an error:

Error using MyClass/get
Property myProp not found in class MyClass, or is not present in all elements of the array of class MyClass.

Enumeration logical (true/false) false If true, then the class appears to be an enumeration class. I am not exactly sure how this could be useful. I saw references to this attribute in the Data Aquisition Toolbox.
SupportClassFunctions logical (true/false) false As above, I am not exactly sure how this could be useful. I saw reference to this attribute in %matlabroot%/toolbox/shared/controllib/engine/ (I don’t currently have ready access to this toolbox so I can’t test).
Description char '' A string that describes the class. First mentioned here.
DetailedDescription char '' A string that describes the class in more detail. First mentioned here.

The CaseInsensitiveProperties and TruncatedProperties attributes are true for Matlab HG (Handle-Graphics) properties. Many users have come to rely on the fact that they can specify the Position property using get(gcf,'position') or set(gcf,'Pos'). It is very intuitive to use. For this reason I do not understand why MathWorks chose to set these attributes’ default value to false. At least now we can manually change this for our classes.

Sample usage (see %matlabroot%/toolbox/matlab/graphics/+graphics/+internal/@LinkAxes/LinkAxes.m and many others):

classdef (CaseInsensitiveProperties=true, TruncatedProperties=true, ConstructOnLoad=true) LinkAxes < handle
classdef (CaseInsensitiveProperties, TruncatedProperties, ConstructOnLoad) LinkAxes < handle  % equivalent alternative

classdef (CaseInsensitiveProperties=true, TruncatedProperties=true, ConstructOnLoad=true) LinkAxes < handle classdef (CaseInsensitiveProperties, TruncatedProperties, ConstructOnLoad) LinkAxes < handle % equivalent alternative

I could not find any similar undocumented attributes for properties, methods, events and enumerations.
Do you know of any other useful attribute for the class, or for its constituents? If so, please post a short comment below.

UDD (Universal Data Dictionary, schema) classes

UDD (schema) classes have the property truncation on by default, and in fact this cannot be unset. I.e., we cannot have a variant of MCOS’s TruncatedProperties=false for schema objects:

>> hTabGroup = uitabgroup;
>> get(hTabGroup,'FlowDir')  % truncated from 'FlowDirection'
ans =
topdown

>> hTabGroup = uitabgroup; >> get(hTabGroup,'FlowDir') % truncated from 'FlowDirection' ans = topdown

The properties do have a settable CaseSensitive meta-property that we can set to ‘on/off’ (default=’off’) on a property-by-property basis. In most cases, we would naturally stick with the default behavior:

>> get(hTabGroup,'flowdir')  % case-insensitive form of 'FlowDirection'
ans =
topdown

>> get(hTabGroup,'flowdir') % case-insensitive form of 'FlowDirection' ans = topdown

This mean that by default, schema objects behave similarly to the ubiquitous HG behavior, whereas custom MCOS objects have a default behavior that is much stricter and needs special handling.

Related posts:

  1. getundoc – get undocumented object properties – getundoc is a very simple utility that displays the hidden (undocumented) properties of a specified handle object....
  2. Undocumented HG2 graphics events – Matlab's new HG2 graphics engine includes many new undocumented events that could be used in various ways. ...
  3. Undocumented scatter plot jitter – Matlab's scatter plot can automatically jitter data to enable better visualization of distribution density. ...
  4. More undocumented timing features – There are several undocumented ways in Matlab to get CPU and clock data...
  5. HG's undocumented parameters interface – Some HG functions also accept inputs parameters in a struct fields rather than the normal P-V pairs format. ...
  6. Undocumented scatter plot behavior – The scatter plot function has an undocumented behavior when plotting more than 100 points: it returns a single unified patch object handle, rather than a patch handle for each specific point as it returns with 100 or less points....
MCOS Object oriented Pure Matlab Undocumented feature
Print Print
« Previous
Next »
20 Responses
  1. neusgaten November 22, 2012 at 02:00 Reply

    Hi Yair,

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

    • Yair Altman November 22, 2012 at 02:24 Reply

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

  2. Martin Afanasjew November 27, 2012 at 08:25 Reply

    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.

    • Donn Shull November 27, 2012 at 12:34 Reply

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

      • Yair Altman November 27, 2012 at 14:12

        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 what MathWorks is doing. 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.

  3. Jacques January 31, 2013 at 22:03 Reply

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

  4. Amro April 13, 2013 at 13:35 Reply

    I just found an undocumented syntax to specify property types in classes:
    http://stackoverflow.com/a/15992558/97160

    I thought you might be interested 🙂

    • Yair Altman April 13, 2013 at 13:50 Reply

      @Amro – thanks, interesting!

  5. Setting class property types | Undocumented Matlab April 18, 2013 at 07:12 Reply

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

  6. Chris Hoogeboom May 1, 2013 at 08:44 Reply

    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.

    • Yair Altman May 1, 2013 at 08:48 Reply

      @Chris – take a look at the Doxygen for Matlab utility on the File Exchange – no need to reinvent the wheel…

  7. Ben Abbott July 12, 2014 at 17:08 Reply

    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?

    • Yair Altman July 13, 2014 at 16:12 Reply

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

    • Ben Abbott July 14, 2014 at 05:28 Reply

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

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

      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.

    • Yair Altman July 14, 2014 at 05:53 Reply

      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.

      • Ben Abbott July 14, 2014 at 15:57

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

        >> foo(3) = scatteredInterpolant foo = 1x3 scatteredInterpolant array with properties: Points Values Method ExtrapolationMethod >> foo(3) ans = []

  8. Terry Brennan November 30, 2015 at 22:48 Reply

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

    >> help classname

    >> help classname

    echoes the comments under the classdef line and

    >> help classname.classname

    >> help classname.classname

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

  9. Maarten van der Seijs March 28, 2018 at 14:12 Reply

    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: ''
                         ...

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

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

    Any insight or directions would be highly appreciated!

    • Sam Roberts March 28, 2018 at 18:59 Reply

      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 (https://stackoverflow.com/questions/26710767/which-methods-keywords-i-e-testmethodsetup-can-occur-in-matlab/26733613#26733613) 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.

      • Jan October 26, 2021 at 18:49

        Any updates on this development? I just raised a similar question there: https://www.mathworks.com/matlabcentral/answers/1571813-custom-class-properties-and-method-attributes?s_tid=mlc_ans_email_view#comment_1801123 and after searching for “Description attribute” I ended up here 😀

Leave a Reply
HTML tags such as <b> or <i> are accepted.
Wrap code fragments inside <pre lang="matlab"> tags, like this:
<pre lang="matlab">
a = magic(3);
disp(sum(a))
</pre>
I reserve the right to edit/delete comments (read the site policies).
Not all comments will be answered. You can always email me (altmany at gmail) for private consulting.

Click here to cancel reply.

Useful links
  •  Email Yair Altman
  •  Subscribe to new posts (feed)
  •  Subscribe to new posts (reader)
  •  Subscribe to comments (feed)
 
Accelerating MATLAB Performance book
Recent Posts

Speeding-up builtin Matlab functions – part 3

Improving graphics interactivity

Interesting Matlab puzzle – analysis

Interesting Matlab puzzle

Undocumented plot marker types

Matlab toolstrip – part 9 (popup figures)

Matlab toolstrip – part 8 (galleries)

Matlab toolstrip – part 7 (selection controls)

Matlab toolstrip – part 6 (complex controls)

Matlab toolstrip – part 5 (icons)

Matlab toolstrip – part 4 (control customization)

Reverting axes controls in figure toolbar

Matlab toolstrip – part 3 (basic customization)

Matlab toolstrip – part 2 (ToolGroup App)

Matlab toolstrip – part 1

Categories
  • Desktop (45)
  • Figure window (59)
  • Guest bloggers (65)
  • GUI (165)
  • Handle graphics (84)
  • Hidden property (42)
  • Icons (15)
  • Java (174)
  • Listeners (22)
  • Memory (16)
  • Mex (13)
  • Presumed future risk (394)
    • High risk of breaking in future versions (100)
    • Low risk of breaking in future versions (160)
    • Medium risk of breaking in future versions (136)
  • Public presentation (6)
  • Semi-documented feature (10)
  • Semi-documented function (35)
  • Stock Matlab function (140)
  • Toolbox (10)
  • UI controls (52)
  • Uncategorized (13)
  • Undocumented feature (217)
  • Undocumented function (37)
Tags
AppDesigner (9) Callbacks (31) Compiler (10) Desktop (38) Donn Shull (10) Editor (8) Figure (19) FindJObj (27) GUI (141) GUIDE (8) Handle graphics (78) HG2 (34) Hidden property (51) HTML (26) Icons (9) Internal component (39) Java (178) JavaFrame (20) JIDE (19) JMI (8) Listener (17) Malcolm Lidierth (8) MCOS (11) Memory (13) Menubar (9) Mex (14) Optical illusion (11) Performance (78) Profiler (9) Pure Matlab (187) schema (7) schema.class (8) schema.prop (18) Semi-documented feature (6) Semi-documented function (33) Toolbar (14) Toolstrip (13) uicontrol (37) uifigure (8) UIInspect (12) uitable (6) uitools (20) Undocumented feature (187) Undocumented function (37) Undocumented property (20)
Recent Comments
Contact us
Captcha image for Custom Contact Forms plugin. You must type the numbers shown in the image
Undocumented Matlab © 2009 - Yair Altman
This website and Octahedron Ltd. are not affiliated with The MathWorks Inc.; MATLAB® is a registered trademark of The MathWorks Inc.
Scroll to top