Xref: utzoo comp.object:3669 comp.lang.eiffel:1632
Path: utzoo!utgpu!news-server.csri.toronto.edu!rpi!zaphod.mps.ohio-state.edu!uwm.edu!linac!att!pacbell.com!pacbell!osc!jgk
From: jgk@osc.COM (Joe Keane)
Newsgroups: comp.object,comp.lang.eiffel
Subject: Re: Functions without side effects (was Old confusion)
Summary: Keep it simple, stupid.
Keywords: functionality
Message-ID: <4888@osc.COM>
Date: 7 Jun 91 19:17:46 GMT
References: <1991May30.141218.3446@mstr.hgc.edu> <327@alfrat.uucp> <1991Jun3.145924.28406@mstr.hgc.edu> <130242@tut.cis.ohio-state.edu>
Reply-To: jgk@osc.COM (Joe Keane)
Followup-To: comp.object
Organization: Versant Object Technology, Menlo Park, CA
Lines: 44

I think this is a symptom of a more general problem.  People try to make their
classes `whizzy' rather than clean and easy to understand.  They add features
because they `might be useful', rather than that there's a good reason that
the features should be part of the class.  KISS.

Suppose i'm writing a widget class.  Widgets have a property called `part'.  I
want to write methods to access and modify this property.  The way i would do
this in C++ is the following:

	class Widget
	{
	...
	  Part get_part();
	  void set_part(const Part&);
	}

This is so simple and easy to understand, you'd think everyone would do it this
way.  But no, people will manage to screw it up in new and interesting ways.

One way is by adding unnecessary functionality.  For example, they say it
`might be useful' for the set method to return the old value.  I think this is
stupid.  If i wanted the old value, i would have called get_part first.

Some people would name either or both of these methods just `part', perhaps to
save keystrokes.  I think this indicates a confusion between a method and the
value it returns.  Here is the way i see it: `widget.part' is an attribute,
`widget.get_part()' is a method call which returns the part, `widget.part()'
is a mistake since you're trying to call an object, and `widget.get_part' is a
method which would return the part if you called it.

Sometimes it may be a good idea to provide a method which combines the
functionality of two simpler methods.  But there has to be a good reason, more
than just the fact that the original two methods may be called sequentially.
For example, there may be some good reason you can make the combined method
significantly more efficient than calling the original methods separately.

And i don't mean you'd save a single function call overhead, it has to be more
than that.  If you followed that reasoning, you'd have to provide a method for
almost every pair of methods you had originally.  For example, in a list class
you'd need to put a method called
`swap_the_last_two_elements_delete_the_first_element_and_return_it'.
--
Joe Keane, amateur mathematician
jgk@osc.com (...!uunet!stratus!osc!jgk)