Boost logo

Boost :

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, gregod at, cpdaniel at, john at