Newly revised Section 10 for ES3.1.

[Brendan Eich]

On Jul 10, 2008, at 4:02 PM, Richard Cornford wrote:

> Something like:-
>
> fucntion getSomething(arg){
>     if(caseOneTest){
>         getSomething = function(x){
>             //actions appropriate for case one
>         };
>     }else if(caseTwoTest){
>         getSomething = function(x){
>             //actions appropriate for case two
>         };
>     }else{
>         getSomething = function(x){
>             //actions appropriate for other cases
>         };
>     }
>     return getSomething(arg);
> }
>
> It is the ability to do this sort of thing that helps make  
> javascript so
> well suited to browser scripting.

Oliver Steele blogged about this kind of memoization a couple of  
years ago:

http://osteele.com/archives/2006/04/javascript-memoization

although his examples did not show top-level function being replaced.  
But it's a good point: strict mode wants to break useful (and used)  
patterns that change the value of a property created by a defining form.

 From Allen's list:

·        Illegal for a function to have duplicately named formal  
parameters
·        Illegal for a function to contain a top level function  
declaration with a function name that is the same as a formal parameter.
·        Illegal to have multiple top level function declarations for  
the same function name
·        Illegal to have a function declaration with the same name as  
var declaration.
·        Illegal for a function to contain a var declaration with the  
same name as a formal parameter.
·        Illegal to assign to a top-level function name.

I could see banning duplicate formal parameter names (I still have no  
memory of why Shon from Microsoft wanted these standardized in ES1 --  
possibly just because JScript already allowed them).

Shadowing a formal parameter with a nested function name also seems  
likely to be a mistake.

Multiple top-level function definitions having the same name? That  
must be allowed if the definitions are in separate scripts. In the  
same script, it could be a mistake, or a fast patch of some kind.  
Without #if 0 or nested comments (ES1-3 do not require them, I don't  
know of any implementations that do them either) it's hard to hide  
bulk code. Anyway, this seems less likely to be fruitful as a "good  
taste" strict-mode check, more somewhat likely to bite back.

Within the same program, function vs. var name conflict is probably a  
mistake to catch. I don't see it in web JS, but I'm not sure how  
uncommon it is. Anyone have insights?

Function containing a var x and taking formal parameter x? That's  
allowed and might be tolerated if the var has no initialiser, but if  
the var has an initialiser then it is very likely to be a mistake.  
Even when hacking and debugging it's rare to nullify an actual  
argument by declaring a var and assigning to it in the var  
declaration -- one would just assign without adding a var at the front.

/be
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mail.mozilla.org/pipermail/es-discuss/attachments/20080710/989ae8e7/attachment-0002.html