On 11/7/10 5:02 AM, Pascal J. Bourguignon wrote:
CLHS says:
19.2.2.1.2.2 Common Case in Pathname Components For the functions in Figure 19-2, a value of :common for the :case argument that these functions should receive and yield strings in component values according to the following conventions: * All uppercase means to use a file system's customary case. * All lowercase means to use the opposite of the customary case. * Mixed case represents itself. Note that these conventions have been chosen in such a way that translation from :local to :common and back to :local is information-preserving.
What an odd corner of the CLHS, littered with the bones of extinct filesystems! This behavior that seems like it would produce unpleasantries much more than it would help anyone, violating the principle of least surprise. But we claim that ABCL will be ANSI first and foremost, so I guess we have to pay attention here…
I suppose there is no definition of "customary case", huh? Pascal suggests a notion of filesystem statistics ("99.999% of files are lowercase") but for a developer dealing with lots of Java files this isn't very releavant.
Lacking a more precise definition, I would then advocate that we declare lowercase to be the customary case across UNIX, OSX, and Windows for ABCL, patching our behavior accordingly. I thought briefly about advocating Windows to have "uppercase" as its customary case, but that is only really true in a DOS world which "modern" Windows systems really aren't any more.
And although we theoretically run on JVMs on say VMS, if we run into such needs, we might devote a user-accessible special variable to control the implementation.
Pending further comments, I'll open a ticket.