On Thu, 2002-07-25 at 03:12, [EMAIL PROTECTED] wrote:
> Aaron Sherman <[EMAIL PROTECTED]> writes:
> > my @x is Hashed::ByValues = (1,2,3);
> > %h = (@x => 1);
> > @x[1] += 4;
>
> Personally I don't like the C< is Hashed::ByValues > because it smacks
> of spooky action at a distance;
On 25 Jul 2002 [EMAIL PROTECTED] wrote:
> Luke Palmer <[EMAIL PROTECTED]> writes:
>
> > On 25 Jul 2002 [EMAIL PROTECTED] wrote:
> > >
> > > Personally I don't like the C< is Hashed::ByValues > because it smacks
> > > of spooky action at a distance; I much prefer my notion of C< %h{*@x}
> > > =
On 25 Jul 2002 [EMAIL PROTECTED] wrote:
>
> Personally I don't like the C< is Hashed::ByValues > because it smacks
> of spooky action at a distance; I much prefer my notion of C< %h{*@x}
> = 1>. And in Perl 6 I have the horrible feeling that C<< %h = (*@x =>
> 1) >> would expand to C<< %h = (1,2,
On Tue, Jul 23, 2002 at 03:10:50PM +, Ashley Winters wrote:
> On Tuesday 23 July 2002 08:44 am, Alberto Manuel Brandão Simões wrote:
> > On Tue, 2002-07-23 at 09:27, Ashley Winters wrote:
> > > @foo = ();
> > > %hash{@foo} = 10;
> > > push @foo, 'This would change the hash key for @foo?';
> >
On Wed, 2002-07-24 at 18:15, Aaron Sherman wrote:
> On Wed, 2002-07-24 at 12:34, Fisher Mark wrote:
> > > But then sometimes you'd *want* hashing to be based on the
> > > content.
> >
> > OK, I'll bite -- when would you want this behavior? This behavior means
> > that once you change the content
On Wed, 2002-07-24 at 12:34, Fisher Mark wrote:
> > But then sometimes you'd *want* hashing to be based on the
> > content.
>
> OK, I'll bite -- when would you want this behavior? This behavior means
> that once you change the contents, the hash value would become irretrievable
> unless you rest
> But then sometimes you'd *want* hashing to be based on the
> content.
OK, I'll bite -- when would you want this behavior? This behavior means
that once you change the contents, the hash value would become irretrievable
unless you restored the contents of the key. (Is this useful in functional
As the last person to change the key hash algorithm, I'd like to chime in
here with a request that each PMC provide a string that the key hashing
algorithm can operate on. To some degree this is just selfish on my part --
I've got plans for upgrading the key hash algorithm in Perl 5 and Perl 6
wh
Dan Sugalski wrote:
> Yes. Hashes will take either strings or object IDs, depending on the
> hash. (The hash can choose)
Seems to me it would be mighty useful to have integer keys as well.
For large sparse arrays, e.g.
--
John Douglas Porter
At 9:36 AM +0100 7/22/02, [EMAIL PROTECTED] wrote:
>Um... not necessarily. Bordering on the 'not at all'. Perl 6 will
>apparently allow one to have things other than strings as keys to
>hashes. If I have:
Yes. Hashes will take either strings or object IDs, depending on the
hash. (The hash can ch
On Mon, 2002-07-22 at 04:36, [EMAIL PROTECTED] wrote:
> > Now, I ask for PMC programmers to take care implementing this! Notice
> > that, for example in arrays, arrays with the same length but different
> > elements should return different hash codes (or try). But for the same
> > elements MUST r
[EMAIL PROTECTED] wrote:
> Also, how deep should we go if we decide to have the hash algorithm
> work on the contents?
>
> One starts to understand why scheme has C, C and
> C.
Indeed. It's also why it allows to specify, in AA accesses,
what equality-testing operator you want keys to be compar
From: [EMAIL PROTECTED]
> If I have:
>
>$a = [ 1, 2, 3 ];
>$b = [ 1, 2, 3 ];
>
>%foo{$a} = 'A';
>%foo{$b} = 'B';
>
> Then I want C< (%foo{$a} == 'A') && %foo{$b} == 'B' > to be true.
Maybe this a case of "And Now For Something Completely Similar". This
looks like something we
On Tuesday 23 July 2002 08:44 am, Alberto Manuel Brandão Simões wrote:
> On Tue, 2002-07-23 at 09:27, Ashley Winters wrote:
> > @foo = ();
> > %hash{@foo} = 10;
> > push @foo, 'This would change the hash key for @foo?';
> >
> > print "ok 1" if exists %hash{ [] };
> > print "ok 2" if exists %hash{
On Mon, 2002-07-22 at 09:36, [EMAIL PROTECTED] wrote:
> > Now, I ask for PMC programmers to take care implementing this! Notice
> > that, for example in arrays, arrays with the same length but different
> > elements should return different hash codes (or try). But for the same
> > elements MUST re
On 23 Jul 2002, Alberto Manuel Brandão Simões wrote:
> On Tue, 2002-07-23 at 09:27, Ashley Winters wrote:
> > On Tuesday 23 July 2002 07:47 am, Alberto Manuel Brandão Simões wrote:
> > > Now, I ask for PMC programmers to take care implementing this! Notice
> > > that, for example in arrays, array
On Tue, 2002-07-23 at 09:27, Ashley Winters wrote:
> On Tuesday 23 July 2002 07:47 am, Alberto Manuel Brandão Simões wrote:
> > Now, I ask for PMC programmers to take care implementing this! Notice
> > that, for example in arrays, arrays with the same length but different
> > elements should retur
On Tuesday 23 July 2002 08:27 am, Ashley Winters wrote:
> push @foo, 'This would change the hash key for @foo?';
>
> print "ok 1" if exists %hash{ [] };
> print "ok 2" if exists %hash{ [10] };
Err, I meant:
print "ok 2" if exists %hash{ ['This would change the hash key for @foo?'] };
Also, the
On Tuesday 23 July 2002 07:47 am, Alberto Manuel Brandão Simões wrote:
> Now, I ask for PMC programmers to take care implementing this! Notice
> that, for example in arrays, arrays with the same length but different
> elements should return different hash codes (or try). But for the same
> element
Resuming:
- Dan proposed an 'id' method returning an INTVAL;
- Brent Dax proposed to return a string;
- Nicholas Clark asked to return an unsigned value;
- Piers didn't like the 'id' name unless globally guaranteed to be
unique;
So, I propose another name (hash). Returning a string can be done
a
Dan Sugalski:
# At 5:52 PM +0100 7/22/02, Alberto Manuel Brandão Simões wrote:
# >Dan, can we create this new vtable method? returning an
# integer (long
# >integer)... with name hashValue, or asHash.. or something else.
#
# Yep. Call it id and have it return an INTVAL.
Can we have it return a
On Mon, 22 Jul 2002, Dan Sugalski wrote:
> At 5:52 PM +0100 7/22/02, Alberto Manuel Brandão Simões wrote:
> >Dan, can we create this new vtable method? returning an integer (long
> >integer)... with name hashValue, or asHash.. or something else.
>
> Yep. Call it id and have it return an INTVAL.
On Mon, Jul 22, 2002 at 01:12:57PM -0400, Dan Sugalski wrote:
> At 5:52 PM +0100 7/22/02, Alberto Manuel Brandão Simões wrote:
> >Dan, can we create this new vtable method? returning an integer (long
> >integer)... with name hashValue, or asHash.. or something else.
>
> Yep. Call it id and have i
At 5:52 PM +0100 7/22/02, Alberto Manuel Brandão Simões wrote:
>Dan, can we create this new vtable method? returning an integer (long
>integer)... with name hashValue, or asHash.. or something else.
Yep. Call it id and have it return an INTVAL.
>On Mon, 2002-07-22 at 17:07, Leon Brocard wrote:
>
Dan, can we create this new vtable method? returning an integer (long
integer)... with name hashValue, or asHash.. or something else.
Alberto
On Mon, 2002-07-22 at 17:07, Leon Brocard wrote:
> Alberto Manuel Brandão Simões sent the following bits through the ether:
>
> > This means one more fun
Alberto Manuel Brandão Simões sent the following bits through the ether:
> This means one more function to the vtable!
FWIW every object in Java must implement a hashCode method:
http://java.sun.com/j2se/1.4/docs/api/java/lang/Object.html#hashCode()
Leon
--
Leon Brocard
On Mon, 2002-07-22 at 14:05, Simon Cozens wrote:
> Alberto writes:
> > Finally, we need to hash PMC's. While I don't know what hash function
> > we should use
>
> Nor can you know, in the general case. Let PMCs hash themselves.
This means one more function to the vtable!
The value returned by th
Alberto writes:
> Finally, we need to hash PMC's. While I don't know what hash function
> we should use
Nor can you know, in the general case. Let PMCs hash themselves.
--
4.2BSD may not be a complete disaster, but it does a good job of emulating one.
28 matches
Mail list logo
