>>>>> "AH" == Austin Hastings <[EMAIL PROTECTED]> writes:
AH> --- Uri Guttman <[EMAIL PROTECTED]> wrote: >> 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. AH> Hmm. If this is all, then I think it's worth putting the onus on the AH> developer to write a better key extractor. possibly. AH> What you're saying, basically, is that the "special comparator" would AH> be doing dynamic key generation. not exactly. key extraction is getting the key out of the record. there could be some munging applied at that phase as well. comparison is just a replacement for <=> or cmp. it could be some strange collate sequence based on specialized data. a contrived example is sorting by length but only for strings beginning with i-k, otherwise go with alphabetic sort. you would have to extract a dummy length value for the keys which don't start with i-k and the name would be the second key in all cases. but there are more complex cases where it is easier to put the logic in the comparison code instead of the key extraction part. the issue is that the comparison could have logic beyond simple comparisons. so we do need to support the compare code block or sub callback. as i said, when you use that you could (if we do it this way) lose major speedups but that is a standard penalty to pay when you need custom code in the comparison. uri -- Uri Guttman ------ [EMAIL PROTECTED] -------- http://www.stemsystems.com --Perl Consulting, Stem Development, Systems Architecture, Design and Coding- Search or Offer Perl Jobs ---------------------------- http://jobs.perl.org
