Here's an update on the state of class objects for Octave. This work
is all available on the CVS branch with the tag "object-branch".
Private functions, class constructors, and class methods should all
work now.
If it is defined, the "display" method of a class is called when
Octave displays a class object.
Operator overloading works for the following operators when at least
one of the arguments is a class object:
unary operators
operator function name
-------- -------------
~ (or !) not
+ uplus
- uminus
.' transpose
' ctranspose
binary operators
operator function name
-------- -------------
+ plus
- minus
* mtimes
/ mrdivide
\ mldivide
^ (or **) mpower
< lt
<= le
== eq
>= ge
> gt
.* times
./ rdivide
.\ ldivide
.^ (or .**) power
& and
| or
The subsref and subsasgn methods are called when Octave does indexing
and indexed assignment for class objects.
The methods function can display all the available methods for a given
class.
Some things that are not done yet:
Operator overloading for built-in types. For example, writing a
function @double/plus.m does not yet work to overload the addition
ooperators for the built-in double-precision array objects. I
don't see this as a big problem because I think most
The superiorto and inferiorto functions to control precedence of
classes for dispatch.
Inheritance.
To support the new way of doing dispatch, the symbol table code has
been completely rewritten and the interface has changed significantly.
I think I've restored most functionality except that the lookfor
function is still broken. Some cleanup also remains to be done (for
example, I think it would be reasonable to eliminate the
variables.{h,cc} files now, merging most of them with symtab.{h,cc}).
To make it easier to merge these changes on the CVS trunk later, I've
been periodically merging the changes on the trunk to the object
branch. The latest merge was done today, so the object branch should
contain everything that is on the trunk plus the changes for class
objects.
It might be useful at this point if people who use objects could check
out the object branch, build it, and give it a test drive. I'm sure
there will be some problems and that many features are still missing,
but it would be good to know which ones people actually use. That way
we can avoid wasting time implementing unimportant or unused features.
jwe