Re: Objects, finally (try 1)

[Dan Sugalski]

At 9:37 PM -0500 1/14/03, Christopher Armstrong wrote:

On Tue, Jan 14, 2003 at 03:00:17PM -0500, Dan Sugalski wrote:

 At 11:44 AM -0800 1/14/03, Mr. Nobody wrote:
 >Seems pretty reasonable, but don't you mean PerlRef, PerlAttr, PerlClass,
 >PerlObject?

 Nope. There's nothing particularly perlish about them, and if we're
 going to have a common base set of object functionality, they'll
 probably be named ParrotRef/Attr/Class/Object. They should suffice
 for perl, python, and ruby (at the very least) unless I've missed
 something.

Hmm, well. Are you really trying to make it so Python won't have to
make a specialized subclass (err, subPMC?) of this system? If so, then
it'll probably need drastic changes.. I'm a Python hacker who's pretty
familiar with its object system. If you want, I can offer up some
explanations/advice for making this system usable directly by Python.

Thanks--I *really* appreciate that.

As it stands, an implementation of the Python object system could
definitely be implemented _in terms of_ what you have now, but, for
example, the method system that you have worked out now would be
totally unusable (afaics), as instance methods have some pretty
whacky, dynamic semantics. It'd probably have to be implemented in
terms of properties.

Methods I'm not actually worried about, though we've not much discussed them. (I think you'll find that Python's got nothing on Ruby or Perl for method wackiness... :) Though you've definitely pointed out an area that I need to get more detailed.

Method dispatch is the one place I know that we may have custom behaviour, but I don't think it'll actually be necessary. Python method dispatch, from the references I have, isn't unusual, which is a good thing. (Plus I'll be layering multimethod dispatch on top, but that'll be transparent)

The problem, of course, is that either you go more static and make the
very dynamic, reflective languages like Python harder to implement (or
prevent them from making use of your existing abstractions like
methods, as explained above), or you go more dynamic and make the more
static languages (like Haskell?) slower because they'd have to
implement their features in terms of dynamic ones, when a lot of the
information could be available at compile-time.

At the moment the only really proposed static stuff is the attribute list, and only because I'm trying hard to stick with the more efficient array structure. (We could just bite the bullet and drop to using a tree, but I think we can avoid that in the common case if we have a fallback--I just need to define the fallback now)

But who knows, maybe it could be made modular enough (i.e., more
interface-oriented?) to allow the best of both worlds -- I'm far too
novice wrt Parrot to figure out what it'd look like, unfortunately.

It'll actually look like what we have now. If you can come up with something more abstract than:

callmethod P1, "foo"

that delegates the calling of the foo method to the method dispatch vtable entry for the object in P1, well... gimme, I want it. :)

I'll add "define method dispatch more" to the list o' stuff for the next edit of the proposal.
--
Dan

--------------------------------------"it's like this"-------------------
Dan Sugalski even samurai
[EMAIL PROTECTED] have teddy bears and even
teddy bears get drunk