Re: Self-Sorting Containers

[David L. Nicol]

Dave Storrs wrote:
> 
> On Fri, 11 Aug 2000, David L. Nicol wrote:
> 
> > I've started talking about "containers" instead of arrays and hashes
> > since those both tie directly to implementation details, and containers
> > are abstractions.
> [...]
> >
> > If hashes normally had a sort method of null, they would work normally,
> > but you could overload the sort method of any hash with

> > What is a better syntax for this?
> 
> How about:
> %foo{ {$a <=> $b} }
> 
> (Obviously, you can put whatever you want as the sort function.)
> 
> Here are the advantages I see:
> - minimum syntax required
> - very clear what you're doing:
> 1) % is only used to refer to a hash as a whole
> 2) you generally don't use code refs as keys
> 
> Dave


Excellent!  The thing the parser would look for (rather, the bad syntax
exception handler, since %foo{{expression}} is generally meaningless
is that the code in there involves $a and $b

Shall we make its own RFC or try to include it in another?


-- 
  David Nicol 816.235.1187 [EMAIL PROTECTED]
:wq

Re: Self-Sorting Containers

[Damian Conway]

   
   > > tie %thehashinquestion, 'Sorted', flubber(^a,^b);
   > > 
   > > ???
   > > 
   > > Damian
   > 
   > 
   > Compiler will know to pass flubber as ref-to-code instead of
   > intant eval because (^a,^b) instead of ($a,$b), or is more,
   > like \&flubber needed here?

I was using the HOF notation, just to mirror your use of an anonymous sub.

In fact:

flubber(^a,^b)

means:

sub { flubber($_[0], $_[1]) }

Of course, you could also say:

\&flubber

in this context and save a subroutine call.

Damian

Re: Self-Sorting Containers

[Dave Storrs]

On Fri, 11 Aug 2000, David L. Nicol wrote:

> I've started talking about "containers" instead of arrays and hashes
> since those both tie directly to implementation details, and containers
> are abstractions.
[...]
> 
> If hashes normally had a sort method of null, they would work normally,
> but you could overload the sort method of any hash with
> 
> methodoverloadoperator(%thehashinquestion, 'sort', {$a flubber $b})
> 
> What is a better syntax for this?


How about:
%foo{ {$a <=> $b} }


(Obviously, you can put whatever you want as the sort function.)

Here are the advantages I see:
- minimum syntax required
- very clear what you're doing:  
1) % is only used to refer to a hash as a whole
2) you generally don't use code refs as keys



Dave

Re: Self-Sorting Containers

[David L. Nicol]

Damian Conway wrote:
> 
>> methodoverloadoperator(%thehashinquestion, 'sort', {$a flubber $b})
>>
>> What is a better syntax for this?
> 
> tie %thehashinquestion, 'Sorted', flubber(^a,^b);
> 
> ???
> 
> Damian


Compiler will know to pass flubber as ref-to-code instead of
intant eval because (^a,^b) instead of ($a,$b), or is more,
like \&flubber needed here?




-- 
  David Nicol 816.235.1187 [EMAIL PROTECTED]
:wq

Re: Self-Sorting Containers

[Dan Sugalski]

At 03:44 PM 8/11/00 -0500, David L. Nicol wrote:
>If hashes normally had a sort method of null, they would work normally,
>but you could overload the sort method of any hash with
>
>methodoverloadoperator(%thehashinquestion, 'sort', {$a flubber $b})
>
>What is a better syntax for this?

Overload the nextkey function for hashes. Since a sorted hash would 
probably have a different internal structure than a normal hash, you'll 
likely just provide your own hash vtable that'd get used when someone said:

   my AlphaHash %foo;

Dan

--"it's like this"---
Dan Sugalski  even samurai
[EMAIL PROTECTED] have teddy bears and even
  teddy bears get drunk

Re: Self-Sorting Containers

[Damian Conway]

   > methodoverloadoperator(%thehashinquestion, 'sort', {$a flubber $b})
   > 
   > What is a better syntax for this?

tie %thehashinquestion, 'Sorted', flubber(^a,^b);

???

Damian

Self-Sorting Containers

[David L. Nicol]

I've started talking about "containers" instead of arrays and hashes
since those both tie directly to implementation details, and containers
are abstractions.


A self-sorting container would be easy enough to tie to, most methods
would inherit from an underlying numbered array, except the insertion
methods and the assignment methods would be different, as after every
alteration, extension, push or unshift the new or modified element
would need to be checked for proper placement.  Or proper placement
could be defered until someone tries to access the container and done
then (when the sort happens is an implementation issue)


Maybe the hash syntax would be better for sorted containers, just using
the key return order for the sorting.


If hashes normally had a sort method of null, they would work normally,
but you could overload the sort method of any hash with

methodoverloadoperator(%thehashinquestion, 'sort', {$a flubber $b})

What is a better syntax for this?







-- 
  David Nicol 816.235.1187 [EMAIL PROTECTED]
:wq