[no subject]

[Carnese@SRI-KL]

    Date: Fri, 25 Jul 86 11:43 EDT
    From: Daniel L. Weinreb

        Date: Thu 24 Jul 86 16:45:33-PDT
        From: Dan Carnese <Carnese@SRI-KL>

        Well, the obvious problem with this convention is that you have to change a
        potentially large number of function names if you ever decide to rename a
        class.  

    No, only if you decide to rename a protocol.  Renaming an individual
    class, an individual implementation of the protocol, doesn't incur that
    cost.

True enough -- renaming classes which do not add any new operations is no
problem.  But I hope you're not arguing that making it more difficult to
rename the rest of the classes is not that bad.  Moving operations around
a class hierarchy is critical to deriving appropriate protocols.

    My point is to make the distinction between names of implementations and
    names of protocols.  The generic concept of pushing, as part of a
    protocol that includes pushing, popping, and other things that make
    sense for something that implements the abstraction of
    being-like-a-push-down-list, are operations that are members of a
    protocol, and affixing a constant prefix to each one of them, to remind
    us what protocol they come from, makes sense.  This prefix need not
    necesssarily have anything to do with any particular class/flavor that
    implements the protocol.

Sure, it would be nice to be reminded of the connection between a function
nanme and a protocol.  But expressing this connection syntactically, in a
way that may require a good deal of non-local modification as the program
evolves, seems a bad idea.  What's called for is a more powerful set of
program interaction tools, so that looking at code in an editor or in
hardcopy would make these connections apparent.  Such tools are not hard to
envision, and simple versions would be straightforward additions to
existing programming environments.

    Date: Sat, 26 Jul 86 13:49 EDT
    From: Daniel L. Weinreb <DLW@QUABBIN.SCRC.Symbolics.COM>

        Date: Fri, 25 Jul 86  10:54:13 PDT
        From: Alan Snyder <snyder%hplsny@hplabs.HP.COM>

        Why then is there a conc-name feature (with a particular
        default) for automatically generated functions and not for those explicitly
        written?

    Well, if defflavor is going to generate functions automatically, it has
    to call them something.  If we are going to encourage a programming
    style in which you can make up your own names for instance variables as
    easily as you can make up your own names for lexical variables (note
    that careful phrasing), then using those instance variable names as
    function names is hazardous, because the naming world of function names
    is a package (broad), whereas the naming world of an instance variable
    is only a set of comixed flavors (narrow).  If we assumed a much finer
    granularity for packages, then perhaps the default conc-name feature
    would not be appropriate.  I guess this is what you mean about the
    particular interaction of OOP and the use of packages.

The real problem is that defstruct doesn't allow any way to distinguish
between ``internal'' and ``external'' instance variables.  A conc-name
option which was applicable to the former but not the latter would allow
both of you to easily get the behavior you want.

-- Dan