Andrew P. Black wrote
Hi Richard,
Normally I agree with you, and prefer boolean methods
inCatagoryCc: aChar isCategorySm: aChar to categoryOf: aChar == #Cc categoryOf: aChar == #Sm
In this particular case, though, the category codes are part of the Unicode Standard, so perhaps exposing them isnât so bad. Moreover, there is meaning encoded into the symbols â for example, all the letter categories start with L. So one could write an isLetter test like this
I understand this argument, but I cannot agree with it. If I were to ask you what code points were defined in character category Mx, you would immediately go to a web site that contained the Unicode categories to find the answer. In other words, you would "ask Unicode". In general, I would expect to see: Character>>#isCapitalLetter ^Unicode isCapitalLetter: self "actually, /self codePoint/" Character>>#isLetter ^Unicode isLetter: self Character>>#isMathSymbol Unicode isMathSymbol: self Unicode's methods would look at and interpret its category information for the character ... which might be internally managed via some kind of tree structure (who knows?). And I would definitely expect to *not* see a method name like "isCategorySm:". :-) Magic numbers, magic codes, etc.: you always want there to be one definitive expert (class) and you do not want other classes usurping its responsibilities.
Character >> isLetter ^ (Unicode categoryOf: self) first == $L
rather than
Character >> isLetter Unicode inCategoryLl ifTrue: [ ^ true ]. Unicode inCategoryLm ifTrue: [ ^ true ]. Unicode inCategoryLo ifTrue: [ ^ true ]. Unicode inCategoryLt ifTrue: [ ^ true ]. Unicode inCategoryLu ifTrue: [ ^ true ]. ^ false
There is still the disadvantage that a typo in the Category name (typing #L1, for example, when one means #Ll) is likely to go undetected.
Andrew
-- Sent from: http://forum.world.st/Pharo-Smalltalk-Users-f1310670.html