By using this site, you agree to our updated Privacy Policy and our Terms of Use. Manage your Cookies Settings.
437,600 Members | 1,861 Online
Bytes IT Community
+ Ask a Question
Need help? Post your question and get tips & solutions from a community of 437,600 IT Pros & Developers. It's quick & easy.

Functional question

P: n/a
Do these two give a different result?

function positive() { return true; }

var positive = function() { return true; }
Jul 5 '08 #1
Share this Question
Share on Google+
13 Replies


P: n/a
Ma************@gmail.com meinte:
Do these two give a different result?

function positive() { return true; }

var positive = function() { return true; }
No.

Gregor
--
http://photo.gregorkofler.at ::: Landschafts- und Reisefotografie
http://web.gregorkofler.com ::: meine JS-Spielwiese
http://www.image2d.com ::: Bildagentur für den alpinen Raum
Jul 5 '08 #2

P: n/a
>>no

How strongly should I interpret that:

No functional difference?

No difference whatsoever?

No subtle browser incompatibilities?
Jul 5 '08 #3

P: n/a
Ma************@gmail.com meinte:
>>no

How strongly should I interpret that:
The answer is about as precise as your question.

Read here:

http://javascript.crockford.com/survey.html

and scroll down to "Functions".
No functional difference?
I'm not sure what you mean by "functional difference", but I'd say no.
No difference whatsoever?
Different source code. The second version should take a semicolon at the
end of the statement.
No subtle browser incompatibilities?
I suppose this is "bog standard"-JS, and I suppose every JS
implementation will handle both versions properly. Maybe PointedEars
will tell you about the earliest JS version capable of both, and that
you shouldn't ask for browsers, when you mean JS implementations.

Gregor

--
http://photo.gregorkofler.at ::: Landschafts- und Reisefotografie
http://web.gregorkofler.com ::: meine JS-Spielwiese
http://www.image2d.com ::: Bildagentur für den alpinen Raum
Jul 5 '08 #4

P: n/a
Ma************@gmail.com writes:
No difference whatsoever?
function myName() { } declarations are executed before any other
statements in the same scope.

function () { } expressions are executed at the same time any other
expression would be.

IOW:

var result = gimme();
function gimme() { return 1 }

will work, while

var result = gimme();
var gimme = function() { return 1 };

will complain that "gimme" isn't a function (yet).

See Ecma 262, section 13.
No subtle browser incompatibilities?
In mozilla's JavaScript, function objects that are defined using the
"function myName() { }" syntax have a name property (myName.name ==
'myName'), while functions defined using a "function() { }" expression
have an empty string as the name property.

The functionObject.name property is not part of the ecma 262 standard
and IIRC is not supported by internet explorer amongst probably others.

See
http://developer.mozilla.org/en/docs...:Function:name

--
Joost Diepenmaat | blog: http://joost.zeekat.nl/ | work: http://zeekat.nl/
Jul 5 '08 #5

P: n/a
Ma************@gmail.com writes:
Do these two give a different result?

function positive() { return true; }

var positive = function() { return true; }
Rarely.
And it depends on where they are in the code.

The former is a function declaration. Inside a function body, it is
evaluated before any non-function declaration and before the body
is executed. It must reside at the top level of the function body, and
not, e.g., inside a branch of an "if" statement.

The latter is a variable declaration and an assignment to the variable.
The variable declaration happens just after function declarations have
been performed, and before the body statments are executed.
The assignment only happens when the execution of the body reaches
the point of the assignment.

I.e.,

// this function works and return true
function foo() {
return bar();
function bar(){return true;}
}

// this function fails since bar exists, but is still undefined in line 1
function foo() {
return bar();
var bar = function(){return true;}
}

// works and returns true
function foo() {
if (true) {
var bar = function(){return true;}
return bar();
}
}

// Can fail with "bar" not declared, since the "function bar ..."
// is syntactically not a function declaration but a function expression.
// Most browsers diverge from the specification and allow function
// declarations inside blocks, though, so it'll work in most browsers.
function foo() {
if (true) {
function bar(){return true; }
return bar();
}
}

/L
--
Lasse Reichstein Nielsen
DHTML Death Colors: <URL:http://www.infimum.dk/HTML/rasterTriangleDOM.html>
'Faith without judgement merely degrades the spirit divine.'
Jul 5 '08 #6

P: n/a
Gregor Kofler wrote:
Ma************@gmail.com meinte:
>No subtle browser incompatibilities?

I suppose this is "bog standard"-JS, and I suppose every JS
implementation will handle both versions properly. Maybe PointedEars
will tell you about the earliest JS version capable of both, and that
you shouldn't ask for browsers, when you mean JS implementations.
With the exception of "JS implementation", for which the better term is
_ECMAScript_ implementation, I would say something like that. As for a
listing of the earliest versions to support either feature, the Matrix[1]
has them. Suffice it to say that every version of JavaScript and JScript,
and every implementation of ECMAScript supports function *declarations*[2];
as for function *expressions*, anonymous or not, it appears they can be
considered safe to use although they are not universally supported.
PointedEars
___________
[1] <http://PointedEars.de/es-matrix>
[2] <http://docs.sun.com/source/816-6408-10/stmt.htm#1004825>
--
Anyone who slaps a 'this page is best viewed with Browser X' label on
a Web page appears to be yearning for the bad old days, before the Web,
when you had very little chance of reading a document written on another
computer, another word processor, or another network. -- Tim Berners-Lee
Jul 5 '08 #7

P: n/a
Thanks to all.

Thomas 'PointedEars' Lahn wrote:
>for which the better term is
_ECMAScript_
I have served on two language standards committees. Neither thought
that we should rename the language after ourselves.
Jul 5 '08 #8

P: n/a
Ma************@gmail.com wrote:
Thomas 'PointedEars' Lahn wrote:
>for which the better term is _ECMAScript_

I have served on two language standards committees. Neither thought
that we should rename the language after ourselves.
You trimmed the following word -- implementation -- which changes the
meaning of the quote. This is not about renaming the language, it is
acknowledging that we are dealing with several languages -- among them
Netscape/Mozilla.org JavaScript and Microsoft JScript -- that are based
on or at least strongly connected to another one -- ECMAScript -- here.
PointedEars
--
Anyone who slaps a 'this page is best viewed with Browser X' label on
a Web page appears to be yearning for the bad old days, before the Web,
when you had very little chance of reading a document written on another
computer, another word processor, or another network. -- Tim Berners-Lee
Jul 5 '08 #9

P: n/a
On Jul 5, 8:55*pm, Lasse Reichstein Nielsen <l...@hotpop.comwrote:
The former is a function declaration. Inside a function body, it is
evaluated before any non-function declaration and before the body
is executed. It must reside at the top level of the function body, and
not, e.g., inside a branch of an "if" statement.

The latter is a variable declaration and an assignment to the variable.
The variable declaration happens just after function declarations have
been performed, and before the body statments are executed.
The assignment only happens when the execution of the body reaches
the point of the assignment.
Funny :
javascript:(function(){var g= "Hola";function g () { ; };alert(g+",
"+typeof g);})();

-"Hola, string"

but :
javascript:(function(){var g;function g () { ; };alert(g+", "+typeof
g);})();

and :
javascript:(function(){var g= "Hola";var g= function () { ; };alert(g
+", "+typeof g);})();

-"function g() { ; }, function"

--Jorge.

Jul 7 '08 #10

P: n/a
Jorge meinte:
On Jul 5, 8:55 pm, Lasse Reichstein Nielsen <l...@hotpop.comwrote:
>The former is a function declaration. Inside a function body, it is
evaluated before any non-function declaration and before the body
is executed. It must reside at the top level of the function body, and
not, e.g., inside a branch of an "if" statement.

The latter is a variable declaration and an assignment to the variable.
The variable declaration happens just after function declarations have
been performed, and before the body statments are executed.
The assignment only happens when the execution of the body reaches
the point of the assignment.

Funny :
Not really.
javascript:(function(){var g= "Hola";function g () { ; };alert(g+",
"+typeof g);})();

-"Hola, string"
As stated: function() { } declarations are evaluated *before* anything
else. Your function g() gets then overwritten by var g.
but :
javascript:(function(){var g;function g () { ; };alert(g+", "+typeof
g);})();

and :
javascript:(function(){var g= "Hola";var g= function () { ; };alert(g
+", "+typeof g);})();

-"function g() { ; }, function"
In this case your var g (the second var can be omitted) just gets a new
value assigned.

See Joost's post.

Gregor

--
http://photo.gregorkofler.at ::: Landschafts- und Reisefotografie
http://web.gregorkofler.com ::: meine JS-Spielwiese
http://www.image2d.com ::: Bildagentur für den alpinen Raum
Jul 7 '08 #11

P: n/a
On Jul 7, 10:51*am, Gregor Kofler <use...@gregorkofler.atwrote:
Jorge meinte:
On Jul 5, 8:55 pm, Lasse Reichstein Nielsen <l...@hotpop.comwrote:
The former is a function declaration. Inside a function body, it is
evaluated before any non-function declaration and before the body
is executed. It must reside at the top level of the function body, and
not, e.g., inside a branch of an "if" statement.
The latter is a variable declaration and an assignment to the variable..
The variable declaration happens just after function declarations have
been performed, and before the body statments are executed.
The assignment only happens when the execution of the body reaches
the point of the assignment.
Funny :

Not really.
javascript:(function(){var g= "Hola";function g () { ; };alert(g+",
"+typeof g);})();
-"Hola, string"

As stated: function() { } declarations are evaluated *before* anything
else. Your function g() gets then overwritten by var g.
but :
javascript:(function(){var g;function g () { ; };alert(g+", "+typeof
g);})();
and :
javascript:(function(){var g= "Hola";var g= function () { ; };alert(g
+", "+typeof g);})();
-"function g() { ; }, function"

In this case your var g (the second var can be omitted) just gets a new
value assigned.

See Joost's post.
Yes I know. But it's a bit weird that in

var g= "Hola";
function g () { ; };

g ends up being a string because you might expect the function g ()
declaration coming after the var declaration+assignment to overwrite
g.

Of course, when there are two assignments in a row as in (I know the
second var can be ommited) :

var g= "Hola";
var g= function () { ; };

the last one is the one that counts.

The lesson here is that declaring g as function g () {...}; isn't
always necessarily (100%) equal to (or interchangeable with) var g=
function () {...}; :

var g= "Hola";
function g () { ; };
alert(g); -"Hola"

var g= "Hola";
var g= function () { ; };
alert(g); -"function () { ; }"

--Jorge.
Jul 7 '08 #12

P: n/a
On Jul 7, 1:51*am, Gregor Kofler <use...@gregorkofler.atwrote:
Jorge meinte:
On Jul 5, 8:55 pm, Lasse Reichstein Nielsen <l...@hotpop.comwrote:
The former is a function declaration. Inside a function body, it is
evaluated before any non-function declaration and before the body
is executed. It must reside at the top level of the function body, and
not, e.g., inside a branch of an "if" statement.
The latter is a variable declaration and an assignment to the variable..
The variable declaration happens just after function declarations have
been performed, and before the body statments are executed.
The assignment only happens when the execution of the body reaches
the point of the assignment.
Funny :

Not really.
To quote the relevant part of the spec:
| 10.1.3 Variable Instantiation
|
| Every execution context has associated with it a variable
object.
| Variables and functions declared in the source text are added as
| properties of the variable object. For function code, parameters
are
| added as properties of the variable object.

http://bclary.com/2004/11/07/#a-10.1.3
javascript:(function(){var g= "Hola";function g () { ; };alert(g+",
"+typeof g);})();
-"Hola, string"

As stated: function() { } declarations are evaluated *before* anything
else. Your function g() gets then overwritten by var g.
Stepwise, g is bound to the Variable object with value undefined.
Then Function g replaces the value that already existed (undefined)
with a function object.

Next pass. g is assinged to the value +"Hola"
an alert call with string value argument.

and :
javascript:(function(){var g= "Hola";var g= function () { ; };alert(g
+", "+typeof g);})();
javascript:(function(){var g= "Hola";var g= function () { ; };alert(g
+", "+typeof g);})();

var g - creates a property on the variable object with name -g - and
value undefined.
var g - ignored.

second pass.
g is assigned the value "Hola".
g is assingned the value of a functionExpression.
an alert statement with string value argument
-"function g() { ; }, function"

In this case your var g (the second var can be omitted) just gets a new
value assigned.
Actually, either - var - statment could be omitted and the interpreted
code would have the same result.
(function(){
g = "Hola";
var g = function () { ; };
alert(g +", "+typeof g);
})();

FunctionDeclarations and Variable declarations are evaluated in the
first pass. They both create a property to the Variable object if no
such property exists.

_Source code_______ _value________________________________________
parameter variable The value passed in the call (undefined if no
value passed)
FunctionDeclaration the Function object
variableDeclaration undefined

As an example:

(function(){
g = "Hola";
function g() { ; };
alert(g +", "+typeof g);
})();

1. skipped first pass
2. a property with identifier - g - and [[value]] - function() { ; } -
added to Variable object
3. skipped first pass.

1. assign g to value "Hola"
2. skipped
3. alert statement
alert(typeof g);
See Joost's post.

Gregor

--http://photo.gregorkofler.at::: Landschafts- und Reisefotografiehttp://web.gregorkofler.com*::: meine JS-Spielwiesehttp://www.image2d.com* ** ::: Bildagentur für den alpinen Raum
Jul 7 '08 #13

P: n/a
On Jul 7, 5:54 pm, dhtml wrote:
On Jul 7, 1:51 am, Gregor Kofler wrote:
<snip>
>>Funny :
>Not really.

To quote the relevant part of the spec:

| 10.1.3 Variable Instantiation
|
| Every execution context has associated with it a variable
object.
| Variables and functions declared in the source text are added as
| properties of the variable object. For function code, parameters
are
| added as properties of the variable object.

http://bclary.com/2004/11/07/#a-10.1.3
>>javascript:(function(){var g= "Hola";function g () { ; };alert(g+",
"+typeof g);})();
>>-"Hola, string"
>As stated: function() { } declarations are evaluated *before*
anything else. Your function g() gets then overwritten by var g.

Stepwise, g is bound to the Variable object with value undefined.
The term 'bound' has no technical meaning in javascript/ECMAScript (at
least until version 4 is finished), and is currently attached to such
a wide range of activity/behaviour that its use tends to obscure. Here
a property is added to the variable object with the name 'g'.

However, at no point would the undefined value be assigned to that
property because function declarations are processed before variable
declarations and so the 'g' property is assigned a reference to a
function object when it is created. The processing of variable
declarations are not permitted to modify properties of the variable
object.
Then Function g replaces the value that already existed
(undefined) with a function object.
<snip>
No undefined value is ever assigned to the 'g' property of the
variable object in the above code.
Jul 7 '08 #14

This discussion thread is closed

Replies have been disabled for this discussion.