Change in OOP programming between 2014a and 2016 - Structures not recognized anymore?

Hello all,

I'm working on a project that was coded in 2014a version and trying to bring it up the MatLab versions. I tried to bring it from the 2014a to 2016a version but I seem to have an issue with how the Object Oriented Programming files are handled by Matlab.

Here's a 'picture' of my directory :

I have an issue where Matlab says that :

Warning: 'bbb.ccc.ddd.eee.fff.ggg.B_AutomaticTransformation' exceeds MATLAB's maximum name length of 63 characters

and has been truncated to 'bbb.ccc.ddd.eee.fff.ggg.B_AutomaticTransformatio'.

....

Undefined variable "aaa" or class "aaa.bbb.ccc.ddd.eee.fff.ggg.B_AutomaticTransformatio".

Error in ... (line ...)

oPlugin = aaa.(sPlugin(6:end))(this, oParent, oGUI, varargin{:});

Has something changed in the way files and folders are handled my Matlab / OOP in the transition from 2014a to 2016a as it's working in the 2014a version?

Also, I'm going from 2014a to 2023b versions of Matlab. Is a 'stop' at the 2016a version before going to the 2023b version worth it?

Thanks !

[dpb]

Look at the release notes for R2016b...depending on whether you still have support or not, the online documentation may or may not let you actually compare the two specific versons; you may have to read the local release notes for each version and may not be able to get to the intermediate versions at all...

I suspect you may have to submit an official support request for this.

On the other Q? I don't know why you chose R2016a as an intermediary, anyway? Although it isn't such a big jump of only two calendar years as opposed to nine...but, it looks like it will be problematic to move the present structure over no matter what unless Mathworks would have a workaround or porting tool of some sort if, indeed, there was a new restriction imposed. But, otoh, I thought that had always been a symbol length limit, but have to admit I've never even come close in practice.

[Walter Roberson]

Note by the way, that as of R2025a (currently in pre-release), the length of identifiers supported by MATLAB goes from 63 to 2048.

[dpb]

"...the length of identifiers supported by MATLAB goes from 63 to 2048."

I thought it had always been 63, but @Gauthier seems to show that at least for folder hierarchies R2014a (and maybe earlier??) could handle more than later releases...

[Steven Lord]

I believe the maximum identifier length has been 63 for at least two decades, but there was a time before that when the limit was 31.

From that small out-of-context code segment I can't be certain what the code is trying to do, but that's an awful lot of levels of namespaces (previously called packages.) Do you really need seven levels of namespaces, where ggg is a sub-namespace of the sub-namespace fff of the sub-namespace eee of the sub-namespace ddd of the sub-namespace ccc of the sub-namespace bbb of the namespace aaa? That's a mouthful!

[Walter Roberson]

I am surprised that the length of the fully-qualified name is restricted. There does not seem to be good reason for that. It would only take 4-ish reasonably named levels to run across the limit.

[dpb]

I dunno about Linux, but Windows Win32 API has a total path length limit of 260 characters unless the application uses the long fllename prefix "\\?\" and the particular API has a Unicode version. Beginning sometime in Win10 there's also a registry entry that can be set to enable long file names, but that again is effective only for applications which register as supporting them.

But a total limit of 63 seems like a coding mistake comparing the wrong things.