RE: FLASH: making the call action behave more like a function call

[Damian Morton]

The motivation for this stack handler wasnt for mathematically recursive

functions as such, but to resolve issues with long call chains that might

cross themselves.


Im my specific case I had an event manager, which called an event handler,

which in turn called code which eventually called the event manager. I

managed to structure the code in such a way that this re-entrancy didnt

clobber things, but it got me thinking about how to organise myself better,

and how to make it easier to produce code which handles these cases.


Reserving variables such as .:arg1, .:arg2, .:arg3 isnt sufficient in this

case, unless you spend some extra time saving those variables somewhere.

This code makes it easy to do that, and in fact saves you from having to

worry about it at all.


For functions that dont have any calls to other functions in them, you dont

even need to have to Call "/stack:save" and "/stack:restore", and can

instead use local variables of the form "/call:x", as opposed to "/var:x".

This is an optimisation, but its probably better to get into the habit of

doing /"stack:save" and "/stack:restore" if youre going to use this

technique. Remember: premature optimisation is the root of all evil; chances

are that the performance hit of using this technique is minimal compared to

the debugging time required for using it incorrectly.


Making things do more than they were intended to do is a good thing, and it

reflects well on flash that this is relatively easily possible.


BTW, this thing would more properly be termed a 'sliding register window'

than a 'stack', but I digress....


> -----Original Message-----

>

From: ownerchinwag [dot] com [ownerchinwag [dot] com]On">mailto:ownerchinwag [dot] com]On Behalf Of Branden

> Hall

> Sent: Saturday, April 29, 2000 12:11 PM

>

To: flasherchinwag [dot] com

> Subject: Re: FLASH: making the call action behave more like a function

> call

>

>

> Lots of good points... I have been doing recurrsion with Flash since the

> beta of it or so, and its nice to see someone finally made a real stack

> manager.  However, for the most part that tends to be over-kill since its

> sort of forcing flash to act like something its currently not.  I usually

> have recurrsive functions have their own built in stack handlers, and just

> not worry about it otherwise. This keeps them clean and separate

> from other

> code in the movie. Also, I tend to keep some variables (usually

> arg1, arg2,

> arg3, etc) aside inside of MCs for the arguments to call actions.  This

> allows me to keep flash as OO as possible while still maintaining a decent

> amount of readability.  If you are going to be coming up to FF2K in NYC in

> July I will be giving a talk there on high-end actionscripting involving a

> lot of these techniques.

>

> -= Branden J. Hall

> -= Multimedia Developer/Instructor

> -= Fig Leaf Software

>

> ----- Original Message -----

>

From: Damian Morton <mortondennisinter [dot] com>

>

To: <flasherchinwag [dot] com>

> Sent: Saturday, April 29, 2000 6:21 AM

> Subject: FLASH: making the call action behave more like a function call

>

>

> > If you begin to use the call action a lot, things can get kind

> of hairy as

> > you try to manage passing paramaters to and from called frames.

> Often, you

> > end up clobbering variables that you wanted to maintain.

> >

> > Heres my stab at how to make the call action behave more like a regular

> > function call.

> >

> > This set of actionscripts sort of simulates a stack based function call.

> > There are two clip instances that hold variables at any point in a call

> > action. The two instances are /var and /call. /var holds local

> variables.

> > /call holds the variables you want to pass to the function you are about

> to

> > call. The first thing the called function does is Call "/stack:save",

> which

> > saves away /var, renames /call to /var, and creates a new, empty, /call

> > instance. The last thing a function does is to call

> "/stack:restore" which

> > basically does the reverse of the "/stack:save" operation.

> >

> > The upshot of all this juggling is that each "function" now has

> temporary

> > local variables in "/var", and a set of variables to communicate to and

> from

> > called functions in "/call". If a function calls itself, or calls a

> function

> > that calls the caller, each function call has its own set of variables,

> and

> > there are no collisions.

> >

> > Even if you arent using functions calling themselves (recursion), it can

> be

> > very usefull to differentiate between temporary local variables,

> parameters

> > passed to functions, and variables belonging to clip instances,

> especially

> > if there is a chain of functions calling each other.

> >

> > For the object oriented types out there, clip instances correspond to

> object

> > instances, labeled actions correspond to methods, "/var:x"

> corresponds to

> a

> > local variable of a method, "/call:y" corresponds to an in/out

> parameter,

> > and "z" corresponds to an object property.

> >

> > Heres an example of a recursive fibbonacci function implemented in

> > actionscript.

> >

> >

> > Library

> > Clip: "Stack Manager"

> >

> > Label: "init"

> > Set Variable: "top" = 1

> > Duplicate Movie Clip ("/_frame_", "call", 1)

> > Duplicate Movie Clip ("/_frame_", "var", 0)

> > Set Property ("/call", Visibility) = 0

> > Set Property ("/var", Visibility) = 0

> > Stop

> >

> > Label: "save"

> > Set Variable: "top" = top + 1

> > Set Property ("/var", Name) = "_stack_"&top

> > Set Property ("/call", Name) = "var"

> > Duplicate Movie Clip ("/_frame_", "call", top)

> > Set Property ("/call", Visibility) = 0

> >

> > Label: "restore"

> > Remove Movie Clip ("/call")

> > Set Property ("/var", Name) = "call"

> > Set Property ("/_stack_"&top, Name) = "var"

> > Set Variable: "top" = top - 1

> >

> >

> > Clip: "Fibbonacci"

> >

> > Label: "fib"

> > Comment: fib(n)

> > Call ("/stack:save")

> > If (/var:n > 1)

> >   Set Variable: "/call:n" = /var:n - 1

> >   Call ("fib")

> >   Set Variable: "/var:fib" = /call:fib * /var:n

> > Else

> >   Set Variable: "/var:fib" = 1

> > End If

> > Call ("/stack:restore")

> >

> >

> > Clip: "Stack Frame"

> > empty

> >

> > you will need to lay out your movie something like this:

> >

> > Main Movie

> >   Movie Clip: Target="/stack" ID="Stack Manager"

> >   Movie Clip: Target="/fib" ID="Fibbonacci"

> >   Movie Clip: Target="/_frame_" ID="Stack Frame"

> >

> >

> > flasher is generously supported by...

> > ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

> >  Get the last 100 messages from the flasher list NOW

> >     http://www.chinwag.com/flasher/last100.shtml

> >

> >  Flash books http://www.chinwag.com/flasher/books.shtml

> > ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

> > To unsubscribe or change your list settings go to

>

> http://www.chinwag.com/flasher or email helpchinwag [dot] com

> >

> >

>

>

> flasher is generously supported by...

> ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

>  Get the last 100 messages from the flasher list NOW

>     http://www.chinwag.com/flasher/last100.shtml

>

>  Flash books http://www.chinwag.com/flasher/books.shtml

> ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

> To unsubscribe or change your list settings go to

>

http://www.chinwag.com/flasher or email helpchinwag [dot] com

>



flasher is generously supported by...

~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

 Get the last 100 messages from the flasher list NOW

    http://www.chinwag.com/flasher/last100.shtml


 Flash books http://www.chinwag.com/flasher/books.shtml

~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

To unsubscribe or change your list settings go to

http://www.chinwag.com/flasher or email

helpchinwag [dot] com