accessor/mutator functions

[Steve Holden]

Andrew Dalke wrote:
> Me:
> 
>>>>> What's wrong with the use of attributes in this case and how
>>>>> would you write your interface?
> 
> 
> Dan Sommers:
> 
>>> 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.
> 
> 
[...]
> 
> Your "tell_the_device_to_change" is my "self.target" and your
> "read_the_temperature_from_the_device" is "self.current_temperature".
> In some sense it comes down to style.
> 
Indeed, but it also comes down to control paradigm. I don't *know*, but 
I'll make a guess that Dan, who admits to being "old school", hasn't 
done a lot of work with GUIs, which are inherently event-based.

The difference between your approaches to controlling an external 
process appear to me to be very similar to the differences between the 
traditional "we ask the questions" approach of a batch program (where 
the program logic dictates the sequence of inputs) and the "what just 
happened" approach required by event-driven GUI-based programming.

> BTW, had I done this for real I would have two layers, one
> which is communications oriented ("send 'get current temperature'
> message to device") and my object model which uses the messaging
> interface underneath.
> 
> 
>> 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.
> 
Well, you are clearly more up-to-date on Pascal than me, and I blush to 
recall that I used to *teach* the language (back when "structured 
programming" was supposed to be a novelty).

> 
> To give a more recent example for me, which I covered here some
> years back, I wrote an OO interface to an "OO-ish" C library
> for doing chemistry.  In the data model, atoms have an atomic
> symbol, a charge and a list of bonds (and many other things).
> Bonds have a bond type and the two atoms at the ends of the bonds
> (and many other things).
> 
> I liked being able to say:
> 
> print atom.symbol, "with charge", atom.charge, "has", \
>       len(atom.bonds), "bonds"
> 
> for i, bond in enumerate(bonds):
>   print "bond", i, "has type", bond.bondtype
> 
> To me this is a very natural way of querying the data and
> traversing the data structure.
> 
> Now underneath the covers it looks like this:
> 
>   atom.charge fails so use __getattr__(atom, "charge")
>   __getattr__ uses a dispatch table to get the underlying C function
>       which is "dt_getcharge"
>   return dt_getcharge(self.handle)
> 
> where "handle" is the handle used by the C library.
> 
> I figured though that this example might be more esoteric
> than my PID controller example, though in retrospect it
> looks like it might be a better justification.
> 
What this may boil down to is exactly Dan's suggestion that we are all 
comfortable with our own definition of "explicit".

Really, of course, the only things you need to make explicit are the 
ones that readers don't understand :-)

so-you-are-fine-if-there's-only-one-reader-ly y'rs  - steve