Clars wrote
> In Irv's example below, there's an accessor handler, mGetNumberOfApples,
> that returns info about a specific property.
> If my behavior has, say, 5 properties I want to access, I'd be tempted
> to write an all-round handler like:
>
> on getProperty me, prop
> return value(prop)
>
Clars,
While I obviously fully understand the problem, here's one way to
think of using a parent script. Take any code in your "master"
behavior that doesn't deal directly with putting sprites on the
screen, and make a single global object out of it. So, move things
like your folder info, f
Irv Kalb wrote:
> Wow, an entire discussion on OOP, and I'm out of the office for one
> morning.
-Sorry you missed out on all the fun!
> One quick comment. In your original message you mentioned that there
> were five different properties that you wanted to get and/or set from
> a behavior.
At 8:27 PM +0100 12/15/00, Clars wrote:
>Thanks again for input, all.
>
>Karina - any sources for naming conventons? I use p for property and g
>or m for global variables(project global or movie global), but that's
>about it.
>
>Jakob- I sent my post before I read yours. I suppose that specificall
Thanks again for input, all.
Karina - any sources for naming conventons? I use p for property and g
or m for global variables(project global or movie global), but that's
about it.
Jakob- I sent my post before I read yours. I suppose that specifically
writing seemingly redundant access handlers g
> Otherwise you might as well program with movie script
> handlers and 500 globals ;)
I once inherited a huge app that was programmed exactly this way (but
far worse than you can imagine), and it was truly four months of
sadness. I would never wish this on anyone.
> Another example of "form" tha
>
> I'm trying to decide how seriously I should take the school of high
> object integrity in Lingo. When I do, I feel I'm doing it for form's
> sake. Still, I'm hoping that adhering to these strict and seemingly
> silly rules will someday take me to the moment of OOP
> enlightenment that
> some t
> Writing a lot of redundant handlers is almost always 'pure OOP'. I
> think the meaning of not accessing the properties directly is that
> you will be allowed to change the inner workings of the script a lot
> without changing in any of the calling handlers.
I can begin to see the outlines of t
Thanks Bjarne,
for the eye-opening examples of property access; I'm sure they can be
useful.
Until now, I had just used sprite(1).propname to get the value.
However, the direction of my question was more about the OOP "ethics" of
accessing properties directly, and how to find the balance betwee
At 11:40 +0100 2000_12_15, Clars wrote:
>on getProperty me, prop
> return value(prop)
>end
You can declare which propNames are "public" and allowed access to
through the universal accessor method, like so:
case prop of
#kjfkd, #jsfif, #fsf:
return me[prop]
end case
return "error: blah
> If my behavior has, say, 5 properties I want to access, I'd be tempted
> to write an all-round handler like:
>
> on getProperty me, prop
> return value(prop)
> end
>
> which could be accessed with:
>
> theValueI_need = sendSprite(whateverSprite, #getProperty,
> "propertyName")
>
> However, thi
> put sprite(1).scriptinstanceList[2].getPropAt(2)
Tsk Tsk... That's accessing the sprite's properties directly - a definite
no-no for OOP :)
But it can be useful for property manipulation inside the sprite script
itself.
Karina
[To remove yourself from this list, or to change to digest mode
Writing a lot of redundant handlers is almost always 'pure OOP'. I
think the meaning of not accessing the properties directly is that
you will be allowed to change the inner workings of the script a lot
without changing in any of the calling handlers.
You can change the prop names, data type,
> If my behavior has, say, 5 properties I want to access, I'd be tempted
> to write an all-round handler like:
>
> on getProperty me, prop
> return value(prop)
> end
>
> which could be accessed with:
>
> theValueI_need = sendSprite(whateverSprite, #getProperty,
> "propertyName")
>
> However, thi
> However, this would seem to be a rash and dangerous balance on the edge
> of broken encapsulation. 'Cuz, I need to know the property name. It just
> seems to me that if I know the handler name, then I'm not ridiculously
> far from knowing the property name.
Consider this
in a behavior attaceh
Hello all in the Lingo OOP coven-
I ran across an old thread from April on OOP basics. I wish to point out
at this time that I have not been studying it SINCE April...
I have included Irv Kalb's example about accessor methods below. I
understand it. No, really. At the risk of having to go throug
16 matches
Mail list logo
