Stevan Little wrote: >> 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()? > > 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.
It is possible to have one's cake and eat it too. Consider: Foo.bless($x) where $x contains an Bar object. We can check if Foo is a subtype to Bar -- for example, Foo.bless({some => 'hash'}) would check whether Foo conforms to the Hash interface. If so, then we safely reuse the underlying representation for storage: class Foo does Hash { has $.a; has $.b } my %args = (a => 1, b => 2); my $obj = Foo.bless(%args); %args.{'a'} = 999; say $obj.a; # 999 say $obj.{'a'}; # 999 If not, we explode $x into named arguments and dispatch to .CREATE to make an p6opaque representation. Hash and Array are thus turned to pairs; a Scalar would have to contain an arglist or a pair, otherwise it'd fail the named-only prototype check. To wit: class Bar { has $.a; has $.b } my %args = (:a<1>, :b<2>); my $obj = Bar.bless(%args); %args.{'a'} = 999; say $obj.a; # 1, not 999 say $obj.{'a'}; # Error -- no such method: postcircumfix:<{ }> Note that A12 used to say that all Objects does Hash, and %$obj even returns private attributes when used inside the class scope. Fortunately, S12 doesn't mention anything like that, so I think the treatment above is safe. Audrey
signature.asc
Description: OpenPGP digital signature