On 1/18/06, chromatic <[EMAIL PROTECTED]> wrote:
> On Wednesday 18 January 2006 18:54, Stevan Little wrote:
> 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 that predates the latest update then you should read again. It hasn't changed all that much on this subject though so maybe not.

I think the problem is that S12 is kind of fuzzy about this "underlying storage"/"alternate repr for opaque" issue. Without a really clean and well reasoned description of all that, and how it all works together there will be little hope of Perl 6<->Perl5 interoperability on the level you desire.

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.

Well, yes, we can push this all down to Parrot, which IMO is the right place for it to be handled. But in that sense then Perl 6's interaction with Perl 5 will be no different than Perl 6's interaction with (Python | Ruby | Tcl | etc). Which means there will be some restrictions on the depth of the interaction.

If we want to have the level of interoperability which you seem to think we should have (and I tend to agree with you that it would be nice), then we need to either;

1) Have a Perl 6 OO -> Perl 5 OO thunking layer

This would mediate things between the two OO models so that neither would have to be restricted by the other. This would be possible with some minor (but fairly complex) extensions to the Perl 6 MOP. Basically we would need to create a Perl 5 MOP of sorts which would have the appropriate thunks in the appropriate placed to make things Just Work.

2) Force some basic rules/restrictions upon the interoperability.

Well to start with, if Perl 5 code would need to treat the Perl 6 code as black boxes. It wouldn't be able to do $self->{attr}, it would have to do $self->attr(). The Perl 6 code would have to handle the Perl 5 data structures in a similar way (not sure the details of that though). There would also need to be some rules about inheritence. Perl 6 uses the C3 algorithm to determine the method resolution order, while Perl 5 uses the depth-first-left-to-right approach. This would mean that a Perl 5 class which uses multiple inheritence with some Perl 5 classes and some Perl 6 classes would have a rather hairy time determining the method resolution order. Maybe we would say that the Perl 6 class would *have* to use pre- order (depth-first-l-to-r) and could not use C3.

I could go on here, but there are enough mismatches between the two OO models that there would have to be some kind of ruleset.

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


See the inheritence/MRO mismatch I described above. This would apply here big time. It is not a trivial issue either.

> 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.

Maybe delegation would be nasty, but so would be mixed MROs. You say TOE-mato, I say TOW-mAto.

> 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.

Of course, everything is possible on some level, but making it easy for the newbie is the really really hard part.

> 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.

I don't think it's madness, and I am not Australian. If it goes one way, it *should* go the other way, period.

> 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?).

I am forking this part of the discussion to another thread. I think that Perl 5 interoperability is not dependent upon bless and that bless in Perl 6 is inherently broken. (more on that later :)

> 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.

Then you will limit your interoperability. The Perl 5 code needs a way into the Perl 6 opaque type, and vice versa, otherwise we end up with only behavioral inheritance and no state inheritance.

I do want the option to rewrite as little Perl 5 code
as possible just to get the program to work, though.

I agree.


Reply via email to