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