NetNews Usenet Archive 1992 #18/NN_1992_18.iso/spool/comp/object/3197

Internet Message Format | 1992-08-13 | 3.8 KB

Path: sparky!uunet!psinntp!internet!sbi!zeuswtc!pascal!rhsu
From: [e-mail] (Robert Hsu)
Newsgroups: comp.object
Subject: Re: Class methods (was: Re: How to design a data structure library)
Message-ID: <[e-mail]>
Date: 13 Aug 92 00:58:37 GMT
References: <[e-mail]> <[e-mail]>
Organization: Salomon Brothers Inc. NYC
Lines: 63

[e-mail] (Steve Mellor) writes:
>
> There seem to be two issues here:
>     (1)  Can a function be an object?
>     (2)  Is it OK to suppress detail at the analysis level?
>
> I would argue that there is an associative object, call it Copulation,
> between Man and Woman.  This object has data, has a lifecycle with
> events, transitions and actions, and finally, it has functions that
> drive the object through its lifecycle.  This is an object like any other.

    You are therefore answering yes to your first question.  This
very issue is being discussed in another thread currently, and I think
it appropriate that, talking about this "associative" object you
mentioned, we should expand the breadth of our discussion and inject
some (hopefully penetrating) insight into it.

    Can a function be an object?  By one criterion, an object
should have state information, and any action that is "durationless"
should be a simple function.  Most certainly, our object is not
durationless (if it were, the world would be a very boring place).
But perhaps by "durationless" what is meant is that the action occurs
as a single step, and that each individual invocation of it is
independent of any other.  Is this the case with our object?  At first
sight, yes, which seems to suggest that it should be a function and
not an object.  But on the other hand, does it retain state
information?  My opinion is that it does, and therefore should be an
object.  For example, this object imposes restrictions on when it can
occur (for such reasons as the phase of the moon, the direction of the
wind, the time of day, whether one is in Virginia, etc.).  This is
state information that should be kept in the object.

    Obviously, one can make a function an object.  The real
question is: should a function be an object?  Using the previous
example, some people see it as a function, noting that the elegance of
such a straightforward act is ruined when it is enveloped by an
unnatural barrier - the class protocol.  Others consider it not only
more elegant to have that protocol, but also much safer, since it
provides more protection, and they are therefore willing to accept any
inconveniences.

    My own opinion is that in general, functions should not exist
independent of a class (i.e. avoid global functions).  In practice
this seldom requires constructing artificial classes just to encompass
all functions, because most functions do not exist independent of
either their parameters or other related functions.  The first place
to look for de-globalizing a stray function is to see if it can go
into the class of any of its arguments.  If that doesn't work, the
next step is to look for a group of related functions that have some
attributes in common, and make a class for all of them.  Only when
this doesn't work are you required to make an artificial class for
just one function - but this should be done nevertheless, because even
this one function will probably have some global state information
associated with it.  What you gain from this is 100% classification (a
pun? or an eerily profound illustration of the meaning of "class"), so
that nothing exists outside of a conceptual abstraction.  This usually
also brings a soothing feeling of aesthetic achievement.

-Robert

--
    // Robert Hsu -- Salomon Brothers Inc. -- [e-mail] \\
    \\   DISCLAIMER: Opinions expressed are not necessarily mine     //