Will the old-style class definitions be supported in future version of Matlab?

I have code with the old-style class defintions. Has Mathworks the intention to stop with the old-style?

Answer 1

[John D'Errico]

One thing you cannot realistically ask on Answers (if you expect a fully valid answer) is what decisions about MATLAB will be made in the future. I'm sorry, but Answers is a volunteer supported forum. Strictly volunteers. Even those employees (their names will be typically labeled staff) who do respond to questions are doing so on a volunteer basis. And even they cannot state firmly what decisions will be made, since even if they know the answer to your question, anyone who does know is also limited by non-disclosure agreements.

Given all of those caveats, you need to appreciate that we cannot answer your question.

However, you also need to understand two facts. First, I have code that is 40+ years old that still runs as well today as it did then. (Geez, am I that old?) The point is, MathWorks tries very hard to ensure that code is forwards compatible. If it ran in an old release, then they want it to run in future releases as much as possible.

The second fact is, MATLAB is an evolving language. It must do so, as anything that does not evolve in a changing landscape will die. And sometimes, sometimes, those two goals will conflict. That is, sometimes, they will decide a change simply must be made, and an old form that previously worked in an old release must go away. The solution there is they will do so slowly, as slowly as possible. They will give you warnings in advance, telling you that some syntax will in some future release go away. The warnings might start with a simple suggestion, like the one in the help for findstr.

help findstr

 findstr - (Not recommended) Find string within another, longer string
    This MATLAB function searches the longer of the two input arguments for
    any occurrences of the shorter argument and returns the starting index
    of each occurrence.

    'findstr' is not recommended. With appropriate code changes, use
    'strfind' instead.

    Syntax
      k = findstr(str1,str2)

    Input Arguments
      str1,str2 - Text to Compare
        character vector | string scalar

    Examples
      openExample('matlab/FindTextArrayElementsThatMatchStringExactlyExample')

    See also strfind, strtok, strcmp, strncmp, strcmpi, strncmpi, regexp,
      regexpi, regexprep, contains

    Introduced in MATLAB before R2006a
    Documentation for findstr
       doc findstr

    Other uses of findstr

       opaque/findstr

As you can see, it gives you the hint to not depend on findstr, to instead use strfind. And that subtle hint has been in the help for findstr for many years. Sometimes (I'm sure as soon as I hit submit on this answer, I'll think of an example) the warning will be more strident. And sometimes a syntax will continue to work, but they will completely remove documentation for that syntax. I'm thinking here of the trick to pass additional variables in the optimization toolbox. If you have used MATLAB for long enough, you will know what I am talking about. But current releases have not even mentioned that capability as an option for many years now. (Honestly, I don't even know if it still works, as the alternatives present now are so much better.)

The point is, TMW makes great efforts so such syntactical changes happen slowly and gracefully. They try never to pull the rug out from under you. You must accept though, that if MATLAB has two syntaxes that do EXACTLY the same thing, but one of them adds some new useful functionality, then the old one will possibly one day go away. It might take years for that to happen. But it is probably a good idea to slowly transition any code you have, and your writing style, to the newer syntactical form.

[Jan Karelse]

Thank you John, for your answer and your thoughts and experience with these kind of topics. It is much appreciated! In hindsight I agree with you that TMW will most likely warn way before in case functionality is going to be removed. So I will watch for the signs like you recommend. Also in my experience (using Matlab 27 years professionaly and that explains why I still have some old-style classes :-) ) the forward compatibility is really excellent.

Best regards

Jan

[John D'Errico]

One thing I would consider is to be willing to do a code rewrite, at least, don't fear the idea. I recall one code that I wrote and rewrote 7 times. I hope I got it right eventually. Maybe, maybe not. But each time I did it, the code got better. I added new features. And sometimes those rewrites were because new functionality was introduced into MATLAB. When sparse matrices were added to MATLAB, for example. Suddenly things got hugely faster, and I could solve vastly larger problems.

But the point is, that a rewrite will often take less time to write than the original, and will be an improvement in many ways.

[Steven Lord]

And of course, before doing a code rewrite, if you don't have tests for your code I strongly encourage you to add them. If you're familiar with function-based class definitions then writing function-based tests shouldn't be too difficult. You can use those as you're reimplementing your class to be more confident that your new implementation behaves the same as your old implementation. Or if you need to familiarize yourself with classdef-based classes, you could try writing class-based tests.

And FYI, you can define (most types of) methods for classdef-based classes in separate files, just like you could (were required to do) for function-based class definitions. [The constructor has to be defined in the classdef file, as do any methods whose names include . (property accessors, converters to classes in namespaces.)]

Answer 2

[Steven Lord]

Looking at the Release Notes for MATLAB for release R2025a, there are two relevant notes. One states that classes defined using functions [that internally call the class function to turn struct arrays into objects] will not be supported in a future release (these types of classes have been around since before I started at MathWorks in 2001) and the second states that classes defined using schema.m files will not be supported in a future release.

However no time frame has been given for the removal of that support in either case. I don't know exactly what that time frame is and even if I did I would not be able to say (John is correct about NDAs.) As one data point, the first of those notes was added to the Release Notes in release R2024b, while the latter was added in or before release R2021a. So if you have both types of class definitions, I'd probably focus on migrating the ones using schema.m to classdef first.

We do take backwards incompatibility seriously; when someone proposes a significant change there's a process to discuss its impact on users, both internal and external, and assess whether it's the right thing to do. ["Significant" is doing a little bit of lifting there; in theory any bug fix or new feature could be considered an incompatibility. But if the change is something like "MATLAB used to crash, now it doesn't" the "make the change or don't make the change" part of the discussion is likely to be very short. There could still be some discussion about how to make the change, "Should MATLAB do A or B instead of crashing?"]

To John's point about functionality sometimes still being supported but no longer being documented, the behavior to call class with two or more input arguments (a struct, the name of the class being constructed, and potentially superclasses IIRC) inside an old-style class constructor function is not documented on the class documentation page.

[Jan Karelse]

Thank you very much Steven for taken the time to answer my question! My takeaway is to start migrating the code piece by piece. Regards Jan