> The basic idea of an accessor is that it is a specialized method
> which just gets or sets a property variable within an object, like
> this:
<SNIP>
yes, I write things like this all the time.
> The author of the article was basically saying that methods like
> these above should never be written (he would have a coronary at the
> sight of a Lingo statement that went directly into an object and got
> a value: SomeObject.pSomeProperty = 5 (don't do that!!!))
I don't
> His
> point is instead of allowing some other object to get or set a
value,
> you should always any code that manipulates a property in the object
> that defines that property.
this would seem to imply that if you have a slider behavior that
controls a QT behavior the slider code should actually be contained in
the QT behavior. is this not correct?
> In my online book at http://www.furrypants.com/loope I write about
> two views of an object - "inside" the object and "outside" the
> object. The author of this article was talking about what I refer
to
> as "outside" the object. That is, how do you view and communicate
> with the object from outside of the object - what are the methods
you
> can call in the object. This is what he was referring to as
> "capabilities". Certainly, objects can be written to do useful work
> without any accessor methods. From the outside, it doesn't matter
how
> the object does what it does. That's the essence of
"encapsulation".
but he is saying that you should not get data from an object. if you
do that is accessing the data and is verboten. correct?
I don't have any problem understanding object properties, accessors,
encapsulation or any of that stuff. I use it all the time. I was
trying to figure out how to apply what he was discussing to a basic
example like this. if you end up putting the slider code inside the
QTBehavior it starts to become almost like procedural code. you have
this large bunch of code that becomes difficult to maintain & that has
everything in it including the kitchen sink. what is the point?
Al Hospers
CamberSoft, Inc.
al<at>cambersoft<dot>com
http://www.cambersoft.com
Shockwave and Director development, Lingo programming, CGI scripting.
A famous linguist once said:
"There is no language wherein a double
positive can form a negative."
YEAH, RIGHT
[To remove yourself from this list, or to change to digest mode, go to
http://www.penworks.com/LUJ/lingo-l.cgi To post messages to the list,
email [EMAIL PROTECTED] (Problems, email [EMAIL PROTECTED])
Lingo-L is for learning and helping with programming Lingo. Thanks!]
