[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Derived Objects and OOP
|
From: |
Robert T. Short |
|
Subject: |
Re: Derived Objects and OOP |
|
Date: |
Sat, 28 Mar 2009 09:49:55 -0700 |
|
User-agent: |
Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.8.1.19) Gecko/20081204 SeaMonkey/1.1.14 |
John W. Eaton wrote:
On 28-Mar-2009, Robert T. Short wrote:
| <!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
| <html>
Can you disable the HTML goop when writing to the lists?
Grumble. This mail thing used to ask me about this. I will watch this
in the future. I am trying with this mail, but am not sure if I know
how to turn it off so let me know if it still comes in as HTML.
| Unfortunately, I don't have any test suite.
| </pre>
| </blockquote>
| OK. I will cobble something together from the documentation.
| <blockquote cite="mid:address@hidden"
| type="cite">
| <pre wrap="">
| 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?
| </pre>
| </blockquote>
| What I meant by this comment is that I haven't checked to ensure that I
| didn't break anything. I will do so as time permits and create
| proper test scripts.
OK.
| | - load/save
|
| What is supposed to be saved?
| </pre>
| </blockquote>
| Saving an object should save the data for the derived class and all
| parents.
Are you sure? The description of the MAT-file format doesn't mention
parent class names. It says that an object is stored the same as a
structure with the name of the class. Octave already does this, so
I'm not sure there is anything to change.
No I am not sure. I guess this was really a "note to Bob" to make sure
that things work sensibly. I am not at all sure there IS anything to be
done, since saving the object should really just save the structure and
that is probably already done. There might be something to do to make
sure that the load process re-creates the parent list.
| | - 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.
| </pre>
| </blockquote>
| This is actually very important. IMHO, without this feature the
| implementation is only half-baked.
|
| Here is what I mean by this (look at the examples provided in the
| tarball for details on the class implementation).
|
| Consider a class hierarchy
|
| ClassName DirectoryName Parent Method
| Snork
| @Snork
| None gick (set and return the value of the property
| gick)
| Dork
| @Dork
| Snork gack (set and return the value of the property gack)
|
| The following code fragment, taken from the ClassTest.m script, creates
| a Snork object with the default value of gick, and then changes the
| value of gick to 2. This works fine.
| snk = Snork();
| snk = gick(snk,2)
|
| However, the next code fragment does not work.
| drk = Dork()
| drk = gick(drk,2) % This
| doesn't work.
| What it <i>should</i>
| do is set the value of the gick property in the drk.Snork field to
| 2. That is, after the second line is executed typing gick(drk)
| should return 2.
What's needed to make that happen?
As far as implementation I have no clue (yet). I have been looking
through all of the tree evaluation stuff just trying to make sure I know
what it does before I go tapdancing through the sources.
Using the example above, if the invocation is gick(drk), then the Snork
field of drk should be updated with the results of the gick function.
In general, the parent tree must be traversed to find the appropriate
structure field for the class that owns the method and that structure
field updated with the result of the method function.
| Note that get/set works just fine. However if a class has multiple
| parents there is no way to use get/set, and the get/set technique is
| really clumsy in some situations.
Do you mean that it should be possible to use get/set in Octave, but
it is not working now, or that it is not possible in Matlab either?
Not possible in MATLAB. Or more accurately, I haven't figured out a
clean way to do it. For examples, see the classes I provided in the
tarball. The way get/set works is that if the derived class doesn't
have a property name it invokes get/set on the parent structure field.
If the parent doesn't have it, it will do it for all of its' parents.
If you get to the top of the tree without finding the property name, an
error is thrown. In the case of multiple inheritance, if you don't pick
the right parent to start with then an error will be thrown. It would
be very simple to provide a clean extension in octave, and I am
considering this when the critical stuff works.
I don't really like the get/set approach for my own applications, so
this is not too high on my priority list.
| <blockquote cite="mid:address@hidden"
| type="cite">
| <pre wrap="">
| | - "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.
| </pre>
| </blockquote>
| I really don't know the answer to this. I put it there mostly
| because I haven't got the symbol table module figured out.
| However, load_path seems to be a reasonable place since that is where
| the method file search takes place.
OK.
| <blockquote cite="mid:address@hidden"
| type="cite">
| <pre wrap="">
| | - "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?
|
| </pre>
| </blockquote>
| I will look and see what MATLAB provides. I have thought of doing
| what you did regardless of MATLAB's behavior, so this is great. I
| will look and see what you did with isa. Just to be sure we are
| communicating, here is what should happen. Referring to the
| example above, isa(drk,"Dork") and isa(drk,"Snork") should both return
| true.
Yes, that's the way it works now.
Cool. I will include this in my test code.
| | - 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.
|
| </pre>
| </blockquote>
| Agreed. This makes the test suite a little complicated.
| Philosophically, no implementation is complete without a test suite and
| documentation. I rarely have time to work on this except for a
| couple of hours on weekend mornings so it is going dreadfully
| slowly. As I gain familiarity with sources it should be easier
| for me to contribute.
Tests would be great to have, but right now it would help more if you
can explain how things are supposed to work (for example, how can we
implement the field setting thing above that you say is broken).
Exactly. First make things work, then document/test. I wish I could
spend more time, but my priorities are (1) billable hours, (2) billable
hours, (3) the book I am writing, (4) billable hours, (5) all of the
other projects.
| <pre wrap="">| - 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?
|
| </pre>
| </blockquote>
| Actually, dispatch_class is the name of the class that invoked the
| method. Thus, using the example above, invoking gick(drk) results
| in dispatch_class being "Dork" and gick(snk) results in dispatch_class
| being "Snork". So I was thinking of creating another element that
| is "Snork" regardless of the invoking class.
| <blockquote cite="mid:address@hidden"
| type="cite">
| <pre wrap="">jwe
| </pre>
| </blockquote>
So you are thinking of explicitly caching the base class name(s)?
That might help performance if the base class is always needed. But
wouldn't it be sufficient to simply look up the base class name(s)
when they are needed? Given a class name, isn't it possible to look
up the base class names(s) quickly? Aren't they already stored in a
map?
Just thinking about it. The key is to make things both simple and
quick. Situations where there are dozens of parents are unlikely, so
this is a small issue. However, every time I go looking through the
parent load path I have to dredge out the parent class file name, so it
might be useful.
jwe