From: Kirby Urner [mailto:urnerk@qwest.net]
You're welcome to your opinions. Sometimes you whine when it seems your opinions are taken for what they're worth though, which *sometimes* (not all the time) ain't much in my book.
We are in agreement. That is precisely when I whine. But there are times, in my view, where a naïve view is quite worthy of expression, provided it is recognized as such. I believe I both recognize when I am presenting a naïve view, and when such a view is worthy of expression. So I find that rejecting it as naïve is fundamentally unresponsive. Art
So I find that rejecting it as naïve is fundamentally unresponsive.
Art
However in this case I don't think your views were rejected as naïve. On the contrary, your views permeated a sophisticated discussion of use cases, and design patterns more generally (s'been a rich thread) plus Scott sort of liked your using () to connote dynamism (I didn't). The tone was always peer to peer. And we came out in different places re properties, which is fine. I'm not going to change my ways just because of peer group considerations -- I'm not that feckless. Kirby
Kirby Urner wrote:
So I find that rejecting it as naïve is fundamentally unresponsive. Art
However in this case I don't think your views were rejected as naïve. On the contrary, your views permeated a sophisticated discussion of use cases, and design patterns more generally (s'been a rich thread) plus Scott sort of liked your using () to connote dynamism (I didn't).
This is close to what I meant. I dislike properties that don't behave as if they were attributes. That is, I'd like two accesses to the same property of a particular object to return the same value until the object has been "changed," and I don't like read access to a property to be a "real" change. There are three exceptions I allow in my personal aesthetic: * debugging code: All's fair for this case. Properties are _golden_ for allowing tracking things into a lot of code without changing that code. * instrumentation: Measurements can be accumulated about behavior, but shouldn't interact with normal operation. * performance: Achieving the same results with different performance is often the whole point of systems programming style programming. --Scott David Daniels Scott.Daniels@Acm.Org
-----Original Message----- From: edu-sig-bounces@python.org [mailto:edu-sig-bounces@python.org] On Behalf Of Scott David Daniels
This is close to what I meant. I dislike properties that don't behave as if they were attributes.
Not exactly sure what that means. Seems there is a lot to this topic. I get to the fact that there is a Uniform Access Principle - with some authority behind it. """ The Uniform Access Principle, as published in Bertrand Meyer's Object-Oriented Software Construction, states that "All services offered by a module should be available through a uniform notation, which does not betray whether they are implemented through storage or through computation." It is described further with "Although it may at first appear just to address a notational issue, the Uniform Access principle is in fact a design rule which influences many aspects of object-oriented design and the supporting notation. It follows from the Continuity criterion; you may also view it as a special case of Information Hiding." """ I guess I am intuitively anti-Meyerist. And am hoping he is quite wrong in the assessment that "information hiding" is a base requirement for information science. ;) Kirby seems comfortable in the Meyerist camp. But I feel my anti-Meyerist sentiments are somehow bound to my pro-Python sentiments. So am having trouble with my Meyerist Python friend's stance. Art
Kirby seems comfortable in the Meyerist camp.
I think you might be reading something too sinister into "information hiding" and are therefore against it. The brutal real world truth is the client wants an API that works today, but will complain if it doesn't deliver tomorrow, even if specs shift in the mean time. A lot of programming arises from this dual use: freedom to use now, freedom to change it under the hood later. Properties help insert a layer between mutable programmer code and a slick API that clients like and want to keep using. It's a matter of keeping a favorite notation relatively static, thereby insulating users from messy inner details. That's *one* meaning of information hiding, and I think a benign one. My world assumes you have access to source code. Information hiding is relative to something. If you have no source code at all, then it's all hidden, and so what's the point of even talking about what's hidden or not?
But I feel my anti-Meyerist sentiments are somehow bound to my pro-Python sentiments. So am having trouble with my Meyerist Python friend's stance.
Art
I think you're espousing an open source ethic, but maybe confuse the purpose of properties with something "information hiding" needn't mean. It could just mean a notational integrity that insulates programmers from other programmers. It's like wearing business suits or casual dress. We don't want to keep adjusting our eyeballs from one freakazoid API to another. Just give us a uniform integrated control panel please, and do your behind the scenes work behind the scenes (but let us peek if we get curious). Kirby
participants (3)
-
Arthur -
Kirby Urner -
Scott David Daniels