new() and weird inheritance

From:         Brennan Young 
Subject:      Re: new() and weird inheritance
To:           DIRECT-L@UAFSYSB.UARK.EDU

Martin Langhoff  wrote

>I'm finding a bit weird that the 'on new' handler of an ancestor gets
>executed when director gets to the line where it is declared. Could not
>find details on that on the manuals, except for the mention that you can
>dynamically re-assign the ancestor property (but doesn't mention that on
>such assignment, the ancestor's 'new' handler will get executed).
>Anyhow, I guess its implicit in that you are calling 'new (script
>"foo")' but its quite a problem for me. The only workaround I can find
>is telling the 'new' handler to just call another function that I _can_=20
>override (or maybe can't I?). I'm all messed up, if someone with a bit
>of OO experience can chime in, I'll be thankful.

I'm not sure I understand your question here. You're wondering why the
new function gets invoked when you call it? Why would you expect this
not to happen?

It's true that the new() function is one of the most weird and powerful calls.
I recently discovered that you don't even need a new handler in a script
to call a new function on that script, but the script must contain
SOMETHING (a simple comment will do) for it to have any associated
bytecode to hook into. Try it.

It might help to know that you can actually use the script object itself
as an ancestor:

set ancestor to script("xyz")

This is called an 'abstract data structure': there is only one of them.
If other objects set their ancestors to the same object, their ancestors
will share exactly the same properties. Sometimes this is very useful,
especially because script objects are global (sort of) and retain their
property values whether or not the movie is running.

Alternatively, if you decide to create multiple instances from the
script with the new() function, you are using it as an 'abstract data
type', so you can have many instances of that type, each with their own
values for the properties.

If you don't want to create new objects every time you swap ancestors,
what about using script objects, or even creating all the ancestors in
advance and then swapping to them later?

Maybe what you're after is something like this.

--score script "Chimera"

property ancestor, extraAncestors

on beginsprite me
  set extraAncestors to []

  repeat with n in ["mammal", "reptile", "bird"]
    add extraAncestors, new(script n)
    --or alternatively...
    --add extraAncestors, script n
  end repeat

  swapSuperclass me
end

on swapSuperclass me
  set ancestor to getat(extraAncestors, random(count(extraAncestors)))
end
--

BTW, I haven't ever needed to swap ancestors, there is always another
way of doing the same thing. It's an interesting feature of Lingo, but
it's very rare in OO. It would be interesting to find some good reasons
for ancestor swapping, by which I mean

Does ancestor swapping make anything any easier?

and

Is there anything that you can achieve with ancestor swapping that you
can't achieve in another way (case... for example) which is as simple or
 simpler?

The only thing I can think of is layer sorting with sprites, which is
largely a matter of manipulating the scriptinstancelist of the sprites
in question. Any other ideas?

--
>OTOH, I'm finding extremely weird that when Lingo finds something like
>if listP(thisItem) and getAt(thisItem,n)=3D"wow" then....
>and I feed thisItem with anything but a list, it halts and says that it
>can't do a getAt, on, say, a string. Why would it try to, it found the
>first statement in the AND to be false, why does it go on

Because it's not been designed properly. Not exactly a bug, but pretty
close, this is one of the dumbest things in Lingo and I'll bet it's not
fixed in D7. (Any comments Macromedia?)

We could say that Lingo is 'gramatically challenged' in its
understanding of AND. It's been like that for ages. You have to make a
nested 'if' to deal with this puppy, which of course is slower. Live
with it for now, but complain after D7 comes out. Thanks for reminding
me, I'll make sure it's on my wishlist.

--
_____________

Brennan Young

D. Plänitz