(2018a) Implicit Call to Inherited Constructor is not available when used in a package

Hi All,

The goal is to try the new feature of Matlab 2018 using a package. In each of the examples there is a super class and a subclass. The subclass has no constructor but the superclass expects a input argument. In the case without a package this works fine as advertised in the release notes. In the case with package there is an error.

[Adam]

It looks as though this is just another one of the annoyances from working with packages, in the same way that even when you are calling a package function from another function within the package you still have to explicitly use the package name and when using classes there is no way to import the package into the whole class scope so you have to refer to it in each function individually potentially, including the constructor.

The only example I can see in the documentation with packages does show implicit calling of the base class constructor although it doesn't explicitly say that this is necessary when using a package, but clearly it is:

https://uk.mathworks.com/help/matlab/matlab_oop/subclass-constructors.html

[alex_7]

Hi Adam,

thanks for your reply. The only reason why I want to use a package is because I need to instantiate a class from a string (without using feval, this link is explaining how https://stackoverflow.com/questions/7102828/instantiate-class-from-name-in-matlab). Do you know if there is any other way to do that?

[Adam]

Take a look at the second answer in that link. I would be suspicious of the requirement to need to do this in the first place though and would probably use some kind of factory type method. this doesn't need to be fancy. Quite often it would simply take the form of a series of if-else statements (or a switch) that create the correct type of class based on an input string.

This looks ugly, but such a function would have a context which would naturally limit the number of possible class types it would be creating. If you are trying to create a class based on some completely arbitrary string then something is going wrong with your design. As for the ugliness, ugly code is OK in certain places and factory functions are one of these places. A series of if-else statements or switch cases are easily readable and keep the ugliness contained in one place.

[alex_7]

There is a limited number of class types, that means that I am not trying to create a class based on arbitrary string. The drawback of if-else statements is that if a new class type is available then another if statement has to be implemented. Anyway it seems that there is no solution to the problem and have to create constructors for the subclasses. Thank you very much for your time.

[Adam]

What is wrong with the str2func approach if you really must do it this way?

Having to add an extra if-else clause may be seen as a drawback, but can also just be seen as part of extending a piece of tight code in an explicit way that forces you to ensure that the new case is satisfied. A very generic answer that can just create any type of class from any type of string may seem much nicer, but is also far more open to bugs and misuse, in the same way that just making every function and property of a class public makes it appear 'simpler' to use, but ultimately creates a mess.

Answer 1

[Guillaume]

I agree with Adam there are a lot of inconveniences that come with packages, so I've given up on them entirely.

I also completely agree with Adam, you should create a class factory. You can either implement that as a free function or as a static method of an abstract superclass of all your classes, or as a static method of a factory class.

The implementation of the creation code itself can also be done several ways as well, using if/else statements as Adam suggested or even with eval. That's one use of eval that would be perfectly valid. If all your classes derive from an abstract base you could even check that your string is indeed a valid class using meta.class. eval has the advantage that you indeed don't need to change anything when a new class gets added to the list.

And if the package issue gets fixed, you can switch to the package method suggested on StackOverflow if eval is disturbing.

Answer 2

[Sean de Wolski]

I had to do this for an application I worked on where I wanted to have an unknown number of models in a package and to be able to scrape it and construct all classes that inherit from the same abstract base class as Guillaume describes.

This is also how the unit test framework creates test suites fromPackage or fromFolder (that's where I got the idea from).

    methods (Access = protected)        

        % Figure out model trainers to use
        function setModelTrainers(obj, modeltrainers)                        
            if isempty(modeltrainers)
                % Grab all classes in model trainers package
                mt = meta.package.fromName('LoadForecaster.Prediction.ModelTrainers');
                classes = mt.ClassList;

                % Determine which ones are of the correct type
                for ii = numel(classes):-1:1
                    switch obj.ModelType
                        case 'Regression'
                            idx(ii) = ismember(?LoadForecaster.Prediction.RegressionTrainer, classes(ii).SuperclassList);
                        % Add more cases to add classification, etc.
                    end
                end

                % Set
                obj.ModelTrainers = classes(idx);
            else
                % Use passed in ones
                obj.ModelTrainers = modeltrainers;
            end

            % Loop over model trainers building a function to the call the
            % constructor.
            for ii = numel(obj.ModelTrainers):-1:1
                obj.ModelTrainerConstructors{ii} = str2func(obj.ModelTrainers(ii).Name);
            end

        end

    end