[...]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.
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.
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.
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.
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).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.
What this may boil down to is exactly Dan's suggestion that we are all comfortable with our own definition of "explicit".
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.
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 -- http://mail.python.org/mailman/listinfo/python-list
