On 1/19/06, chromatic <[EMAIL PROTECTED]> wrote:
> On Wednesday 18 January 2006 20:02, Rob Kinyon wrote:
> > On 1/18/06, chromatic <[EMAIL PROTECTED]> wrote:
> > > Answer me this then -- under your scheme, can I subclass a Perl 5 class
> > > with Perl 6 code, instantiate the subclass, and use that object in Perl 5
> > > code as if the subclass were Perl 5 code, without rewriting all of my
> > > Perl 5 code?
> >
> > You have two cross-language interactions.
> >     1) Subclass a LangX class in LangY
> >     2) Instantiate a LangY class and use that object in LangZ
> > That LangX === LangZ is irrelevant to the discussion.
> Unless, of course, if $omeone had promised backwards compatibility with LangZ
> 5 from LangY 6.

I'm not sure how that promise is broken if Perl 6.0.0 includes Ponie
as part of the distribution.

> Next question.  If Ponie and Perl 6 are both running on Parrot, and if Ponie
> has PMCs that represent Perl 5 data containers, such as p5hash, p5array,
> p5symbol, and so on, what's the problem with having a Perl 6 object that uses
> one of those PMCs as its internal storage?

Nothing. Just like it's not a problem if Perl6 uses one of the
Ruby-specific PMCs for storage. In fact, the alternate $repr idea is
specifically to allow for the use of foreign datatypes as storage.
Luke's excellent example is to use a C-struct as your storage.

> I realize one of Stevan's objections is "But if you use a Hash, does your
> object automatically support the .keys method and .kv and so on?" to which I
> reply "No, of course not.  That's silly.  It just uses the Hash for
> *storage*."

Storage of what? What are you trying to do that you need to use an
object to store your attributes? Why aren't you just using the method
-that- object is using?

And, for the record, I'm currently working on a proposal to p6l to
restrict object representations to unboxed types. So the problem that
Stevan is worried about in this objection would become moot.

> Is that your objection to bless()?

No. My objection to bless() is BUILD() and CREATE(). There's already a
mechanism in the P6 OO system for specifying the internal
representation of the instance. In fact, if you're crazy enough, you
can specify that at runtime. In other words, the functionality of
bless() has already been subsumed into the OO system and is called by
a few different names.

> Or is the question about "Why is there a need for bless() when you can already
> pass arguments to CREATE()?"  In that case I dunno.

Exactly. :-)


Reply via email to