There seems to be a basic assumption of ASCII identifiers. Hey, this ain't the eighties!
Let's have us an XᴍʟHᴛᴛᴘRequest. Absolutely clear with no scope for misunderstanding in either direction: Gᴄ; Rᴄ; Aʀᴄ; SimpleHᴛᴛᴘServer. Monospace font support is a little poor, but I'm sure they'll fix that up once the desire is demonstrated. Q and X don't have small-caps variants in Unicode, so acronyms will be banned from having a Q or an X in the middle. * * * * * Between the primary contenders, I end up with no firm opinion myself, but I have come up with some arguments in both directions, a couple of which haven't arisen here yet. .NET style: - Simpler to reason about and say what should be done, especially if applied entirely purely (Io, Gc, Rc) with no exceptions (not even for IO). - More convenient for some tools (e.g. Eclipse, Emacs) to work with as they have clear word boundaries there. - Natural language can be converted to it regardless of case, entirely generally (handy in code generation, reducing duplication of names). Java style (not capitalising chained acronyms): - Argh! I have this thing, what do I name it? - Is there a reason why it's XMLHttpRequest rather than XmlHTTPRequest or XmlHttpRequest? - (The solution may be to define what should be done, but it might be difficult to convince people to do it that way.) Java style (but capitalising all acronyms): - Less ugly in general - More ugly if acronyms are chained - Easier to type (hold down the shift key for most of `GC<Foo>` leading to two presses, rather than three; ditto for `SimpleHTTPServer`) You can't meaningfully convert from any of these forms of identifier to natural language; .NET fails on any acronyms, Java fails on chained acronyms. Only with an identifier style like XML_HTTP_Request can one do that. (Or small caps.) For myself, I'm content with the current convention, so my HTTP server has things like HttpVersionNotSupported and header case normalisation of "Www-Authenticate". The rules are nice and easy to apply, while it'd take a _little_ more work to produce the likes of HTTPVersionNotSupported correctly, and it simply can't be done for unknown headers—they need something like the .NET style. Sure, that isn't for identifiers, but having something recognisable like that in other parts of the language is likely a good plan. I still wonder, though: should a certain struct be named ETag or Etag? If going with .NET, I (as one who should clearly have influence approaching zero in such matters) would urge not to allow any exceptions. It's much simpler to maintain such a position. In the end, I really don't have any strong preference, so I'd probably opt for laziness and keeping the current convention. That is, assuming no one wants small caps identifiers. _______________________________________________ Rust-dev mailing list [email protected] https://mail.mozilla.org/listinfo/rust-dev
