NetNews Usenet Archive 1992 #16/NN_1992_16.iso/spool/comp/object/3077

Text File | 1992-07-30 | 3.9 KB | 93 lines

Xref: sparky comp.object:3077 comp.lang.eiffel:1029
Path: sparky!uunet!psinntp!internet!sbi!zeuswtc!pascal!rhsu
From: [e-mail] (Robert Hsu)
Newsgroups: comp.object,comp.lang.eiffel
Subject: Re: Class methods (was: Re: How to design a data structure library)
Message-ID: <[e-mail]>
Date: 30 Jul 92 16:19:21 GMT
References: <[e-mail]> <[e-mail]>
Followup-To: poster
Organization: Salomon Brothers Inc. NYC
Lines: 80

[e-mail] (Jan Steinman) writes:

> I think the hang-up on queries or commands is getting in the way here,
> as is the class-object distinction. Objects are created continuously
> and rapidly; many messages need to return newly created objects, and
> if you insist that only classes can return new objecs, you'll get in
> trouble quick!

    My understanding of Smalltalk is that, indeed, only classes
can create new objects.  If an instance method returns a new object,
that object must initially have been created by a class object.
Assuming this is true, then the set union operation can simply be an
instance method, and still be considered clean, because it is not
creating a new instance.  Rather it is invoking the class object to
create the new instance and passing it back.

> ... aMan and aWoman collaborate to create aChild
> -- they don't ask either Manness or Womanness to do it for them!

    Of course, this is an over-simplification.  A lot of
interesting actions must be performed for this to happen, most of
which occurring in the early stages; but most importantly, deep in the
code somewhere, after the member access methods at the beginning, and
before the delivery of the exit message at the end, there must be a
call to the appropriate class object to create a new Man or Woman.  So
even though the appearance is that aMan and aWoman did it on their
own, (and presumably want to take all the credit despite having
enjoyed the experience), in fact a higher, more metaphysical thing
happened - appropriately, invoking a metaclass.

    (Upon re-reading the previous paragraph, I am quite impressed
with its profundity, and think I may have unwittingly discovered the
answer to life, the universe, and everything.  But then again I am
easily impressed with my own work.)

    Going back to the original issue, there is no need to make the
set union operation specifically a class method simply because it
creates a new instance, since new instance creation will be done by
the class object ultimately.  Given that it does take two existing
sets to have a union, it makes sense for the operation to be an
instance method.  Besides, I don't think that it's possible in
Smalltalk to invoke a class method on one of its instances, so if you
were to make "+" a class method, you won't be able to make it an
operator, meaning you can no longer write:

    c := a + b.

    Someone mentioned that C++ does not have class methods.  C++
does have static member variables and functions, which are pretty much
equivalent to Smalltalk class variables and methods.  C++ also offers
a solution to this problem for those who insist on considering set
union a global operation: you simply implement a global operator for
it that does not belong to the Set class.  Of course you can also
implement it as a regular member function:

class Set {
...
    Set operator+(const Set&);                     // as member function

    friend Set operator+(const Set&, const Set&);  // as global operator
...
};

    Either way, you invoke it like this:

    c = a + b;

    To take a real C++ example, the C++ Standard Components from
USL contains a Set class which has (among others) a union operation
overloaded by the "|" operator, implemented as a regular member
function (i.e. invoked on an instance).  Using it, one would write:

    c = a | b;

------
Robert

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