Go to content Go to navigation Go to search

xeno
form

Category

Search


Links

Things that I would like from Matlab: Better Object Orientation · 2006-10-23

For a long time now, it has been possible to create classes in Matlab. Sort of. Except that there’s no pass by reference, so calling a set() method on a class has no real meaning. My biggest problem with Matlab’s classes though are that they require the @classname directories with individual m-file function underneath.

If I wanted private methods in my class, I would create another folder named private and stick more m-files in there.

So as it stands, if I wanted to create a class myclass that contained two public methods, foo and bar and some private functions, I would create a directory structure like so:

@myclass/
    foo.m
    bar.m
    private/
        priv1.m
        priv2.m

For some applications, this approach works well enough, but when we consider one or two line functions, having a dozen m-files becomes quickly painful.

But what other approach is there?

Since R14, Matlab has had named inner classes. Conveniently, these inner classes share the workspace with their surrounding classes, but their surrounding function does not share a workspace with them. Also, inner functions within a single function are able to access eachother. Now how hard would it be to introduce a class keyword (or something else since class() is already a function) that encapsulates a number of inner functions. Each function would be public, a la Python (or introduce public, private, protected keywords) and an entire class could be published in a single file, like every other language out there.

For example, we could rewrite the above set of m-files as:

class myclass
    function foo(x, y)
        % Some stuff happens in here
    end

function bar(a, b) % Some more stuff happens in here end end

Supposing that we wanted our class to inherit from something, we could easily write myclass(yourclass) or something similar to denote inheritance.

Now, we have a self contained class that requires only a single new keyword (putting in private methods might take a little more, but Mathworks could be lazy and use double underscores or something like Python). Like before, there is no access to internal variables, but we have the same functionality while being much easier on developers.

So, any Matlab gurus or Mathworks engineers out there that can tell me why this is a terrible idea?

Oh, could we get interfaces or abstract classes too?