On Thursday 19 January 2006 21:53, Stevan Little wrote:
> 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?
Yes.
> 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 don't think it's impossible, but it's fairly ugly and I'm okay if you can't
do it by default from the Perl 6 side. I certainly wouldn't use it.
From the Perl 6 side, I would rather use Perl 6 looking code.
> 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?
From Perl 6? Yes.
> 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).
Agreed.
> With p5, you /can/ get to the underlying data structure. This is a
> break which will hamper the backwards compatibility effort I think.
With Perl 5, you can *appear* to get to the underlying data structure. Yet
tie() is basically free on Ponie and there's a metaclass mediating access to
the underlying storage. I think that makes the problem solvable.
(Does using an alternate type of storage mean you need an alternate metaclass?
Perhaps, perhaps not -- but the practical effects of syntax have to come from
somewhere.)
As long as you can use Perl 5 classes in Perl 6 without rewriting all of the
Perl 5 code, I'm happy.
-- c
