Derived Objects and OOP

[John W. Eaton]

On 14-Mar-2009, Robert T. Short wrote:

| Attached is a changeset and some associated tests and commentary for a 
| partial implementation of derived classes.
| 
| There are some "FIXME" comments in the code (2) for things I really 
| don't know how to do.
| 
| The attached tgz file include "NotesOnClasses" that describes what I 
| have done and why.  Also in the tgz file is a test script "ClassTest.m". 
| 
| There is still one major thing that has to be done before this is really 
| useful.  Assigning the result of a method in a parent class to the 
| derived class doesn't work.  See the test script "ClassTest.m" for 
| examples.  As yet I have not figured enough of this code out to have any 
| idea how to do this.  In the "NotesOnClasses" file are other issues that 
| have to be resolved, but mostly they are secondary in the sense that it 
| will be possible to write useful scripts without the change.
| 
| Comments are solicited:
| 
| 1.  I am not sure I am really using mercurial correctly.  I made my 
| changes, then
| 
|  > hg commit
|  > hg export changesetid > changeset
| 
| 2.  I tried to emulate the coding style, but probably missed.
| 
| 3.  Maybe this is all nonsense and there is a better way?
| 
| This should certainly not be included in 3.2 since it is incomplete and 
| since the number of files touched is small, I am not sure the patches 
| should even be applied yet, but I would really like comments.

I applied the patch with some additional changes, including adding
ChangeLog entries.  I'd like to have this in 3.2, primiarily because I
know of some code that I would like to see running in Octave that
relies on the inheritance features.  I know, I've been arguing for not
delaying the release by adding new features, but I don't think this is
too disruptive because classes are a new feature so a regression in
behavior from 3.0 isn't likely to be due to adding inheritance, and it
shouldn't cause trouble for classes that don't make use of the
inherintance feature.

| Finally, if the person that wrote the original code has sample scripts 
| and classes that could be shared, then I can run regression tests and 
| eventually build a good integrated test suite.

Unfortunately, I don't have any test suite.

Quoting from the notes file included with the tarball:

| - Do private functions work right?

I haven't checked, and am not sure what needs to be checked.  Can you
write some tests for the features you expect to work?

| - load/save

What is supposed to be saved?

| - Assigning a class to the result of a parent method doesn't work.  See
|   the script "ClassTest.m" for examples.

I don't understand what you mean by this.

| - "clear classes" should clear the parent list in load-path.

OK.  Should we really be storing the parent info in the load-path, and
searching it in find_method?  Or should that logic be in the symbol
table lookup code, with the list of parent classes stored somewhere
else (perhaps in the symbol table)?  I'm not sure what is best, so I
left it alone for now.

| - "isa", "which" and ??? don't work right.

I made isa work by writing a __parent_classes__ function that can take
an object and return a cell array of parent class names.  Does Matlab
provide a function that returns a list of parent classes for a given
object?

How does the "which" function need to change?

| - Regression testing on polynomials or other tests defined by other
|   developers.

It would be great to have additional tests.  Since objects require
class functions defined in files in directories with special names,
this may require some changes to the test suite.  I suppose we can
just add new class code to the test directory and run some tests
there instead of embedding the tests in the source code as we would
prefer to do for most test functions.

| - The "dispatch_class" member of the function class should probably
|   indicate the parent class, and another member should indicate 
|   the calling class (or something similar).

The dispatch_class name that is stored in the octave_user_function
object is the name of the class in which the function is defined.  Why
should that be changed?  How would it be useful to store parent class
information there?

jwe