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 n
> > 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
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,
> bu
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
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 t
> methodoverloadoperator(%thehashinquestion, 'sort', {$a flubber $b})
>
> What is a better syntax for this?
tie %thehashinquestion, 'Sorted', flubber(^a,^b);
???
Damian
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 ins
