whoa, is that a mess. the only surprise is that you get such a benign error message with such egregious code.
first, never nest named functions. second, what the heck are you trying to do?
as I said this is not actual code (several hundred lines) but just a contrived example modelling the application structure. While it is still something different, lets assume that the dummy class represents polygons (so it derives from array and would implement useful methods like finding total length, area, center of gravity).
The static function could be intersection
I am using quite a few nested functions in this project - they have access to local variables of the enclosing function. Without the m I wouldhave to pass in a handful of variables (or an object grouping them together)
I have already noticed that nested functions are a mixed blessing, because there are fewer compile-time checks (such as number and type of arguments). However, they exist, so why shouldn't I use them?
One of the things I stumbled over: when I got the error, I tried one thing ... that did make the code work in the end: I removed the static attribute from the function and changed the main class to call it as a method of the first element of the array (which is certainly making it unreadable)
1 person found this helpful
nested named functions don't work. and, i can't help you with abstracted code. it's too frustrating on my part.
someone else may be willing and able to help you, if you're patient.
>> nested named functions don't work
it is a bit disappointing to find that, after writing some 2000 lines that make heavy use of a feature. Is that some knowledge buried inside a manual, or is it just common experiece by others who tried it before?
Thanks for replying - even if it is somewhat bad news
i don't have much formal training so almost all my knowledge is trial and error and reading the flash help files. but it doesn't take much to see that flash handles named functions in a, perhaps, non-intuitive way. for example:
// b() is undefined. the compiler should complain if you're using strict mode (which you should be using).
also, if you define a named function on a movieclip frame (that may eventually or may not ever play), that function will be defined as soon as the movieclip exists. eg, you can define a named function on frame 200 of movieclip mc and, on the frame frame where mc is defined, mc.thatfunction() will work before frame 200 plays (and frame 200 need not ever play).