Another newbie question

[Mike Meyer]

aleax at mail.comcast.net (Alex Martelli) writes:
> Mike Meyer <mwm at mired.org> wrote:
>> My standard object interface is modeled after Meyer's presentation in
>> OOSC: an objects state is manipulated with methods and examined with
>> attributes; manipulating attributes doesn't change the internal state
>> of the object. This makes it possible to change the internal
>> representation of a class without having to change all the clients of
>> the class to match.
> Note that properties enable you to obtain the goal in your final
> sentence while letting attributes still be freely assigned -- a vastly
> preferable solution.  As far as I recall, Meyer's Eiffel allows this
> syntactic transparency for accessing attributes (since it does not
> require parentheses in function calls) but not for setting them; so you
> might end up writing boilerplate setThis, setThat, and so on, although
> at least you're spared the half of the boilerplate that goes getThis,
> getThat in typical Java...

Yup, properties are powerful things - I was very happy to see them
added to Python. And Eiffel indeed gets the same transparency by
allowing obj.feature to be a parameterless method invocation (without
having to go through the dance required to create a property), an
attribute reference, or a reference to a computed constant (a "once"
feature).

On the other hand, Eiffel specifically forbids setting attributes
directly, except for the object they belong to. This is done to
enforce the design goals I stated above: attributes are the "readouts"
for an object, and methods are the knobs/dials/etc. This also ties in
with the compiler having facilities to check class invariants. If you
allow assignments to attributes in other classes, the assignments have
to generate code to check the invariants every time you have such an
assignment, otherwise a future attribute read may come from an object
in an invalid state. If you only allow attributes to be set by the
owning objects methods, then you only have to check the invariants on
method exit.

Since I like that object model, this restriction doesn't bother me. On
the other hand, I don't find myself writing set_* boilerplate very
often - my methods tend to be written to manipulate the class rather
than the attributes. Most of the time I write such methods, it's
because Eiffel doesn't have default values for arguments. So what I'd
write in Python as:

       obj = My_class(1, foo = 23)

I write in Eiffel as:

       obj = MY_CLASS(1)
       obj.set_foo(23)

Different idioms for different languages. Trying to write Python in
Eiffel doesn't work any better than trying to write C++ in Python.

       <mike
-- 
Mike Meyer <mwm at mired.org>			http://www.mired.org/home/mwm/
Independent WWW/Perforce/FreeBSD/Unix consultant, email for more information.