Thanks.

I agree on pushing on that sealing issue. What can we do? It would be great to subclass some graphics elements.

I totally understand where you are coming from – the benefits to users of subclassing are clear, as you’ve articulated. That said, I still believe we need to proceed very carefully if we intentionally open up parts of MATLAB that we aren’t committed to keeping as compatible as possible over time. You refer to the risk as “potentially making life a bit harder for MathWorks developers one day”. I see it very differently – I see the primary risk to our users, not MathWorks developers. Our developers evolve the product to meet demand from our users; constraints on changing underlying implementation and architecture can significantly hinder our ability to keep up with user demands. Of course, nothing is black-and-white – you know better than almost anybody about the trade-off between getting capabilities now and code potentially breaking in the future.

I’m intrigued by your notion that developers have a different expectation of compatibility when subclassing than they might have when calling documented programing interfaces directly. I’ve long been interested in figuring out “safe” ways for us to give advanced users more flexibility while still managing release compatibility expectations, so maybe this points in a fruitful direction. I could imagine a world where we set expectations that subclassing is not guaranteed to work in the future. I can see this working in a direct conversation with the developers who subclass, but I really worry about the downstream user who relies on this subclassed code who doesn’t know why their code broke with a new release, has no idea how to fix it and potentially no ability to get the author to fix it, either. This reflects the nature of how a majority of MATLAB code spreads in the wild today.

As always, I encourage other readers to jump in with their perspectives. Yair and I could discuss more next time we meet.

@Eric – I really appreciate the fact that you took the time to post your comment and state MathWorks’ position on this matter publicly. This is not taken for granted at all.

However, I have to tell you that I find your reasoning for sealing Matlab classes perplexing to say the least. Please correct me if I’m mistaken, but I believe that Java, C++, C# and VB.Net — to name just a few well-known object-oriented programming languages/environments, all of which have far greater following than Matlab — have not seen fit to seal their classes in the general case (GUI/graphics included), and I do not think that this has ever hampered their growth. The same can be said for many if not all of the numerous commercial and open-source libraries that MathWorks uses within Matlab.

Any user who extends a built-in class, in *any* programming language, knows full-well that this might break in the future. This is still much better than not being able to accomplished the requested functionality today. Such users might tell themselves that since the other platforms are not as limiting, it might make sense to drop Matlab in their favor.

Limiting users’ ability to use Matlab today, under the vague notion that this might possibly make life a bit harder for MathWorks developers one day in the far future, is IMHO plain nearsightedness. On the contrary – let the user community extend the built-in Matlab classes, and then you could incorporate the best of these extensions in future Matlab releases (at no expense to MathWorks!). Just my personal ¢2, please don’t kill the messenger…

Kudos for bringing up this Sealed issue; I couldn’t have agreed with you more. It is indeed a perplexing decision that hampers one’s work.

I have first encountered this problem while updating the old Cursorbar to the new HG2 engine. Since Cursorbar needed — on top of a plethora of new properties — events and methods with arguments, and since it had to be “real time,” the simple solution of addprop just wouldn’t suffice. It would have been much easier to subclass either Group or some other handle graphics class; alas, being not the case, I had to wiggle myself around to keep the desired behavior and compatibility with handle graphics. As you can imagine, it came with some cost, and some things still don’t work properly as a result.

I believe the Matlab community should press strongly on this matter. Maybe, a shared “new functionality” request between many people or a petition of some sort will do the trick. In any case, it would help to hear a clarification from Mathworks about this decision; perhaps, they have some reasons we’re unaware of.

Cheers and keep up the good work.