--- Uri Guttman <[EMAIL PROTECTED]> wrote: > >>>>> "AH" == Austin Hastings <[EMAIL PROTECTED]> writes: > > AH> --- Uri Guttman <[EMAIL PROTECTED]> wrote: > >> @out = sort > >> key:compare( \&my_compare_sub ) ( /(\d+)$/ ), > >> @in ; > > >> note that the custome compare callbacks can be a block or a sub > >> name/ref. the callback sub would be passed 2 args as usual. > > AH> Off the top of my head, I can't think of a case where the > compare sub > AH> would be needed unless the key was not well-ordered. Does > anyone have > AH> an example of a case where the key-extraction sub approach > doesn't > AH> reduce the problem to a Scalar comparison? > > there are rare times when you need a computed comparison, say with a > specialized collation sequence. if this sequence isn't supported by > locale or whatever, you need to do a callback comparison. i can't > think > of a real world example but maybe with some odd symbolic character > set > or a custom one. in any case, supporting the callback is easy. it has > one drawback which is that it disallows the GRT but the guts could > fallback to the ST then. in both cases, key extraction is the same.
Hmm. If this is all, then I think it's worth putting the onus on the developer to write a better key extractor. What you're saying, basically, is that the "special comparator" would be doing dynamic key generation. IMO, let the developer write a xxx_2_UTF32 key extractor. In all likelihood, once it's written he may find a way to use that format throughout the code. =Austin
