Gerhard Fiedler wrote: > On 2006-07-15 06:55:14, mystilleef wrote: > > > In very well designed systems, the state of an object should only be > > changed by the object. > > IMO that's not quite true. Ultimately, the state always gets changed by > something else (user interaction, physical events); very few objects are > completely self-contained in their behavior. >
Then in those cases the system becomes a victim of high coupling. > In most systems (and you possibly have written some of them) are objects > whose state gets changed by other objects -- possibly through the > intermediation of setter methods that do nothing else but set the state. > There's no conceptual difference between directly setting the state or > calling a setter function that does nothing else but directly setting the > state -- except for one unnecessary level of indirection in the latter. > It depends. If certain conditions need to be met before changing the state of an object, then arbitrarily changing it can be dangerous. I gave an example earlier. > > For example, a third party randomly changing is_active, (which Python > > lets you do freely and easily) from False to True may crash your GUI. > > And I'm not making this up. Things like this do really happen depending > > on the whackyness of your toolkit. > > That's quite true, but a setter that does nothing but change is_active > doesn't prevent this. If there is logic necessary to prevent state changes > in certain situations, this should be implemented. But whether you then > call this a part of the "behavior" (looking at the implementation as being > a setter method) or a part of the "state" (looking at the implementation as > being an added feature of the attribute) doesn't really make an objective > difference. > Of course using setters for the sake of just using them is pointless. The reason to use them is if pre-conditions or post-conditions need to be met. Or to control access to an objects states. > > So sometimes, it is my duty to protect the state of an object. > > Of course. > > > Which is programming objects based almost entirely on state and behavior. > > As you can see this has nothing to do with Python vs Java's vs X's > > implementation of accessors and how using them sucks, or how they aren't > > Pythonic. Some domains just require this stuff. > > Yes, but you seem to still be stuck in the paradigm that setting the state > is behavior if it comes from the outside -- probably because some languages > implement that way. > Not at all. Behaviors are just methods of an object. They are behaviors whether they are called internally or externally. > I'm not (yet) a Python programmer. To be honest, the one single feature > that attracted me to Python is the structuring by indenting... I never > understood why we have to indent (to be able to read) /and/ brace (to make > the compiler happy) in other languages -- I always thought that if > indenting helps me to understand the structure, the compiler should be able > to read exactly that :) > > I come from a mostly C/C++/Java/PHP background, apparently similar to > yours. GUI, embedded, whatever. But I can understand that the difference > you are making is not based in a concept, it is based in an implementation. > > It is an artificial difference to say that > > o.is_active = true > > is modifying state, whereas > > o.set_active( true ) > > is dealing with behavior. Either way you are changing the state. Behavior, > that is, doing something, implies state change, one way or another, > sometimes relevant, sometimes not. There are (often embedded) systems, and > well-designed ones, that basically don't deal with what you call behavior > at all and handle everything through state change (of signals). Such > systems can be rock-solid and quite complex, and have a lot of "behavior". > And there are systems that do everything through what you call behavior > (e.g. getter/setter type implementations). Both types can work, both can > achieve the exactly same; this is just an implementation detail. > If all set_active does is change is_active's state, then set_active is pointless. See above for my point on the issue. > > And this is why many overzealous OO languages do "force" you to use > > accessors. > > I'm not sure why you keep on harping on this. It seems to have been clearly > stated that in Python, every attribute /is/ an implied getter/setter pair > -- it's up to you to just let the language use the default (simple) > implementation, or override it with your own logic. It is also up to you to > call this added logic then a feature of "behavior" or of "state". > > > Thinking in terms of state and behavior is, because it works regardless > > of programming language or implementations. > > Agreed. But the distinction is not universal, objective, it is subjective. > Where you make it is your choice. As the examples above show, there are > well-working solid systems out there that work on both ends of your > spectrum: only behavior is exposed, or only state is exposed. Both can > achieve the same. It is a subjective choice to call this > > o.is_active = true > > state or behavior... the underlying setter implementation for is_active can > do everything you want your behavior to be -- or it can be the simple > straightforward default setter. It's just a subjective thing to say that > this is in the realm of behavior or of state. Didn't you say that state > changes can crash a system? That's behavior, as far as I am concerned :) > And there is little if any behavior that doesn't change the state -- > especially setters are known to do that :) > > Gerhard State - behavior is not something I made up, so it isn't subjective. It is a common term used in OO literature. In fact, the only reason I used it is because I thought is was common knowledge. And behaviors are not just necessarily getters/setters, they are methods of objects. -- http://mail.python.org/mailman/listinfo/python-list
