Judd Storrs wrote:
On Thu, Apr 23, 2009 at 1:44 PM, Robert T.
Short <address@hidden>
wrote:
Dumb structs is a little
unfair. Now mind you, not all that far off,
but a bit harsh. There are lots of limitations, but I have done some
very nice things. The biggest problem is having lots of little m-files
around that are all three-liners, but every change to the basic
structure requires modifying a bunch of little files.
When I said 'dumb' I didn't mean it as a criticism. What I meant to
convey is that I don't think structs and classes are really different
at all. The mental model I've developed over the years working with
matlab and IDL structs and OOP is that Matlab structs and classes are
essentially exactly the same thing. The differences boil down to how
the interpreter dispatches functions and what restrictions are placed
on member access. A struct-flavored object has no access member
restrictions and defers all function calls. A class-flavored object has
a protected layout, restricts member access in certain scopes, and can
hijack function search if it's the first arguement in a call. From that
perspective it seems unnatural to treat objects and structs
as two different animals because and object is a struct and a struct is
an object. That's all I meant.
OK. I didn't really take it as a criticism, but I see how you
interpreted my response that way. 'Sides I didn't invent it so why
should I take it as a criticism anyway? :->
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.
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.
In my own work, I have come to rely so heavily on classes and
inheritance that I am finding it very difficult to go back to my older
code that doesn't have those features. That is why I jumped in to
build the inheritance thing. I am already using it heavily. It seems
to work pretty well, and will be generally useful once we get this
load/save thing done. There are lots of details that need cleaning up
(e.g. a full implementation of "clear classes") but those should follow
pretty easily with the stuff John started yesterday.
In IDL (interactive data language), the situation is similar
except there is also a third flavor. Structures in IDL can be either
"anonymous" or "named". The interpreter keeps track of "named"
structures the same way Matlab keeps track of "class" structures.
Anonymous structures are what matlab's structures are -- you can add
and remove components whenever you want. Named structures are a hybrid
-- once the first named struct is created you cannot change the number,
names or types of its members without clearing the interpreter's memory
(Matlab doesn't enforce type--I just checked). In IDL classes are built
over named structures.
Not familiar with IDL, but you are correct. In MATLAB, once I create a
class from a struct, I can't change the structure any more. MATLAB
doesn't care what I stuff into the structure elements though. I can
start with some real number and end up with a class, an array, etc.
--judd
|