Mark Smith wrote the magic phrase that made this much clearer to me:
> It's like attaching a temporary value to each line and sorting
> by that.
The moment of "a ha!" Thank you, Mark. Jim Ault's detailed explanation
was also helpful.
So this tells me two things:
1. Using a function for a sortKey expression introduces a "sometimes"
rule in terms of understanding the order of expression evaluation in the
engine, in which most of the time functions are evaluated first but in
this case the function is applied repeatedly for each line of the sort
container as the sort command is run.
2. Using a function as a sortKey expression evaluates the sort container
as though by effectively adding data to it, rather than anything
necessarily in the data itself.
Both of these are very valuable insights. Thanks to all who helped
explain this.
Yes indeed, now I can see many areas where this can be useful, but it
also leaves me with a question:
Given #1 above, how does this affect performance? Unless there's
something ultra-tricky going on (wouldn't be the first time the engine
surprised me that way <g>), I would imagine that performance is affected
at least linearly, in which the overhead of the function call is
multiplied by the number of lines of the container to arrive at the
additional performance hit relative to a non-custom sort.
Perhaps I'll do some benchmarking to verify this theory....
--
Richard Gaskin
Managing Editor, revJournal
_______________________________________________________
Rev tips, tutorials and more: http://www.revJournal.com
_______________________________________________
use-revolution mailing list
use-revolution@lists.runrev.com
Please visit this url to subscribe, unsubscribe and manage your subscription
preferences:
http://lists.runrev.com/mailman/listinfo/use-revolution
