Path: utzoo!attcan!utgpu!jarvis.csri.toronto.edu!mailrus!iuvax!rutgers!ucsd!ucsbcsl!eiffel!bertrand
From: bertrand@eiffel.UUCP (Bertrand Meyer)
Newsgroups: comp.lang.eiffel
Subject: Re: Feature names (Eiffel tip of the week #2)
Keywords: Consistency
Message-ID: <142@eiffel.UUCP>
Date: 14 May 89 14:02:57 GMT
References: <137@eiffel.UUCP> <493@grand.UUCP>
Organization: Interactive Software Engineering, Santa Barbara CA
Lines: 64

From <493@grand.UUCP>, day@grand.UUCP (Dave Yost):

> I think the best way to standardize names [of features] is for them
> to appear in a very basic deferred class, parent of all
> similar descendents in which they would be used.  For
> example, a deferred base class COLLECTION could have
> an "nb_elements" feature, and all descendent COLLECTION
> classes would be obliged to use that name for the number
> of items in the collection.  So, strings and arrays
> which are obviously collections would each have an
> nb_elements, instead of a STRING having a length, and
> an array having an nb_elements.  (My preferred name for
> this feature would be simply, "size").

    The example given is typical of the need for name standardization
and I agree with the use of ``size'' as standard name. I also agree
with the desirability of having a deferred base class whenever possible.
It is of course preferable if you perceive the need for such a class right
from the start, although sometimes you will recognize it only as an
afterthought.

    (Speaking of afterthoughts, it has been pointed out to me
    that the reference to ``l'esprit de l'escalier'' in my message
    <138@eiffel.UUCP>, coming as it does from an apartment-oriented
    civilization, was culturally opaque in a suburban, one-story-house
    society.  There the correct form is ``l'esprit du driveway''.)

    When it is possible to devise such a common ancestor, however,
name consistency is usually achieved fairly naturally, since by default
the names will be the same in all descendants. Differences only arise in
descendants that explicitly rename the feature - presumably for a good reason.

    My note was going further by suggesting that whenever
appropriate the names should be the same for all features of a certain
broad category even if the signatures are not the same, precluding the use
of a single deferred routine in a common ancestor.
For example if every container class contains a feature
that represents the basic access mechanism associated with the corresponding
data structures, we may decide to call it ``at''
throughout, even though the signatures are different:

    at (index: INTEGER): T  in ARRAY [T]
                             (and STRING where T is CHARACTER)
    at: T  in STACK [T]

and so on (see original note). In this case, because the signatures are
different and the language is typed, there cannot be a common deferred
routine ``at'' in a common ancestor. Nor should there be, as these
routines are really different, not only in their signatures but more
generally in their specifications. It is because they are different that
different names (such as ``entry'' and ``top'') may initially have been
chosen.

    Because they share the same general goal, however, it is appropriate
on further reflection to use identical names so as to facilitate the task
of the client programmers, who in any case must learn and remember the
significant differences (differences of specification) but with
this approach won't also need to remember irrelevant name differences.
After a while they should feel more comfortable with the basic classes
by being able to guess the name of a feature they don't immediately recall.
-- 

-- Bertrand Meyer
bertrand@eiffel.com