> Returning functions this way doesn't imply they do not have names. I've
> successfully used pattern "return someNamed function(){ ... }" for
> debugging.

You mean "return function someNamed() { ... }", right?  That's fine by
the specs, because the FunctionExpression is allowed to have an
optional name.  (ECMA spec[1], section 13.)

[1] http://www.ecma-international.org/publications/standards/Ecma-262.htm
--
T.J. Crowder
tj / crowder software / com

On Nov 15, 7:43 am, "artemy tregubenko" <[EMAIL PROTECTED]> wrote:
> On Fri, 14 Nov 2008 01:59:07 +0300, kangax <[EMAIL PROTECTED]> wrote:
> > My only concern about this pattern is memory usage. There are many
> > functions created during branching process, yet only one is returned/
> > assigned (and is then used throughout the rest of the application
> > life). Those alternative functions are stored in a closure (e.g. in a
> > closure of "final" function) and so consume memory; every method has a
> > burden of its "branching environment" (memory-wise). This wouldn't
> > happen if we were to use function expressions (rather than function
> > declarations), but then our methods wouldn't have identifiers:
> > var someMethod = (function(){
> >   if (doTest()) {
> >     return function(){
> >       // original function
> >     }
> >   }
> >   else return function(){
> >     // alternative version
> >   }
> > })();
> > I've never found this to be a problem (i.e. lack of function "names")
> > but Tobie says that having those is useful for debugging. I'm still
> > not sure if such clarity/convenience worth memory loss. Perhaps this
> > "loss" is a non-issue and I'm just being overly paranoid : ) I
> > definitely like how clean and maintainable such pattern looks, though.
>
> Returning functions this way doesn't imply they do not have names. I've  
> successfully used pattern "return someNamed function(){ ... }" for  
> debugging.
>
> --
> arty (http://arty.name)
--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups 
"Prototype: Core" group.
To post to this group, send email to prototype-core@googlegroups.com
To unsubscribe from this group, send email to [EMAIL PROTECTED]
For more options, visit this group at 
http://groups.google.com/group/prototype-core?hl=en
-~----------~----~----~----~------~----~------~--~---

Reply via email to