On Fri, Apr 24, 2009 at 1:54 PM, Robert T. Short
<address@hidden> wrote:
In my view (at least the way octave implements classes in this legacy
style), a class IS a struct, but has some extra stuff (methods,
dispatching, etc.) and some restrictions. I have never looked at the
implementation of real OOP languages, but I am guessing that the
concept still holds. I don't quite buy the notion that classes and
structs are exactly the same thing. In my view, a class is a struct
but has more junk, but a struct is not a class. If you look at the old
xwindows code, though, classes are simple carefully constructed
structs, so there is a lot of validity to your point of view.
I think a better way to say what I'm get at is that in Matlab, the difference between a struct and a class seems to be what the interpreter does, not something intrinsic to a "struct" or a "class" itself. i.e. what makes a struct a class is what caused by the class() function and is destroyed by the "clear classes" command not something that is part of the object. It's complicated because Matlab uses postfix notation for method calls i.e. when the interpreter sees:
> sum(something)
It's the interpreter that has to decide if it's going to evaluate this as object->sum() or sum(struct) and then in the case of object->sum() hunt down the appropriate function definition. Likewise it's the interpreter that has to decide if the evaluation scope allows members to be accessed. Another wrinkle is that a struct must get the interpreters blessing before it can becoming as class. It seems really to be all about what the interpreter does and I'm having trouble invisioning how an interpreter can conveniently delegate these actions to the classes.
Something that I keep meaning to ask JWE is whether we should derive
octave_class from octave_struct. I haven't really thought this out in
detail, but it seems to me that deriving things this way solve a couple
of problems. In the ov-class.{h,cc} code there are elements that say
"FIXME: This is the same code as ov-struct". Inheritance might fix
that problem. Also, the notion of returning a struct if the class is
not reconstructable seems easier, since you just take the map and
return the base class rather than the derived class. Just thoughts.
I agree, but given all the work that has to go on inside the interpreter to get classes to work with the language--isn't the only thing that differentiates a class from a struct the class name? That's what the m-file format suggests and that's why I proposed always reading objects from files as structs and asking the interpreter to convert them to classes. But then I got the impression that John was saying that octave allows C++-based classes to not be based on struct representations? Maybe I misunderstood.
--judd