I would say that the way that you are trying to set these properties
violates very basic OOP principles. The principle of "encapsulation"
is based on the idea that the only thing you can know about an object
is the API (the Application Program Interface) that the object has.
This is the list of routines (methods) that you can call. The object
itself owns the implementation of these routines and can use whatever
data it needs and any algorithm it wants to accomplish the tasks.
What this means is that only the code of the object should ever have
access to its own propery variables. Nobody outside the object
should ever know about these variables. What you are building impies
some knowledge - or even "guesswork" about how the object does what
it does.
Again, I bring up the case of changing a property variable name.
Let's say you have an object "oSomething", that has a property called
"pMyWonderfulProperty". Further, assume you have some code outside
the object that tries to reach into the object and get or set this
property, using oSomething.pMyWonderfulProperty, or through a call
in the object itself that explicity gets or sets this property based
on it's name. This will work the way you want it to. But now, for
some reason, you decide that you want to change the name of
pMyWonderfulProperty to pMyOutstandingProperty. (This is something
that I do quite often to make my code more clear as it evolves.) Look
at what happens. Code inside the object continues to work fine
because you have changed all occurrances of the old name to the new
name. But, now, your external calling code will start to fail
because when it tries to set or get pMyWonderfulProperty, that
property no longer exists. In order to make this change correctly,
you must now go through every line of every program that could
possibly use this object and ensure that you change every occurrance
of pMyWonderfulProperty to pMyOutstandingProperty.
However, if you had built this mechanism with an accessor, using my
previously mentioned case statement, nothiing would break. The old
code would be like this:
on mChangeProp, theProp, theValue
case theProp of
#wonderfulProperty:
pMyWonderfulProperty = theValue
etc
and you would only have to change it to this:
on mChangeProp, theProp, theValue
case theProp of
#wonderfulProperty:
pMyOutstandingProperty = theValue
etc.
The point is that this object would be self-contained, and changes
inside the object would not force any changes to callers of the
object.
For a more detailed discussion of this, I would suggest taking a look at:
http://www.furrypants.com/loope see chapter 4
Irv
At 10:20 AM +0200 10/6/05, Michael von Aichberger 2 wrote:
Thanks to all who answered to my question.
I pretty quickly discovered by myself that setAprop was the solution.
To the question of Tom, whether I use it in a behaviour or a parent script:
Parent script is the answer. And to Irv's concern that my approach would
break encapsulation, I am not sure.
What I am doing is the following:
I have a handler in an parent script that gets a property list of possible
properties as a parameter, then steps through this list, checks, if the
script object has a property of the same name, if so, changes its value.
Like this:
on mChangeProp me, paramL
n = paramL.count
if n > 0 then
repeat with i = 1 to n
myProp = paramL.getPropAt(i)
myValue = paramL[i]
if me.getAProp(myProp) <> VOID then
setaProp(me, myProp, myValue)
end if
end repeat
end if
end
The handler is called from outside the object. Is this against the rules of
OOP?
Thanks
Michael
[To remove yourself from this list, or to change to digest mode, go
to http://www.penworks.com/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!]
--
Multimedia Wrangler.
[To remove yourself from this list, or to change to digest mode, go to
http://www.penworks.com/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!]
