Re: [boost] Re: Interest in FC++?

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.

--Beman