On Wednesday 18 January 2006 18:54, Stevan Little wrote:

> Are you thinking that one would be able to bless a Perl 5 reference
> into a Perl 6 package?

Not really, but depending on the what Perl 6 bless() does it might work.

> I would argue then that we really don't need Perl 6 &bless for this,
> and we can just use Perl 5's &bless. After all, if Perl 5 can call
> Perl 6 functions, then Perl 5 will need to understand Perl 6's
> packages, and vice-versa. If this is true then Perl 5's bless should
> be able to accept a Perl 6 package value and DWIM. However, this
> would probably be a somewhat ugly solution to whatever problem it is
> you are trying to solve since your Perl 6 code would be weighted down
> with Perl 5 OO-isms. In fact, I would argue that doing it this way is
> not the right way, and instead using Perl 6 OO and delegating to a
> Perl 5 object is a better option.

In the long-term sure.  However, I don't know how far interoperability will 
get if we expect everyone to do everything The Right Way all at once.

> Or are you thinking that a Perl 6 value should be blessed into a Perl
> 5 package?

That's closer to what I had in mind.

> I think there is a real serious issue here since the hash the Perl 5
> package would be expecting is a ref to an HV, and the Perl 6 value it
> would be getting would be an instance of the ^Hash class (itself a
> subclass of ^Object). This is actually where i see the fundemental
> problem with a Perl 6 &bless which is capable of blessing Perl 6
> references. There are no Perl 6 references like we had in Perl 5,
> they are *all* objects now. Would not the Perl 5 layer see the Perl 6
> instance of ^Hash as an object? If not, then we must already have a
> Perl 6 opaque (the ^Hash instance) to Perl 5 HV converter/proxy/magic-
> jellybean/thunk so I don't need to write it :)

Why would Perl 6 bless() bless references?  I've always seen it as specifying 
the underlying storage container for the object's instance data.  (Hey, my 
last rigorous reading of S12 predates my current project.  I could be wrong.)

If Ponie is there and this code runs on Parrot and Ponie uses Perl 5 PMCs, 
they're theoretically available to Perl 6, with the proper invocations or 
magic or thunking or whatever.

> Or maybe you are you thinking that a Perl 6 class can inherit from a
> Perl 5 class?


> To be honest, i think this is better handled with delegation, and can
> even be automated using the attribute delegation features described
> in A/S12.

I have serious doubts about round-tripping with delegation, having tried to do 
it.  I want to subclass a Perl 5 class with Perl 6 code and use objects of 
that class within Perl 5 code without them having to know that I'm doing 
something sneaky.

It'll be a true pity if that's *truly* impossible.

> The biggest problem with this would be object initialization. The
> normal Perl 6 BUILDALL/BUILD code could not be used here since Perl 5
> does not have the meta-object protocol to support such behaviors, nor
> is there a common enough Perl 5 object initialization idiom to work
> with here. The end result is that you probably end up having to do a
> bunch of manual initialization code.

Sure, but that's a per-representation thunking layer writable in Perl 6 code.  
It might be somewhat tricky, but it's not completely hideously unsolvable 
code -- if it's possible.

> And let's not forget that our Perl 6 blessed hash is not the same as
> the Perl 5 blessed hash, so there might be confusion/issues there
> too. We also have the issue here of where does ^Object fit into our
> inheritance now? Is the Perl 5 package the top of our @ISA tree? or
> do we insert ^Object in there somewhere too?
> Or maybe you are you thinking that a Perl 5 class can inherit from a
> Perl 6 class?

I'm not nearly Australian enough for that kind of madness.

> So in conclusion, I think that a Perl 6 &bless which acts like a Perl
> 5 &bless is not as useful as your seem to indicate.

I'm pretty sure that's not what I was advocating.  I'm pretty sure the design 
thinking has always been:

1) by default, your object is opaque
2) if you don't want this, you can always use bless()

For interoperability with Perl 5 classes, I don't want to use an opaque 
object.  Ergo, I want to use bless() (or something, but does that explain why 
I think bless() is important?).

> It is certainly not the magic bullet of interoperability. I don't think we 
> can really avoid not having a p6opaque->p5-blessed-ref magic-thunker. 

I don't want to translate opaque objects into blessed references.  They should 
be opaque everywhere.  I do want the option to rewrite as little Perl 5 code 
as possible just to get the program to work, though.

-- c

Reply via email to