Another newbie question

Mike Meyer mwm at mired.org
Fri Dec 9 17:42:52 EST 2005


aleax at mail.comcast.net (Alex Martelli) writes:
> Mike Meyer <mwm at mired.org> wrote:
>> 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.
> What classes' invariants do you have to check in those cases?  E.g.,
> consider zim.foo.bar.baz() -- you do have to check the invariants of
> bar, foo AND zim, right?

Nope, just bar. Attributes display state, they don't let you change
it. Nothing you do with zim.foo or zim.foo.bar can change the state of
zim. The only invariants you need to check are bar's, which you do at
the exit to it's baz method.

> Or, in other words, having
> to spell zim.foo.bar=baz as zim.foo.set_bar(baz) [[and having to code
> boilerplate to implement set_bar]] is a style-choice (common to Eiffel
> and Smalltalk, and others) which I consider inferior to the alternative
> choice you find in Ruby or Python [[allowing autogeneration of the
> implied attribute-setter method if necessary]].

It's a style choice derived from the designers believe about what
constitutes "good design". It's not really any different from python
requiring you to spell fetch_tuple().index(val) as
list(fetch_tuple()).index(val): the language designers have decided
what's "proper" usage of some element of the language, and the
features of the language support such usage, and not other usage.

You may not agree with what Meyer believes - in which case you would
be right to reject any language he designed.

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



More information about the Python-list mailing list