On Thu, Aug 8, 2013 at 8:01 AM, Timothy Bleiler <blei...@buffalo.edu> wrote:
> So, to the extent that it might effect preferences for the syntax, what
> are some examples of how this would be used?
>
This seems similar to the distinction between class and instance methods.
Class methods are often used to store values that all the instances share
in common. In LC, a local variable in the behavior seems like the
reasonable way to handle this. For example, if you are writing Space
Invaders and need to keep track of how many invaders are left, a local in
the behavior script for the invaders would work.
Having the scriptObject would let you store properties on the behavior
object, which might come in handy if you want to save the stack? Not sure.
It would also let you reference objects relative to the behavior object,
which I think is how we got into this quicksand. For example, if there were
a field for logging events on the same card as the behavior button, then
the behavior script might include:
on logThis someMessage
put cr & someMessage after fld "log field of the owner of the
scriptObject
end logThis
That seems somewhat contrived, and less than useful. Instead, since logging
isn't as simple as the above (you'd likely want automatic timestamping,
maybe additional formatting, etc.) you'd probably want to have a bolt-on
behavior for *that*, and that would mean that the behavior you add to the
behavior button needs to be able to reference the behavior button, which
none of this addresses, I don't think. :-/
_______________________________________________
use-livecode mailing list
use-livecode@lists.runrev.com
Please visit this url to subscribe, unsubscribe and manage your subscription
preferences:
http://lists.runrev.com/mailman/listinfo/use-livecode
