On Wednesday 18 January 2006 20:02, Rob Kinyon wrote: > On 1/18/06, chromatic <[EMAIL PROTECTED]> wrote:
> > Answer me this then -- under your scheme, can I subclass a Perl 5 class > > with Perl 6 code, instantiate the subclass, and use that object in Perl 5 > > code as if the subclass were Perl 5 code, without rewriting all of my > > Perl 5 code? > > You have two cross-language interactions. > 1) Subclass a LangX class in LangY > 2) Instantiate a LangY class and use that object in LangZ > That LangX === LangZ is irrelevant to the discussion. Unless, of course, if $omeone had promised backwards compatibility with LangZ 5 from LangY 6. > So long as you aren't peeking behind the curtain (method calls only), > Parrot should be able to mediate everything. In other words, if your > code is good OO code, then you shouldn't have any problems. In other words, your answer to my question is "no". Fine. Next question. If Ponie and Perl 6 are both running on Parrot, and if Ponie has PMCs that represent Perl 5 data containers, such as p5hash, p5array, p5symbol, and so on, what's the problem with having a Perl 6 object that uses one of those PMCs as its internal storage? I realize one of Stevan's objections is "But if you use a Hash, does your object automatically support the .keys method and .kv and so on?" to which I reply "No, of course not. That's silly. It just uses the Hash for *storage*." Is that your objection to bless()? I don't mean to handwave here -- there are definitely issues to consider when crossing a language boundary related to method dispatch (and the last I remember from design meetings was "things change there and you shouldn't expect that they stay the same"), but the resistance to allowing different storage types for objects completely baffles me. Or is the question about "Why is there a need for bless() when you can already pass arguments to CREATE()?" In that case I dunno. -- c
