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