Jakob Hede Madsen <[EMAIL PROTECTED]> wrote
> Ahh, subtle but important distinctions here.
> <return call (#mMethod, ancestor)>
> achieves the same as:
> <ancestor.mMethod()>
>
> Which causes the 'me' parameter in the called method, to point to the
> ancestor itself, and not to the significant subClass. The object
> begins to suffer from "split personality disorder" This has some
> consequences:
(Lots of cogent theory snipped)
Now I remember *why* I was doing it that way when I was making the
mindstorms simulator
<http://www.legomindstorms.com>
...sometimes I really wanted the ancestor to know itself as something
distinct from the sub.
Other times I wanted the ancestor to think that it was the sub, so that
the value of 'me' was always the entry point of the call, even when way
up in the inheritance chain, that way I could imagine that all the code
was one class, and ancestors were able to manipulate data, and call
handlers which were in fact overridden.
When 'I' am scared, it's not me, just some inherited animal process
activating my adrenal glands, but I experience it as 'me'.
Thanks for bringing this into focus, Jakob, it's an important point and
I've never seen it discussed in a Director related forum.
I really like the way that in Java, you are obliged to implement
abstractions in some situations. In lingo, I have to use comments to
remind myself that 'this handler must be implemented by a subclass, or
the code wont work.
I suppose you can also make sure that the 'abstract' handler contains a
bug which will still compile (such as calling a non-existent handler),
so that if you forget to override it with something useful, you get
reminded with a script error. Has anyone tried that?
> And while we are at 'call':
> I can think of these reasons for using call:
> 1: the method to call is dynamic, ie: residing in a variable.
> 2: you have a list of objects to call.
> 3: You want to be able to call one or more objects in list, with a
> method, which they may have implemented.
> Of course the list could probably be extended.
Here's a good one; It's more convenient to replace
call (#mMethod, object)
...with...
call (#mMethod, [object])
...just before the client comes to see the beta. ;)
--
_____________
Brennan Young
Artist, Composer and Multimedia programmer
mailto:[EMAIL PROTECTED]
"If you play a wrong note, play it again twice as loud and everyone will
think you did it on purpose the first time."
-Thelonious Monk
[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!]
