Typing system vs. Java

[Alex Martelli]

"Courageous" <jkraska1 at san.rr.com> wrote in message
news:1n9omt89amtbf9i07bvdasreuk5qs56v48 at 4ax.com...
>
> >> Various different rules which have crept up over the years such as
> >> "don't use global variables," and "practice strong encapsulation,"
> >> and so forth are all only distractions and are useless to the degree
> >> that in any particular context they don't satisfy Sir Occam's
relentless
> >> blade.
> >
> >Except that they often promote ease of testing, modification and
> >refactoring.  That is what gives them value.
    ...
> Note that I'm not arguing against interface and implementation separation;
> I am simplying pointing out that the rule "always have getters and
setters"
> isn't necessarily correct all of the time.

Indeed, I've become convinced that, in Python, it's a bad rule.  I think
the Pythonic idiom is to expose 'properties' (client-visible attributes) for
client use with Python syntax (obj.theattr for reading, maybe also
obj.theattr=newvalue if it's appropriate for the property to be writable),
and, if accessor functions are needed, provide them behind the syntax
screen (with __getattr__/__setattr__ in 2.1 and before, with dedicated
per-attribute getters/setters in 2.2 and after).  Object Pascal (at the
heart
of Delphi) has always worked like this (as, for read-access only, has
Eiffel;
now Eiffel has added a mechanism for write-access), and it's nice.  In
Python it also gains you a bit of performance if the common case is for
accessors to be NOT needed:-).  I think the fact the mechanism's due
for introduction in 2.2 shows I'm not the only one to feel this way:-).

So, the _specific_ rule 'always have getters and setters' is too broadly
put -- unless you amend it to 'always ensure you can seamlessly have
your code called when a property is accesses, even if you expose that
property "bare" right now'.  In some languages, such as C++ and Java,
this means the property must live behind a screen of accessor methods
(getters/setters) -- in others, such as Object Pascal, Eiffel and Python,
there is no such implication.

> IMO, this is particularly true in
> situations where you have a package of objects which are mutually
> manipulatory, but don't otherwise expose a public API.

Yes, "the [proper] unit of encapsulation is the package", not the
class (R. Martin formulated this rule for C++, but AFAIK all C++
authors share it -- it's definitely in Meyers, Lakos, Stroustrup, albeit
not always as clearly and sharply expressed -- and the rule extends
to other languages, particularly ones where "package" is a formal
concept [while in C++ you have to "synthesize" it]).

But, again, this doesn't address the general issue: that simplicity
of design and code is great, but, when it conflicts with testability
and refactoring (or reusability and reuse, too), there's a legitimate
engineering trade-off.  The (proper) rules, such as those expressed
by R. Martin, apply to a wide range of such trade-off situations, and
may well trump "surface" simplicity where other factors dominate.


Alex