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


Attachment: signature.asc
Description: OpenPGP digital signature

Reply via email to