[Edu-sig] quantum instance

[Kirby Urner]

> Speculating along those lines of course makes me an obnoxious bastard -
> but we already knew that.
> 
> Art
> 

No you're right of course.  I was conflating a lot of experience into a
story about me and the heart surgeons, but at some expense in realism.

More realistically, the point of contact between my "world of code" and the
knowledge domain of cardiology is the event-driven GUI -- that's what we
focus on and iteratively rework.  I've had my GUIs running in operating
rooms (e.g. CORIS), but these days they mostly run on back office desks at
Regional Heart Data Services (less stressful for me, plus I don't have to
change clothing just to get access to the site).

The low level methods vs. attributes thing is more within the object world
of programmers coding for other programmers.

As a FoxPro programmer, I get to interact with library objects through APIs.
FontBold is an attribute of a text field and is either true or false.  In
code:  thisform.text1.FontBold = .T. (not a method call).  DateFormat is
another attribute (not a method call) and accepts values 1-14 (e.g. 7 is
described as 'Japan' and formats a date as yy/mm/dd).

When I change an attribute at design time, I'll often see immediate changes
in the form I'm designing.  My change to a property triggers methods in the
underlying GUI that is the FoxPro IDE itself -- a very typical use case,
replicated throughout the programming world (e.g. in VPython).
 
Given I'm trying to help math teachers integrate programming into their new
math/CS hybrid course materials, the use of Python properties is more
explicit when I'm doing my flavor of Pythonic mathematics.  That's where
you'll find myvector.length triggering _get_length() behind the scenes.[1]

Your idea that an API should carry information about the underlying
mechanisms, at the expense of mirroring expectations inherent in the user's
knowledge domain, is wrongheaded.  OO is all about modeling object worlds,
meeting user expectations (where users may be other programmers), and
Python's property feature is one standard tool for achieving this.  Meeting
user expectations is neither anti-scientific nor pandering -- it's the job
of a competent programmer, including when coding for other programmers.

Your objections against having attribute syntax trigger setters and getters,
couched in some sanctimonious rhetoric about "reality" and the badness of
"information hiding" comes across on my end as bogus, poorly thought out,
reflective of your inexperience and apparently weak grasp of what OO
programming is all about.  From my point of view, you simply don't know what
you're talking about.  

I'm in no way persuaded that you have some special insight into what the
property feature is "really" intended to provide, based on some supposedly
close reading of Guido's examples.  It's there for the same reason it's in
other OO languages, to help coders build and maintain APIs that make sense
to their users.

Kirby

[1] e.g. http://www.4dsolutions.net/ocn/polys.html