From: Beman Dawes (bdawes_at_[hidden])
Date: 2003-06-26 19:39:25
At 04:21 PM 6/26/2003, Brian McNamara wrote:
>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.
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk