> 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 _______________________________________________ Edu-sig mailing list [email protected] http://mail.python.org/mailman/listinfo/edu-sig
