At 04:53 PM 10/1/00 -0400, Dan Sugalski wrote:
>At 11:33 AM 10/1/00 -0700, Peter Scott wrote:
>>But, setting aside my visceral reaction to changing array bases, you have
>>precisely the same problem here that has scuppered my intent to file an
>>RFC for hashes with fixed keys; how do you apply the attribute to
>>anonymous, let alone autovivified, arrays? If I say
>>
>> my @a :base(1);
>>
>>then what of $a[1][1]? How to specify that the second level array also
>>has a base of 1? Without it looking really ugly?
>
>Well, it'd be reasonable for autovivified arrays and hashes to inherit the
>properties of their parent, so if you had:
>
> my int @foo;
>
>and accessed $foo[1][2], that new autovivified array would be of type int.
Well, okay. This works better in the case of arrays, where it is much more
likely that the programmer wants homogeneity, than in hashes. Consider a
typical multicolumn database-type hash like:
%state = (
AK => {
NAME => 'Alaska',
CAPITAL => 'Juneau'
},
AL => {
NAME => 'Alabama',
CAPITAL => 'Montgomery'
},
AZ => {
NAME => 'Arizona',
CAPITAL => 'Phoenix'
}, ...
Clearly each level does not want the same restriction on its keys.
But the fact that my pet whim isn't supported by this proposal shouldn't
detract from the advantages in other situations.
>As for anonymous hashes and arrays, there's no reason outside of
>appearance that you coudn't tack on attributes after the closing
>array/hash constructor:
>
> my $foo = [] : int;
Looks good. What are the chances of the internals supporting user-defined
attributes? What would the API look like?
--
Peter Scott
Pacific Systems Design Technologies
