Re: Types, packages & objects : the good old naming conventions question (without religious ware)

["Jeffrey R. Carter" <spam.jrcarter.not@spam.acm.org>]

Hibou57 (Yannick Duch�ne) wrote:
> 
> An example trap (to me at least) : what about a type which would seems
> obviously named Size and a parameter which seems obviously named
> Size ? X would surely not be OK, neither Item.

If Size is the best name for the parameter, and assuming this a numeric value, 
then I'd call the type Size_Value.

> An idea may be to get a more or less close synonymous (like Count...
> not very good) for the parameter for which one may naturally be
> tempted to name Size. But this seems (and is) a work-around, and if
> the word � work-around � really legitimately applies on that
> situation, this means there is a trouble (not natural, at least). Why
> the work around will probably applied on the parameter ? Because the
> parameter comes later when the type definition is already introduced
> (in the worst case, it may be tempting to change the type name). This
> latter detail makes us to come to another aspect of the trouble :
> choosing a practicable type name, may requires an amount of prediction
> over what instance names may be.

I think that you shouldn't be writing anything until you've decided on the type 
and its operations, including their parameters.

This isn't trouble. A type is usually only part of what you're creating, and 
it's important to think about the whole thing before committing any part of it 
to code. This is especially true for the visible part of a pkg spec.

-- 
Jeff Carter
"C's solution to this [variable-sized array parameters] has real
problems, and people who are complaining about safety definitely
have a point."
Dennis Ritchie
25