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

Functions

P: n/a
My head's in a spinning cycle.

I think I understand the basics of function(), but somehow that just doesn't
seem enough.

function myFunction(){
return 1
} // some function named myFunction that returns the value 1
var Test1 = myFunction(); // calls the function and assigns the returned value to Test1

var Test2 = myFunction; // assigns a reference of myFunction() to Test2
var Test3 = Test2(); // runs myFunction() - referenced - and assigns the returned value to Test3

ok, I think so far I understand this bit.

Where my head is in a spin is here:

let me assume the following:
someobject.onevent
I have an object someobject, which has an onevent trigger.

where are the differences in the following:
(I know there are in some, but I just can't grasp it)

someobject.onevent = "alert('event fired')";

someobject.onevent = function(){ alert("event fired") };
^
not even sure if this is needed

function myAlert() {
alert("event fired")
}

someobject.onevent = "myAlert();";
someobject.onevent = myAlert();

also with function references:
someobject.onevent = "myAlert";
someobject.onevent = myAlert;

Would somebody please point me in the right direction,
or kindly explain the differences because my mind is really blocked on this.
Thank you
Oct 1 '05 #1
Share this Question
Share on Google+
4 Replies


P: n/a

Robi wrote:
My head's in a spinning cycle.

I think I understand the basics of function(), but somehow that just doesn't
seem enough.

function myFunction(){
return 1
} // some function named myFunction that returns the value 1
var Test1 = myFunction(); // calls the function and assigns the returned value to Test1

var Test2 = myFunction; // assigns a reference of myFunction() to Test2
var Test3 = Test2(); // runs myFunction() - referenced - and assigns the returned value to Test3

ok, I think so far I understand this bit.

Where my head is in a spin is here:

let me assume the following:
someobject.onevent
I have an object someobject, which has an onevent trigger.

where are the differences in the following:
(I know there are in some, but I just can't grasp it)

someobject.onevent = "alert('event fired')";
You are assigning the string "alert('event fired')" to the event, which
will be of no use.
someobject.onevent = function(){ alert("event fired") };
^
not even sure if this is needed
You are assigning a function to be called upon said event. And when
this function is called, it will do an alert. Having a semi-colong at
the end of a statement is a good practice.

function myAlert() {
alert("event fired")
}

someobject.onevent = "myAlert();";
You are assigning a string to the event.
someobject.onevent = myAlert();
You are assigning the return value of the function to the event.
also with function references:
someobject.onevent = "myAlert";
Again, you are assigning a string to the event.
someobject.onevent = myAlert;
You are assigning the function reference to the event. And when the
event is triggered, the function reference will be called.
Would somebody please point me in the right direction,
or kindly explain the differences because my mind is really blocked on this.
Thank you


Oct 1 '05 #2

P: n/a
Robi wrote:
<snip>
where are the differences in the following:
(I know there are in some, but I just can't grasp it)

someobject.onevent = "alert('event fired')";
Assuming - someobject - is a DOM Element and - onevent - an intrinsic
event handling property supported by that Element (rather than this
being about author implemented event handling mechanisms on custom JS
objects), then assigning a string primitive to the value of an intrinsic
event property is relying upon the browser providing an internal
"setter" for the property that will take the string and create a
corresponding function from it. A very few browsers will do this but
most won't, so it is best to forget about the idea of assigning strings
to intrinsic event priorities.

Assigning such strings is a running error in cross-browser scripting
(made worse by the browsers that do transform such strings into
functions) and follows from the way that such assignments appear to
parallel event handler assignment through HTML attributes. So given:-

<input type="button" value="XX" onclick="alert('button clicked');">

- the fact that the equivalent assignment to the value of the - value -
property is:-

buttonRef.value = 'XX';

- suggests that:-

buttonRef.onclick = "alert("button clicked');";

- would be correct for reasons of constancy. This is not the case, nor
necessarily consistent as assigning:-

buttonRef.type = 'button';

- is only successful following the initial creation of an INPUT Element
with the - document.createElement - method. Element properties that
correspond with HTML attributes are simply not string values equivalent
to the values found in the HTML.

When the above HTML onclick attribute is processed by the browser the
string value of the attribute is used as the function body for a
function that the browser creates internally and assigns to the
corresponding - onclick - property of the DOM element. Simplified, the
browser responds to encountering the attribute by doing the equivalent
of (internally):-

buttonRef.onclick = function(event){
altert('button clicked');
};

- or:-

buttionRef.onclick = new Function('event', 'alert(\'button
clicked\');');

(Details of the - event - parameter of that function, and any scope
chain augmentation, vary between browsers.)

Because the transformation of the attribute value into a function object
is not obvious it is not uncommon for script authors to not appreciate
that it is happening at all.
someobject.onevent = function(){ alert("event fired") };
^
not even sure if this is needed
The totality of this line of code is an ExpressionStatement (ECMA 262,
3rd Edition; Section 12.4). An ExpressionStatement is made up of an
Expression (ECMA 262, 3rd Edition; Section 11.14) followed by a
semicolon (usually optional because of "automatic semicolon insertion"
(ECMA 262, 3rd Edition; Section 7.9) but generally recommended anyway).
In this ExpressionStatement the Expression is an AssignmentExpression
(ECMA 262, 3rd Edition; Section 11.13), consisting of a
LeftHandSideExpression (ECMA 262, 3rd Edition; Section 11.2) (the
MemberExpression (ECMA 262, 3rd Edition; Section 11.2) -
someobject.onevent -), an assignment operator (- = - ) and an
AssignmentExpression (in this case the FunctionExpression (ECMA 262, 3rd
Edition; Section 13) - function(){alert("event fired")} -).

As the right hand side of the AssignmentExpression is a
FunctionExpression the evaluation of the AssignmentExpression involves
the evaluation of the FunctionExpression, for which a new (anonymous)
function object is created and a reference to that function object is
the result of the evaluation of the FunctionExpression. It is this
function reference that is assigned to the value of -
someobject.onevent -.

Incidentally, the body of the FunctionExpression is - alert("event
fired") -, also an ExpressionStatement that should itself be semicolon
terminated (that is, automatic semicolon insertion will render it
semicolon terminated, but good practice suggests that the author should
do that explicitly instead of allowing the interpreter to infer the
semicolon).
function myAlert() {
alert("event fired")
}

someobject.onevent = "myAlert();";
This is the assignment of another string primitive, and should never be
used as string primitives are not executable.
someobject.onevent = myAlert();
The right hand side of this AssignmentExpression is a CallExpression
(ECMA 262, 3rd Edition; Section 11.2.3). The evaluation of the
CallExpression involves resolving the MemberExpression - myAlert - into
a reference to a function object and then calling/executing it (passing
any arguments found in the ArgumentList (ECMA 262, 3rd Edition; Section
11.2.4) between the parenthesise). The result of the CallExpression is
the value returned from the call to the function object, and it is that
value that will be assigned to - someobject.onevent -. That value will
be the - Undefined - value (ECMA 262, 3rd Edition; Section 4.3.9) in the
case of - myAlert -.
also with function references:
someobject.onevent = "myAlert";
That is another string primitive, and even if the browser does use this
string to create a corresponding function object the body of that
function will be a single ExpressionStatement where the Expression is a
PrimaryExpression (ECMA 262, 3rd Edition; Section 11.1) consisting of an
Identifier (ECMA 262, 3rd Edition; Section 7.6). The evaluation of such
an expression is useless (will do nothing), so any resulting function
object will do nothing.
someobject.onevent = myAlert;
The Identifier - myAlert - evaluates to a reference to a function object
and so it is the reference to that function object that is assigned to
the value of the object property. This is similar in effect to
evaluating a FunctionExpression and assigning the result of that
Expression, except that the function object referred to by - myAlert -
is not (necessarily) an inner function so closures may not come into
play in this case.
Would somebody please point me in the right direction,
ECMA 262, 3rd Edition.
or kindly explain the differences because my mind is really
blocked on this.


Apart form the use of string primitive values (which you can dismiss
entirely), you may need to better describe the area of your confusion.

Richard.
Oct 1 '05 #3

P: n/a
Richard Cornford wrote in message news:dh*******************@news.demon.co.uk...
Robi wrote:
<snip>
where are the differences in the following:
(I know there are in some, but I just can't grasp it) [...] Would somebody please point me in the right direction,


ECMA 262, 3rd Edition.
or kindly explain the differences because my mind is really
blocked on this.


Apart form the use of string primitive values (which you can dismiss
entirely), you may need to better describe the area of your confusion.


Richard, I thank you very much for the detailed explanation
and description on the different "statements" I listed.

I have read through it twice already, trying to get my mind
take in the definitions and nuances and getting to understand
the function assignments and to differentiate between
"intrinsic" primitives and official(?) assignments.

Again, thanks a bunch.
Oct 2 '05 #4

P: n/a
Robi wrote:
Richard Cornford wrote:
Robi wrote:
Would somebody please point me in the right direction,
ECMA 262, 3rd Edition.

<snip> I have read through it twice already, trying to get my mind
take in the definitions and nuances and getting to understand
the function assignments and to differentiate between
"intrinsic" primitives and official(?) assignments.


"Intrinsic", as in 'intrinsic event', is a term form the HTML
specification and is used to distinguish event handlers originating with
HTML attributes and the corresponding set of DOM Element properties
(probably along with event handlers such as - window.onresize - that
pre-date DOM specifications) from other event handler attaching
mechanisms such as the W3C DOM Events specified - addEventListener -
method and the Microsoft proprietary - attachEvent - method.

"Primitives" are types of value that are represented directly at the
lowest level of the language implementation. Specifically; Undefined,
Null, Boolean, Number and String. As opposed to the Object type, which
is not primitive. Functions are Objects in ECMAScript.

And I did not mention "official" at all.

None of these terms apply to assignment as such. The value being
assigned (the right hand side) may be a primitive value or not, and the
property to which the value is assigned (the left hand side) may be an
'intrinsic event' property or not. The assignment itself is never more,
less or other than an assignment.

Richard.
Oct 2 '05 #5

This discussion thread is closed

Replies have been disabled for this discussion.