accessor/mutator functions

Dan Sommers me at privacy.net
Mon Feb 28 21:01:29 EST 2005


On Tue, 01 Mar 2005 01:39:13 +0100,
Thomas Lotze <thomas at thomas-lotze.de> wrote:

> Dan Sommers wrote:

>> I think I'd add a change_temperature_to method that accepts the
>> target temperature and some sort of timing information, depending on
>> how the rest of the program and/or thread is structured.

> But then you put application logic into a library function. Doing this
> consistently leads to a monster of a library that tries to account for
> all possible applications. Where does this leave the KISS principle?

Maybe I'm "old school," but I usually end up with lots of layers in
between library functions and application logic.  If I think my
"library" layer is too big, yes, I will add another layer of abstraction
around it.  Nothing says that my application has to talk directly to
every low-level library function.

>> In the case of simply reading the current temperature, and not
>> knowing what's inside that device driver, I'd still lean away from
>> exposing a current temperature attribute directly.  I think part of
>> my thinking comes from my old Pascal days, when it made me cringe to
>> think that "x:=b;" might actually execute a subroutine rather than
>> just copy some memory around.

> Then you also avoid lists, dicts and, ironically, methods. Accessing
> methods means to access a callable attribute, after all, with all the
> stuff going on behind the scenes on attribute access.

By that logic, I'd also avoid Python, which, obviously, I'm don't.

When I see a simple construct like "a = b," or "a = b[ 2 ]," or even
"a.b.c = d.e.f," I would like to think that nothing "magic" (for some
suitable definition of "magic") is happening.  Yes, in a language like
Python, a lot more is happening (and a whole lot more *could* happen)
under the hood than in the extremely roughly equivalent "move.l d1,d2"
in assembly language.

I guess we all have our own personal tolerances for "Explicit is better
than implicit."

Regards,
Dan

-- 
Dan Sommers
<http://www.tombstonezero.net/dan/>
μ₀ × ε₀ × c² = 1



More information about the Python-list mailing list