On Tue, Aug 23, 2005 at 12:21:42PM -0400, Sam Ruby wrote:
> Kevin Tew wrote:
> > I've ripped out a lot of the explicit passing of self as the first
> > argument of pmc methods. -  We don't have to pass self around, parrot
> > makes it available to us automatically.
> 
> I added self on Leo's request.  Now it is unneccessary.  *shrug*

Parrot's calling conventions having updated, everybody must adjust,
it's not about Pirate.  I like to think that this most recent change
in calling convention is an improvement, by and large.

> > Sam's implementation of Python PMC is old and outdated.  He did a lot of
> > pioneering work in the realm of the python object system on parrot. 
> > Probably the first real attempt at a full object system on top of parrot.
> > Parrot has changed drastically since then.
> > Sam's PMC's were also incomplete, they lacked support for a lot of the
> > __add__ style python methods.  This is quite understandable, Sam was
> > trying to get something working.
> 
> Check out parrot/t/dynclass/pyint_2.pmc.  __add__ style methods were
> working, and tested.

I remember seeing the implementation of __*__.  It looked fine to me
in design, though I didn't review every particular one.

At OSCON I learned that IronPython contrives to make CLR classes look
just like native Python classes even under introspection, and that's
just plain nifty.  The Parrot equivalent would be to make the class
look like it has an __add__ method iff the underlying Parrot class
implements __add.  Interesting?

> > The plan is to reduce python object system pmc's code content and
> > functionality to zero, and then rebuild it up  Mainly because every time
> > I try to morph Sam's code, Leo tells me the whole approach is wrong :)
> 
> No matter what you do, Leo will tell you that the whole approach is
> wrong.

It's a fair cop.  Leo's always has strong ideas about how things
should evolve.  But in language-specific code like the Python classes,
I don't see why Leo -- or I, for that matter -- should have standing
to tell you what to do.  If Python users are happy with the results,
whatever they may be, and if the core functionality of Parrot isn't
impacted for other languages, more power to you.  If we got all
unreasonable on you, you'd just take Pirate development out of the
Parrot tree or else just quit, and neither of those alternatives is
good for Parrot.  As Larry says: Live and let learn.

Therefore, if you _want_ to rebuild from zero, please by all means go
ahead.  Just be prepared to discover that the original structure was
actually better than you thought.
-- 
Chip Salzenberg <[EMAIL PROTECTED]>

Reply via email to