>While some of these names are ones that I have made up, and thus can be >changed "on a whim" to lowercase versions, there are still two classes >of naming issues which I hesitate to change: > > Haskell names. Many functoids (like enumFromTo, takeWhile, zipWith, > etc.) and datatypes (like Maybe) have the exact same names and > behavior as their counterparts in the Haskell programming language. > I've named them this way to cater to programmers coming from a > Haskell background, and am hesitant to change them.
Don't underrate Haskell programmers. The ones I know have the kind of minds where if you switched the names to pig latin, they wouldn't skip a beat.
> Functoid types. The obvious alternative to naming the type of a > functoid with a leading capital letter (e.g. "compose" has type > "Compose") is to add a suffix (e.g. make it so "compose" has type > "compose_type"). Functoid type names are used a lot, though, and I > am not fond of the idea of making the type names longer than the > names of the instances.
I personally dislike the use of _type in such cases, but I think consistent naming has enough advantages that it wins out over personal preferences. I probably won't vote against a library which used such names for Functoid types, particularly if it represented an important body of existing code, but why run the risk?
>I dunno if either of the examples above constitutes reason enough to >bend the rules with regards to naming conventions, but I want to ask.
One case I'm aware of where it makes a lot of sense to bend the rules is with certain few mathematical names which traditionally changed meaning when their case changed. That's a pretty strong argument. But almost all other cases come down to personal preference rather than strong arguments.
--Beman
_______________________________________________ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
