[Golist] Sequencing function calls and passing arguments

[Moses Gunesch]

Well but, you should also know that closures are sort of a bad deal  
because they retain references that can get stuck in memory. So in  
that way, I think your system of having an arguments parameter was  
cleaner because it avoids an extra closure that retains references to  
the addCallback() arguments.

There are some articles about closures out there online somewhere if  
you search but be sure they are about AS3 / AVM2 which is a totally  
different thing than AS2 / AVM1.

You can also see the number of method closures in memory listed in the  
Flex debugger's memory profiler. You could build your system then do a  
test in Flex that makes thousands of tween instances and callbacks,  
then deletes the tweens, to see if the closures "stick" or not... I  
haven't played with that level of stuff much. However, this is also  
kind of tricky because the GC does not sweep until it needs to,  
meaning that even if closures do stick at first, your test would need  
to cycle itself infinitely so you can see how it operates over time.

Or, ignore the low level issues and just have fun, do what works ...  
in the end it won't affect things very much either way so maybe it's a  
waste of time to worry about. :-)

- m


On May 21, 2008, at 1:03 PM, Jud Holliday wrote:

> More comments below
>
> 1.       Am I going about this in an overly complicated way?/Is  
> there already a system in place to accomplish this?
>
> Like Donovan said you can already pass arguments using a nested  
> closure. However, that tends to be kind of illegible so i think that  
> your system makes a lot of sense.
>
> Thanks Donovan/Moses!  I didn’t know about nested closure. I  
> definitely prefer to keep the syntax clear, but I can use nested  
> closure behind the scenes and greatly simplify the class. No more  
> need to override the ‘dispatch’ method. Now the method in question  
> looks like this:
>
> public function addCallbackWithParams(closure : Function,  
> type:String=GoEvent.START, args:Array = null):void
> {
>             //uses nested closure to pass arguments to the function
>             super.addCallback( function():void{ closure.apply(null,  
> args); }, type);
> }
>
>
>
> 2.       If not, then does addCallbackWithParams make sense, or is  
> there another way to add the ability to pass parameters to a  
> callback in LinearGo? This seems like a really handy feature.
>
> I like it a lot. The other approach which i almost took with Go  
> (until someone pointed out the nested closure thing, at which time i  
> figured that was far simpler), was to have a special callback class,  
> that wrapped the closure, the arguments, and the GoEvent type to  
> associate the callback to. One nice thing about having such a class  
> is that you can pass callbacks in an array, and each one defines its  
> own type. However, your approach is nice and simple too.
>
> I think it's a great topic to be discussing. The ultimate thing  
> would be something that worked anywhere around the Go kit (with  
> physics animations eventually). You know Jud, I think the best  
> version of the class you're writing there would be to just implement  
> IPlayable/PlayableBase but not extend LinearGo. That way you have a  
> 'playable callback' class that can be included in groups as you're  
> doing here, but can be used directly without LinearGo's overhead or  
> extra features.
>
> Ah, I think I see what you mean. I will take a look at changing that  
> and let you know if I have questions.
>
> -Jud
>
>
>
>
> _______________________________________________
> GoList mailing list
> GoList at goasap.org
> http://goasap.org/mailman/listinfo/golist_goasap.org

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://goasap.org/pipermail/golist_goasap.org/attachments/20080521/aba5c903/attachment-0001.html