Re: classes and private

[Paul Kienzle]

On May 14, 2004, at 11:55 AM, Paul Thomas wrote:

> Do you mean the underlying classes for the standard Matlab types or 
> classes in the Matlab language?  I presume that it is the latter.....
>
> If you are contemplating taking this on, can I get in my 10 cents 
> worth, please?
>
> Having written applications for Matlab with my own classes, I must say 
> that I am not very convinced that theirs is the way to go.  It is 
> striking that once a good number of operators and intrinsic functions 
> are overloaded, the @mydatatype directory becomes seriously filled 
> with files.  This means that, for a complicated class, with many 
> functions, you have to get the design right first time.

Isn't that always the case? ;-)

>   Otherwise, the modifications span a large number of separate files.  
> I would much prefer a function that calls on a single class definition 
> file, which defines the objects, the actions of operators and the 
> functions.

I'm interested in what it would take to support the code that is out 
there built on classes.  I don't mind in this case if the user has to 
run a translation tool to get them working because they are not 
commonly used.

That said, the simplest implementation will leave things in separate 
files:

(1) Every function in the @class directory will need a dispatch() set 
up.  That's easy enough.

(2) Objects are just structs with a class name.  Subclassing the struct 
class will give us arrays of objects --- all we need to add is the 
class name and its parent.  Populate the operator table for objects 
with calls to plus(), minus(), etc, and we can use normal function 
dispatch to call the right function.

(3) Currently dispatch only looks at the first parameter.  That's good 
enough for most purposes, but there are cases (e.g., the binary 
operators) where you want to chain off the second parameter.  I don't 
like the idea of cycling through every parameter to find the one with 
the highest precedence on every function call, but I don't see any 
other way.

Support for private functions will be trickier.  The obvious thing to 
do is modify function lookup to check for a name in a private function 
table limited to the private directory before looking in the main 
function table.  If it is found, then treat it like a function which is 
private to a file.  The path search library will need to know not to 
descend into private directories.
This will require changes to the interpreter.

The alternative is to rename package/private/name.m to 
package/package__name.m, and change all calls to name in package/*.m to 
call package__name.  A simple perl script should be able to do that so 
long as no private functions are called from eval.

Paul Kienzle
address@hidden