> ...
> so here is a (very rough and probably broken) syntax idea building on
> that:
>
> sort :key { :descend :string .foo('bar').substr( 10, 3) }
>
> :key { :int .foo('baz') }
> :key { :float .foo('amount') } @unsorted ;
I see a kind of problem here: If the parts of the key are not fixed length but
can vary you can put them in strings *only* after processing all and
verifying the needed length.
Example:
sort :key { :descend :string .foo('bar') }
:key { :int .foo('baz') }
:key { :float .foo('amount') } @unsorted ;
Now .foo('bar') isn't bounded with any length - so you don't know how much
space to reserve.
And I believe that
- generating keys on every list element
- storing them into a array (array of array) and
- after having processed all checking the length, and
- now generate the to-be-sorted-strings
- sort
isn't the optimal way.
BTW: this requires that *all* keys are generated.
In cases like
- by name,
- by age,
- by height,
- by number of toes left,
- and finally sort by the social security number
most of the extractions (and possibly database-queries of calculations or
whatever) will not be done - at least in the current form of
sort { $a->{"name"} cmp $b->{"name"} ||
$a->{"age"} <=> $b->{"age"} ||
...
That is to say, I very much like the syntax you propose, but I'm not sure if
pre-generating *every* key-part is necessarily a speed-up.
If there are expensive calculations you can always cut them short be
pre-calculating them into a hash by object, and just query this in sort.
Also I fear that the amount of memory necessary to sort an array of length N
is not N*2 (unsorted, sorted), but more like N*3 (unsorted, keys, sorted),
which could cause troubles on bigger arrays ....
Regards,
Phil
