[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: NSCharacterSet bloat?
From: |
Richard Frith-Macdonald |
Subject: |
Re: NSCharacterSet bloat? |
Date: |
Sun, 29 Jan 2006 08:20:14 +0000 |
On 25 Jan 2006, at 19:11, Derek Zhou wrote:
What I was puzzled about is why a smallish utility (handful of
files), which propabably have little pratical usage other than in
base, lives outside the base.
I think two reasons ...
1. the author of the utility originally did it that way.
2. the utility has no use at all inside base, so nobody would have
changed it.
Let me elaborate on point 2 ... since this appears to be the cause of
the confusion.
The characterset info translated by the utility tells you things like
which characters are uppercase, lowercase, alphanumeric etc ... the
unicode equivalent of the standard isupper(), islower(), isalpha()
etc functions/macros. As such it's not something that users of the
base library ever need to change and there is no useful purpose
served by having the utility in the base library ... it's of use
solely when maintaining the base library in the event of a change in
the unicode version that the library supports.
Anyway, I can put all the relevent files into the NSCharacterSet dir
under base and give you a tar ball and a patch to plug it in the
overall makefile.
While I'd welcome improvements to the utility to automate checkiing
of the unicode standard to see if it has been updated, I'd rather
keep it where it is, since I see no point in adding it to the base
library... it would just use a bit more disk space without adding any
capabilities for users of the library.
I think it's better to stick to saying that you have a personal
aesthetic issue here ...
Another benefit of seperation is to give users the option of updating
charset data without recompiling base themselves. If gunstep goes
mainstream, most likely people will get gnustep from distributions and
refrain from manual installation (could mess up dependency).
But users shouldn't be updating the charsets (meaning that it's not a
normal/reasonable thing to do) ... if they *really* want to change
what characters are considered uppercase for instance, they can code
in the changes they want ... use a category to override standard
behavior, do all their checking via a function of their own etc etc.
All the same sorts of options a user of the C libraries have if they
want to change what ascii characters are considered uppercase with
isupper()