Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > comp.lang.javascript > #23803 > unrolled thread

Defining functions in JavaScript

Back to article view | Back to comp.lang.javascript

Contents

  Defining functions in JavaScript AbdulFattah Popoola <abdulapopoola@gmail.com> - 2014-04-06 08:19 -0700
    Re: Defining functions in JavaScript Hans-Georg Michna <hans-georgNoEmailPlease@michna.com> - 2014-04-07 08:58 +0200
      Re: Defining functions in JavaScript "Evertjan." <exxjxw.hannivoort@inter.nl.net> - 2014-04-07 13:43 +0200
    Re: Defining functions in JavaScript Andreas Bergmaier <andber93@web.de> - 2014-04-07 18:00 +0200
      Re: Defining functions in JavaScript Thomas 'PointedEars' Lahn <PointedEars@web.de> - 2014-04-07 19:26 +0200

#23803 — Defining functions in JavaScript

Hello everyone,

I wrote about the various ways of creating functions in JavaScript: their creation styles, their characteristics and the issues developers should know about when using the various styles.

http://abdulapopoola.com/2014/04/03/defining-javascript-functions/

Kindly post your feedback.

[toc] | [next] | [standalone]

#23806

On Sun, 6 Apr 2014 08:19:01 -0700 (PDT), AbdulFattah Popoola
wrote:

>...
>http://abdulapopoola.com/2014/04/03/defining-javascript-functions/
>
>Kindly post your feedback.

Just a very minor spelling mistake:

viola -> voilà

Assuming, you mean the French word.

Hans-Georg

[toc] | [prev] | [next] | [standalone]

#23810

Hans-Georg Michna <hans-georgNoEmailPlease@michna.com> wrote on 07 apr 2014 
in comp.lang.javascript:

> Just a very minor spelling mistake:
> 
> viola -> voilà

Voilà da gamba?

-- 
Evertjan.
The Netherlands.
(Please change the x'es to dots in my emailaddress)

[toc] | [prev] | [next] | [standalone]

#23816

AbdulFattah Popoola schrieb:

> issues developers should know about when using the various styles.

You haven't named http://kangax.github.io/nfe/ though?

> http://abdulapopoola.com/2014/04/03/defining-javascript-functions/
>
> Kindly post your feedback.

Some inaccurracies/mistakes:

* "Creating a function expression is easy: just declare a function where 
the parser expects an expression and it automatically becomes a function 
expression."

The term "declare" might be confusing here, it also indicates a name 
which is optional for function expressions.

* "Function expressions are essential to achieve functional programming 
concepts like currying, partials in JavaScript."

They are a fundamental part in the expressiveness of JavaScript, but 
they're not *necessary* for functional programming. You could do 
everything with function declarations only.

* "The last way is to use the Function keyword itself, this constructs a 
function object and returns it."

No. The "function" keyword is what opens a function declaration or 
function expression, you are referring to the "Function" *constructor* 
function here. It might be a built-in global, but it's not a keyword.

* "the function body has to be parsed every time it is called."

A body isn't called, a function is. Because of that, the statement is 
confusing; you should emphasize that the function body only needs to be 
parsed when the Function constructor is called, not every time when the 
resulting function is called and the body is executed.

* "And there are potential risks from malicious agents"

Those come from *unsafe* construction of dynamic code strings, not from 
using Function() in general.

* "However for function expressions, the variable declaration is hoisted"

Not all function expressions appear inside a variable initialisation.

*   if(true) {
         //function expression because
         //it is not a source element
         function baz() {};
     }

Nope, that's a syntax error. Expression statements must not begin with 
the function keyword. See 
http://kangax.github.io/nfe/#function-declarations-in-blocks for more 
information

* "Here are some more examples of queer ways to create functions:"
     eval('f("eval")');
     setTimeout('f("timeout")',1000);

Those aren't really creating function objects, they're just evaling 
code. You could however do

     var f = eval("(function(str) { alert(str); })");


Regards,
  Bergi

[toc] | [prev] | [next] | [standalone]

#23817

Andreas Bergmaier wrote:

> AbdulFattah Popoola schrieb:
>> http://abdulapopoola.com/2014/04/03/defining-javascript-functions/
>>
>> Kindly post your feedback.
> 
> Some inaccurracies/mistakes:
> 
> * "Creating a function expression is easy: just declare a function where
> the parser expects an expression and it automatically becomes a function
> expression."
> 
> The term "declare" might be confusing here, it also indicates a name
> which is optional for function expressions.

It is not just confusing; it is *wrong*.  This is commonly referred to
as _defining_ a function.  Also, function expressions are not created; 
_functions_ (Function instances) are created when parsing function 
expressions that have been _written_.
 
> * "the function body has to be parsed every time it is called."
> 
> A body isn't called, a function is.

Of course.  Excessive use of “call” is a telltale sign for a script kiddie.

> Because of that, the statement is confusing; you should emphasize that the
> function body only needs to be parsed when the Function constructor is
> called, not every time when the resulting function is called and the body
> is executed.

Not generally true either.
 
> * "And there are potential risks from malicious agents"
> 
> Those come from *unsafe* construction of dynamic code strings,

Meaning?

> not from using Function() in general.

Hence “potential”.  That said, the entire style of the article is as 
clueless as it is FUD-ish, which is to be expected from a Googlodyte.
 
> * "However for function expressions, the variable declaration is hoisted"
> 
> Not all function expressions appear inside a variable initialisation.

Correct.  Also, the script-kiddie term “hoisted” implies the misconception 
that source code would be reorganized; that is not the case.  Instead, when 
control enters an execution context, declarations – function *declarations* 
and variable declarations alike – are parsed/acted upon before everything 
else in that context.  This only has the effect *as if* code *had been* 
reorganized; that can be clearly seen with Venkman, the JavaScript™ 
debugger.

The clueful (hacker) has a natural desire to find out how things work; they 
have studied how things work, hence they know how they work, and how to 
reuse existing, well-defined terminology to describe that; the clueless 
(script kiddie) invents new terms out of thin air instead so that they can 
manage to grasp how and why they perceive things to be, and they parrot 
terms and statements so as to appear knowledgable to their fellow 
(clueless).
 
> *   if(true) {

OMG.

>          //function expression because
>          //it is not a source element
>          function baz() {};
>      }
> 
> Nope, that's a syntax error. Expression statements must not begin with
> the function keyword. See
> http://kangax.github.io/nfe/#function-declarations-in-blocks for more
> information

As a conforming extension of ECMAScript, several implementations have 
allowed what is has been dubbed “function statements”.  So this is neither 
an expression statement nor a syntax error per se.  For example, it is not a 
syntax error in Google V8 3.23.  But this syntax is incompatible, so to be 
avoided (called “not ‘safe’” in the ECMAScript Support Matrix).

I find your last quotation confusing as it is lacking quotation marks 
because it is just source code.  It would have been better to use “|”
for all quotations from sources outside the thread in the first place.

-- 
PointedEars

Twitter: @PointedEars2
Please do not Cc: me. / Bitte keine Kopien per E-Mail.

[toc] | [prev] | [standalone]

Back to top | Article view | comp.lang.javascript

csiph-web