How to achieve autocompletion for "fake" properties of class inheriting from matlab.mix​in.indexin​g.Redefine​sDot

I am creating a class MyClass that inherits from matlab.mixin.indexing.RedefinesDot.

The class has, among other properties, one property called LinkedFiles. The value of LinkedFiles is a scalar instance or a vector of instances of a class called LinkedFile. LinkedFile has several properties, and I want to "embed" these in my main class. I am currently doing this by a combination of inheriting from both matlab.mixin.indexing.RedefinesDot and matlab.mixin.CustomDisplay. Subclassing these classes allow me to both display the properties of the LinkedFiles instances as properties of MyClass, and I can access their values using dot indexing on MyClass.

What I dont have, is autocompletion for the property names of the LinkedFiles instances. So if VariableA is a property of a LinkedFile instance, I can not do MyClassInstance.Vari... and expect MATLAB to autocomplete.

I have read about functionSignatures.json, but as far as I understand, these are meant for function inputs and outputs, not for dot references.

Is there a way to achieve this?

Or should I rethink the way I am designing this?

Answer 1

[Kyle]

Hi Eivind,

Currently, tab completion does not support properties for classes which inherit from RedefinesDot. One reason is because the dot predictions would require running MATLAB code from your class's dotReference method. In most cases, tab completion relies on a properties blocks to know which properties should be shown.

Depending on the logic in your class, you could change your classdef to instead use Dependent Properties. These are declared in a properties block, so tab completion will know about them. This might fit your situation better than RedefinesDot, depending on what else is in your dotAssign, dotReference, and dotListLength implementation. Particularly, if you only wish to override behavior for the LinkedFiles property, this is much more targeted and will let MATLAB handle all other dot operations.

One thing worth mentioning is that both Dependent Properties and RedefinesDot can slow down your object performance if you put too much code inside of the indexing methods (dotAssign, dotReference, get.LinkedFiles, etc.). I recommend keeping overloaded indexing logic as simple as possible, especially if you index into these properties often, such as in loops.

There is one other alternative that doesn't use either. Get/Set Methods. These are very similar to Dependent Properties, but I don't think they fit your solution as well. Unlike Dependent Properties, Get/Set methods require the property to exist within the class. If you access it from within the class file, you bypass Get/Set methods. However, in your case, it sounds like the property doesn't really exist in your MyClass definition. It exists in your LinkedFile definition, and you want to refer to these other properties using custom logic. For that reason, a Dependent Property sounds more appropriate between the two.

Answer 2

[Eivind Hennestad]

Hi Kyle,

Thanks for this thorough information and your suggestions!

One of the ideas is that the LinkedFiles instances can be mixed and matched, and so declaring the properties in the owning class (MyClass) directly is problematic because I will not know beforehand which properties will be there. It therefore seemed like the RedefinesDot would be an elegant solution, but I am thinking now that maybe I have to use dynamic properties instead.

[Kyle]

Dynamic properties are a way to have particular instances have different fields than others. It might be the only way to get the behavior you are looking for.

It is worth noting that, while powerful, some class designs that rely on dynamic properties can get expensive. Try to avoid any implementation which requires you to frequently index into dynamic properties with obj.(propName) where propName is a variable. This syntax is considerably slower than obj.propName written directly in the file.

If performance is a concern, I would normally recommend using dictionaries for that kind of use case. These are designed around having named keys that are performant. A dictionary would be a single map of strings to values, which might integrate well with your existing CustomDisplay code. However, these runtime-dependent implementations often struggle with tab completion. So while they might run faster, it comes with the cost of your customized tab completion.

If tab completion provides you with a more convenient workflow, it sounds like dynamic properties will be the more effective choice.