On Tue, 2002-04-16 at 14:57, Piers Cawley wrote:
> Aaron Sherman <[EMAIL PROTECTED]> writes:
> > I suspect it would involve:
> >
> > 1. Copying the key (which might be a reference) on insertion.
> > 2. Hashing once, and caching the hash.
> >
> > This means a minimum of overhead, so it's a good th
David Wheeler <[EMAIL PROTECTED]> writes:
> On 4/16/02 11:57 AM, "Piers Cawley" <[EMAIL PROTECTED]> claimed:
>
>> Personally I'd like the default hash to return some immutable, unique
>> and probably opaque object id (something the like
>> 'Foo=HASH(0x81e2a3c)' you get from unoverloaded objects i
On 4/16/02 12:27 PM, "Larry Wall" <[EMAIL PROTECTED]> claimed:
> You guys are thinking in terms of a single $obj.hash method. I think
> there will be more than one hashish (er...) method available, and each
> hash will be able to choose at least whether it wants to hash by $obj._
> (the default)
Piers Cawley writes:
: Aaron Sherman <[EMAIL PROTECTED]> writes:
:
: > On Tue, 2002-04-16 at 14:00, Mike Lambert wrote:
: >> Speaking of which, how do we ensure the immutability of keys being put
: >> into the hash? I think Perl copied the string, so that:
: >>
: >> $b = "aa";
: >> $a{$b} = 1;
:
On Tue, Apr 16, 2002 at 02:00:33PM -0400, Mike Lambert wrote:
> Speaking of which, how do we ensure the immutability of keys being put
> into the hash? I think Perl copied the string, so that:
RFC266 talks about these issues, though it was just really my take on
the problem at the time. http://de
On 4/16/02 11:57 AM, "Piers Cawley" <[EMAIL PROTECTED]> claimed:
> Personally I'd like the default hash to return some immutable, unique
> and probably opaque object id (something the like
> 'Foo=HASH(0x81e2a3c)' you get from unoverloaded objects in Perl5, but
> probably not identical). This isn'
Aaron Sherman <[EMAIL PROTECTED]> writes:
> On Tue, 2002-04-16 at 14:00, Mike Lambert wrote:
>> Speaking of which, how do we ensure the immutability of keys being put
>> into the hash? I think Perl copied the string, so that:
>>
>> $b = "aa";
>> $a{$b} = 1;
>> chop $b;
>> print $a{"aa"};
>>
>>
On 4/16/02 11:00 AM, "Mike Lambert" <[EMAIL PROTECTED]> claimed:
> Speaking of which, how do we ensure the immutability of keys being put
> into the hash? I think Perl copied the string, so that:
>
> $b = "aa";
> $a{$b} = 1;
> chop $b;
> print $a{"aa"};
>
> still works.
>
> If we start storing
On Tue, 2002-04-16 at 14:00, Mike Lambert wrote:
> Speaking of which, how do we ensure the immutability of keys being put
> into the hash? I think Perl copied the string, so that:
>
> $b = "aa";
> $a{$b} = 1;
> chop $b;
> print $a{"aa"};
>
> still works.
>
> If we start storing full thingies in
Speaking of which, how do we ensure the immutability of keys being put
into the hash? I think Perl copied the string, so that:
$b = "aa";
$a{$b} = 1;
chop $b;
print $a{"aa"};
still works.
If we start storing full thingies into the keys of a hash, we either need
to make deep copies of these, or
On Tue, 2002-04-16 at 12:21, Larry Wall wrote:
> Aaron Sherman writes:
> : This allows me to specify separate hashing and stringification methods,
> : but retains Perl's original default of combining the two.
>
> Yes, that's what we intend to do.
You can make a man feel so small ;-)
Thanks
Aaron Sherman writes:
: In this example:
:
: %hash = ($a=>$b);
:
: $a can be anything. In fact, since Perl6 promises to retain the original
: value of $a, we're rather encouraged to store complex data there. But,
: this poses a problem. The key to use for hashing might not ideally be
: the
12 matches
Mail list logo
