mystilleef wrote:
> Bruno Desthuilliers wrote:
>
>>mystilleef wrote:
>>
>>>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.
>>
>>Time to burn your book and face reality. ObjA sends message Msg1 to
>>ObjB. Part of the associated behaviour is that in responce to Msg1, objB
>>changes it's own state. Practical result : ObjB's state has been changed
>>by ObjA. Practical question : how do you hope to avoid this "hi
>>coupling" (lol), apart from making all your objects totally autistic ?
>>
>
>
> Are you serious?
Deadly serious. But I'm afraid you're still missing the point.
> Well, you design an object that serves as a mediator.
> All objects can then only interact with themselves and the mediator
> only. Via signals, objects learn to automatically adjust their states
> and respond to events.
signal -> message -> method call -> change state.
Spell it how you like, add as many indirection levels you want, it still
boils down to the fact that *something* triggers the state change.
> This is just one of several methods you can
> dramatically reduce coupling.
It's just one of several methods that dramatically increases complexity,
without changing anything to the fact that in the end, *practically*,
some object ObjA changes its state as a response to a message sent by ObjB.
> I'm sure glad I didn't burn my book.
No comment.
>
>>>>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.
>>
>>Does this imply a 'method call' *syntax* ?
>
>
> That's language dependent.
>
>
>>Given the existence of
>>"computed attributes" (ie: support for 'attribute access' *syntax* with
>>hidden accessors) and the possibility to redefine implementation (from
>>default attribute r/w access to computed/controlled) without touching
>>the interface, why advocate the *systematic* use of computed attributes
>>when it's just duplicating the default behaviour ?
>>
>
>
> I'm not advocating anything.
cf below on this.
> I'm just stating the use case for
> accessors and the wisdom behind them. My qualm with implicit accessors
> remains the name issue.
The "name issue" is *your* problem. And AFAICT, it's a "problem" because
you refuse to free your mind from a "what's in the book" mindset.
>
>>>>>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.
>>
>>Indeed.
>>
>>
>>>The reason to use them is if pre-conditions or post-conditions need to
>>>be met. Or to control access to an objects states.
>>
>>Then why advocate *systematic* use of them ?
>>
>>(snip)
>
> I never advocated anything.
You advocated
"""
1). Make all attributes of a class private/protected .
2). If a "non-callable" attribute is going to be used outside a class,
think about making it a property and name the property well, because
you never know...
"""
>
>>>State - behavior is not something I made up, so it isn't subjective.
>>
>>The words (and the concept they describe) are not. Interpretation of
>>what is state and what is behaviour is 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.
>>
>>It is.
>>
>>
>>>And behaviors are not
>>>just necessarily getters/setters, they are methods of objects.
>>
>>Behaviour is how a given object reacts to a given message. *Nothing* in
>>this implies the notions of attributes or methods. Attributes and
>>methods are implementation details of the concepts of state and
>>behaviour, and - while this is a common implementation of OO concepts -
>> the choice to use non-callable attributes as representing the state
>>and callable ones as representing behaviour is totally
>>implementation-dependant.
>>
>
> I agree. And I already told you I think in terms of state and behavior
> and not language dependent semantics.
Then why do you advise "(making) all attributes of a class
private/protected" and systematically using properties ?
--
bruno desthuilliers
python -c "print '@'.join(['.'.join([w[::-1] for w in p.split('.')]) for
p in '[EMAIL PROTECTED]'.split('@')])"
--
http://mail.python.org/mailman/listinfo/python-list
