On 1/19/06, chromatic <[EMAIL PROTECTED]> wrote:
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?
Okay, so when you say alternate storage then you mean that a class
like this:
class Foo {
has $.bar;
method new ($class, %params) {
$class.bless('p5Hash', %params);
}
method baz {
$.bar += 1;
}
}
should use a PMC representation of a p5 hash as it's storage, and
that the method baz does the right thing here?
Because that makes sense to me. However, what doesn't make sense
would be if I had to write &baz like this:
method baz {
self->{'bar'} += 1;
}
In other words, if this is just a detail of the storage, and does not
affect user code at all, then I am okay with it. This though would
mean that you would not have direct access to the underlying data
structure (the p5 hash).
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*."
Okay, then I assume you mean it to behave the same way as with the
p5hash, that it is completely transparent to the user that you are
using a p5hash or a p6hash or a p6opaque?
In which case,.. I say okay. But note again that you have not
provided access to the underlying data structure (the p6hash a.k.a -
an instance of ^Hash).
Is that your objection to bless()?
Yes, that is my objection, because while the alternate storage
approach discussed above is actually a very interesting feature, it
does not fit with the p5 vision of &bless.
With p5, you /can/ get to the underlying data structure. This is a
break which will hamper the backwards compatibility effort I think.
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.
Yes, this will be an interesting one :)
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.
Well as you say in your reply to Rob, TIMTOWTDI. I will agree with
you here if they are in fact 2 ways to do the same thing. This would
actually solve and simplify some issues in the metamodel currently.
And to be honest, I have absolutely no real "objection" to &bless. I
just don't think the current treatment of it is consistent with some
of the stated goals of the Perl 6 design.
Stevan
