On 1/18/06, chromatic <[EMAIL PROTECTED]> wrote:
On Wednesday 18 January 2006 14:13, Stevan Little wrote:
Do we really still need to retain the old Perl 5 version of &bless?
What purpose does it serve that p6opaque does not do in a better/
faster/cleaner way?
Interoperability with Perl 5 code.
How so? Please elaborate how you see this working?
Are you thinking that one would be able to bless a Perl 5 reference
into a Perl 6 package?
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.
Or are you thinking that a Perl 6 value should be blessed into a Perl
5 package?
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 :)
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.
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.
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?
Well since Perl 5 inheritance is really just a package name in the
@ISA, this is trivial to get method inheritance since Perl 5 already
can understand Perl 6's packages. And lets assume that the Perl 5
&new uses the (somewhat common) idiom and just calls SUPER::new(@_)
and re-blesses the returned Perl 6 instance. Let's assume too that
the Perl 6 constructor just blessed a Perl 6 instance of ^Hash. Again
we have the mismatch between the ref to an HV and the ref to an
instance of ^Hash. This brings us back to our Perl 6 opaque (the
^Hash instance) to Perl 5 HV converter/proxy/magic-jellybean/thunk
thingy.
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. 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.
However, maybe I am missing something here, if so, please elaborate
and explain.
Thanks,
Stevan
