Properties validation in subclass with multiple superclass but same ancestor

hello everyone,

I have a problem: I'm trying to build a (quite complex) super/subclassing tree for a project, but I'm stuck before MATLAB failed at instanciating an object deriving from multiple classes but that at the end derive from the same root object, and in this root object I defined an abstract property, with some validators, that should be define in the concrete object.

According to this page, it should works, but it does NOT work in my case (MATLAB 2024a; I plan to migrate to newer versions soon).

Minimum Workin Example (MWE) completely unrelated to my project:

let's suppose that i have to model several vehicles, so I can create a superclass called "vehicles" with some properties, including the minimum number of staff required to run it:

classdef vehicle < handle

properties (Abstract, Constant)

required_staff (1,1) {mustBeNumeric}

end

methods

function obj = vehicle()

end

end

end

Now, we can specialize the "vehicle" in several ways and multiple times, for example by creating a "landVehicle" class, a "bike" class (extending "landVehicle"), an "electricalVehicle" (all these classes may define something more, but for this MWE we can have them "empty" and it will not change) and finally the "EBike9000" that is an electrical bike.

Code for the "bike" class (the other mid-classes are similar):

classdef bike < landVehicle

end

Code for the "EBike9000" concrete class:

classdef EBike9000 < bike & electricalVehicle

properties (Constant)

required_staff = 1

end

end

Now, the only definition and validation for the required_staff property is in the root "vehicle" class. The middle class never mention it, however, when I tried to instantiate an EBike9000 object, matlab complain with:

Error using EBike9000

Class 'electricalVehicle' and class 'bike' both define validation for

Abstract property 'required_staff'. When inheriting property validation,

only one superclass can define validation for property 'required_staff'.

However, this validator IS the same since it belong to the same superclass, so it should NOT be a problem for MATLAB to validate it (as also stated in the page I linked at the beginning).

So, what's going on? is this a bug, or it's me that I'm missing something? Ideas for some workarounds (except including a set.required_staff method which on all the possible vehicles around)?

[Matt J]

It does seem like a bug to me, though they might tell you it is a documentation bug. I.e., when a child class has multiple inheritance paths tot he same parent, the documentation may have meant to say it is to be treated as though the child inherits multiple copies of the parent.

[Umar]

Hi @Jacorem,

From what I can see in your code, since both bike and electricalVehicle ultimately inherit from the same vehicle class where required_staff is defined, MATLAB should recognize it's the same property validation rather than treating it as conflicting validations.

A few potential workarounds you might consider:

*Define the property validation in an intermediate class that both inheritance paths go through.

*Use composition instead of multiple inheritance for one of the paths.

*Override the property validation in your concrete class explicitly.

Matt J's comment about this potentially being a documentation vs. implementation issue sounds plausible - it might be worth filing a bug report with MathWorks to get clarification on whether this is intended behavior or a bug.

You might also get more targeted help from MATLAB's technical support since this seems like it could be a edge case in their inheritance implementation. Hope this helps.

[Jacorem]

Thanks @Matt J and @Umar for your comments.

I think that I will follow Umar advice and open a bug report.

For now, as a workaround, I just commented out all my validations (and hope that I will not mess around without them, sigh).

The idea of having a _init method for each class wasn't bad, but at the same time I would like to have the properties constant (in my example, all the EBike9000 need 1 person to run, so why I need to create/have a specific bike to know that?), while some of the workarounds suggested by Umar (I'm thinking mainly to point 1 and 3) are really against how Mathworks implemented OOP in Matlab and there are several entries in this forum discussing them (I checked before opening a new question): the basic idea is that if "required_staff" is a number for all the vehicles, why it should be some text for the bikes? And if so, how the methods in the "vehicle" superclass should be aware of it/handle this edge-case scenario? The same apply on the other way round or in any case when the validations are different.

Answer 1

[J. Alex Lee]

i just tried this MWE on 2025a update1 and it did not give me an error on instantiating EBike9000.

classdef vehicle < handle
    properties (Abstract, Constant)
        required_staff (1,1) {mustBeNumeric}
    end
    methods
        function obj = vehicle()
        end
    end
end

and

classdef landVehicle < vehicle
	methods
		function this = landVehicle()
		end
	end
end

and

classdef bike < landVehicle
	methods
		function this = bike()
		end
	end
end

and

classdef electricalVehicle < landVehicle
    methods
        function this = electricalVehicle()
        end
    end
end

and

classdef EBike9000 < bike & electricalVehicle
    properties (Constant)
        required_staff = 1
	 end
	 methods
		function this = EBike9000()
		end
	end
end

[Jacorem]

Yep, indeed, after contacting the support, the guy who got my ticket try it in both versions (2024a and 2025a): in n2024a it got an error and in 2025a it di not, so it seems that this "bug" was (silently) fixed between the two versions.

This also means that I either have to update to the new version (which I would like to avoid since I risk to break LOTS of code) or go on without the validation. I choosed the second.