Hi Irv,

I think I understand your point, but I don't see the big difference between
my code and yours.

Both our scripts are accessor scripts. I don't change the properties of my
object from outside. My accessor script does it. As a parameter your script
gets a symbol and a value, mine gets a list with symbols and values.

Your case statements sees to it that if there's no property inside the
object for a given parameter, nothing happens, nothing breaks.

Same for my code. 

One difference between my code and yours that mine is able to change a not
limited number of properties at the same time.

Of course, for the code to make sense you have to know what parameter to
pass, but this applies to both our codes. In your case: If you don't know
that your accessor script waits for a parameter like "#wonderfulProperty:"
your script is useless. 

Ok, in your case, if you change the property pMyWonderfulProperty to
pMyOutstandingProperty in the object, the expected parameter
"#wonderfulProperty" won't change. 

But in my case, it's all completely different. The object my accessor script
resides in is an ancestor script to many different child objects. So
whenever the accessor script is called, it has a different set of internal
properties. And the accessor script has to be able to change any existing
property in any possible child object. 

This is why I choose a list for a parameter. Moreover the content of this
list - the properties to change - are never hard coded, but chosen in
runtime by a user interface.

Having explained that, do you still see another way of achieving the goal?

Thanks
Michael
 

-----Ursprüngliche Nachricht-----
Von: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] Im Auftrag von Irv Kalb
Gesendet: Donnerstag, 6. Oktober 2005 18:32
An: Lingo programming discussion list
Betreff: Re: AW: <lingo-l> setting the properties of "me" by a variable

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!]


[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!]

Reply via email to