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?
Absolutely.
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.
Stevan
