http://www.mathworks.com/matlabcentral/fileexchange/loadFile.do?objectId=18223&objectType=FILE

function obj = myQuasiObject
..

with some nested functions

function nestedFunction1
..

function nestedFunction2
..

then create structure ‘obj’, and add to it

(a) arbitrary values (these are your class properties),
(b) handles to the nested functions (these are your class methods).

Voila! Class myQuasiObject is ready to instantiate

obj = myQuasiObject;

and manipulate – with the customary ‘dot’ syntax not available with Matlab’s ‘frontdoor’ objects.

obj.nestedFunction1

Not being able to have private properties and methods is a nuisance, but inheritance seems to be alive and well: why not invoke one ‘object function’ from within another?

Is this added functionality a good thing? I think that Loren’s code – just touching on the matter, really – gained but a tiny bit of syntactic sugar from not using a ‘normal’ class, with a transparent constructor and methods. On the other hand, consider this FEX submission, a purposeful play on persistence and scope implications of the ‘backdoor objects’ approach

http://www.mathworks.com/matlabcentral/fileexchange/saveRating.do

for an example of how one can create a debugging nightmare in less than 20 lines.

When the function handles are constructed in the same environment (same function, workspace and during the same invocation), they DO all share the same workspace – no extra copies. That’s how they can do the near magic that they can.

–Loren

The one thing I wonder about is memory usage. I don’t really understand what gets stored into a function handle. I know that a function handle “contains” all the variables in its scope, but I’m not exactly sure how. If you create an object in the way described here, consisting of a struct with numerous function handles, I’m assuming that each handle effectively “points” to the same shared workspace of variables? this would be quite cheap and acceptable, even if the data in that workspace became quite large, since there would only be one copy.

I became concerned that the reality may be more memory-wasteful, when looking at the documentation for function handles and nested functions, which says
“What in fact happens though is that MATLAB stores variables such as VExt inside the function handle itself when it is being constructed.” (see the documentation for nested functions).

This can’t be correct, right? this would lead to the situation where each function handle had its own workspace.

But on the other hand, I find it somewhat magical that each of the function handles ends up pointing to the same workspace (what I want/hope to happen). It seems then that as you create a function handle, the interpreter must check to see if a workspace with the same variables in scope exists, in which case it doesn’t duplicate the workspace, but rather “points” to the first one. Is this what happens?

Michael, are you willing to share your OO framework? I would love to be able to use something like this in Matlab.

Dear Loren,

I regularly use the nested function trick for numerical computation. It makes life so much easier… However I find the usually fantastic help tool a little weak on this side.

I therefore had to write a tool for that (hyperSubFunHelp on MCFE). But I think an easy to use tool for displaying help about subfunctions is definitively lacking (help function>subfunction is not really easy to use).

Regards,

Mathias

Ok, what does that mean…

In practical terms, it realizes what is shown in the second block of code, above. I.e., if a is an object then b = a refers to the *same* object, not a copy. If each field on the struct representing an object is a function handle, all copies of that struct have the same function handle values and they all point to the same thing.

Here’s a practical example of how direct access breaks this:

Modify the example, above, by adding a field, age, directly to the class structure:

function obj = foo

name = ”;
obj.age = [];

obj.name = @accessName;
function out = accessName(in)
if nargin, name = in; end
out = name;
end

end

Now, create an instance (object) of the foo class and set its attributes:

>> a = foo
a =
age: []
name: @foo/accessName
>> a.name(‘Arthur Dent’); a.age = 42;
>> disp( a.name() ); disp( a.age )
Arthur Dent
42

Copy it:

>> b = a;
>> disp( b.name() ); disp( b.age )
Arthur Dent
42

Now modify the first one:

>> a.name(‘Ford Prefect’); a.age = 612;
>> disp( a.name() ); disp( a.age )
Ford Prefect
612

But the second one is broken since the age is still the value it had when you did b = a :

>> disp( b.name() ); disp( b.age )
Ford Prefect
42

So, “b” is a partially-connected twin of “a” from the Island of Doctor Moreau… a misshapen creature that likely would cause heinous bugs in your code!

The way to think about stuff in the OO paradigm is as things that interact with each other purely by messages. A message to an object asks it invoke an operation that transforms its state, returns a value (which, purely speaking, itself would be an object…), or does both. You don’t want the outside world to go messin’ with an object’s state directly, just via the set of messages it can respond to. The set of valid messages defines the interface that the object presents to the world. How it does things, behind the curtain, is hidden. That’s what one means by encapsulation. (Ok, there’s more to it… see the Encyclopedia Galatica, or, wikipedia as a starting point for more…) It enables all sorts of crunchy goodness – good modularity – when applied properly.

Usually (but not always in all languages…), a message consists of the method name and its arguments. E.g. in the syntax used here the method invocation a.name(‘Bart’) is sending the message ‘name’ with the argument ‘Bart’ to the object referenced by ‘a’.

In OO hackin’, when you’re creating a bunch of objects to do something useful, you usually want to have objects each have references to several of the other objects so that they can interact with each other.

E.g., A bunch of person objects (a collection of person objects)named “dude”,”biker” and “hacker” all walk into a room object. The room object already contains a collection of person objects, “boring guy”, “Alan Kay” and “hot babe”. The new guys get added to the room’s collection of persons. Each one of the new person objects wants to iterate over the collection of persons in the room (skipping themselves, unless they have multiple personalities…) to execute the “scope_em_out” method on each person in the room – i.e., each new guy wants a list of references to each person in the room collection. Then they can choose their next message, if any, to send to one or more of the other persons (“dude” and “biker” both send “hi_howyadoin?” messages to the “hot babe” and to each other while “hacker” is totally into a “talk_with_guru” message to “Alan Kay”…).

BTW, Alan Kay and the rest of the brilliant gang at Xerox Parc were the inventors of Smalltalk, a ‘pure’ object language, starting around ’69. There’s a fun, open source version still around and kickin’, called Squeak, and some commercial versions that a few companies still quietly use to get a lot done. Smalltalk is one of the few imperative languages even more fluid to hack than Matlab since one can actually change code *while it’s executing*. A good portion of the Squeak community are educators who use it to get kids (even elementary school) into programming in a really fun environment.

That was probaby waaaaaay more than you wanted, wobbly!…

Happy Matlabing!
Michael

I am begging to know: 1. if what we see in the matlab files will change much ie see memmapfile, 2. when will mcos be officially released.

The current oops system is very difficult to use if you want to have proper fully functional class. And trying to do it with just nested functions isn’t ideal either.

Please please oh please let us know when mcos will be available.

Like Sean, I’ve been using closures with nested functions and function handles to do ‘lightweight’/'pseudo’ OO (lacking inheritance) since their introduction in 7.0. I was inspired by similar patterns in Scheme.

I also use anonymous functions quite a bit. Incidentally, by using anonymous functions (lambda functions…) one can hack many of the examples in the first chapters of the classic, “Structure and Interpretation of Computer Programs” (http://mitpress.mit.edu/sicp/). This is a great way of getting a little taste of functional programming vs. the procedural, imperative paradigm that 99% of Matlabers probably are more used to.

A massive advantage to using closure objects can be that a function handle reference to an object (instance) method provides pass-by-reference, so, e.g., the same instance can be referenced in multiple collections. This leads to the second massive advantage: persistence. As long as there is a reference to the object its enclosed state exists and anyone who has a reference to it can use it. There is no need to use globals ever again (DEATH to globals!), except, perhaps in exceptional circumstances.

In order to realize a closure object as a ‘pure’ reference the structure returned by the main, enclosing function (effectively, the constructor) must be only a structure of function handles (or a single function handle pointing to a dispatcher). Loren’s example, volumeVisualization, breaks this a bit by putting some mutable state onto the structure, but that could be fixed easily.

All access to internal state should be through accessor methods. As a hint, a convenient, minimalist accessor providing both get and set is shown by this example:

function obj = foo

% variables in the enclosing function are attributes
name = '';  

% provide accessors for the ones you want to be 'public'
obj.name = @accessName;
  function out = accessName(in)
    if nargin, name = in; end
    out = name;
  end

% other methods change state (provide behavior)
...

end

Then….

a = foo;
a.name('I am a foo');
a.name() -> 'I am a foo'

b = a;
b.name() -> 'I am a foo'   % reference to the same object

I’ve implemented several variants of OO frameworks based on closures that add inheritance. Even the somewhat bulky, first forms (they carried a lot of boilerplate…) were more useful than the (pardon the editorializing) mega-clunky, native ‘class’ framework in Matlab. My latest versions are far more concise and have been optimized for performance. This gives me ‘real’ OO within the Matlab, my favorite engineering bat’leth, the one that I use almost every day on my desk and in the lab.

Another neat-o-keen aspect of this approach is that classes can be defined within classes and/or multiple classes can be defined within the same .m file, rather than in the plethora of .m files within a @foo directory.

Loren’s example shows how nice it is to be able to compose objects. That way, you can cleanly encapsulate closely related responsibilities for a behavior into an individual objects and then compose several of those objects to solve a particular problem.

As a parting shot, for anyone getting into hacking OO for the first time, some excellent essays on fundamental ‘good principles’ by Robert Martin can be found at: http://www.objectmentor.com/omSolutions/oops_what.html. The OO paradigm is just another tool – one can write either beautiful or hideous OO code…

I echo Sean’s sentiments about GUIDE. Building a replacement has been on my to-do list for ages and I’m not surprised that he and his colleagues have done it.

Cheers and happy Matlab hacking!

Michael