From: optimistx on
David Mark wrote:
....
> And don't discount the impact of function calls on performance,
> especially when manipulating the DOM. Their presence (or the lack
> thereof) is often critical to performance.
Would you like to give a couple of examples, which might oftern happen
in real life programming ?
From: Richard Cornford on
kangax wrote:
> Garrett Smith wrote:
<snip>
>> That's odd. Seems in Tracemonkey, a RegExp is callable without
>> implementing [[Call]], or ? A bug in there syntax extension, due
>> to internal typechecking for RegExp, as:
>> typeof /a/
>
> Yes, from what I remember, Mozilla makes regex objects callable
> without actually giving them [[Call]].

That would be very clear violation of ECMA 262, 3rd Ed., where Section
11.2.3 (Function Calls) features the words "If Result(3) does not
implement the internal [[Call]] method , throw a TypeError exception" as
step 5 in its algorithm. That is, in ES3 terms, if it does not have a
[[Call]] method it cannot be called, and so if it can be called it
_must_ have a [[Call]] method (or at least that is the required
behaviour, so the ability to call something has direct implications for
all other situations where the existence of a [[Call]] method is
relevant). The specifics have moved around in ES5, but the internal
IsCallable function still boils down to 'does the object have a [[Call]]
method', so nothing has really changed.

On e of the main things that has dogged the - isFunction - question over
its very long history is that very few people have been willing to state
what 'being a function' represents. If you can give a clear definition
of what 'being a function' is then you are probably in a position to
either design and effective - isFunction - method, or to declare the
determination untestable and so give up the attempt. Instead we see lots
of example of - isFunction - method that do something, get criticised
for the inconsistencies in that something, and then get changed so they
do something else, with nobody ever stating what the definition of
'Function' is that their - isFunction - is supposed to be testing.

Personally, I like a definition of 'function' that goes; "if you can
call it then it is a function". It is a definition that rules out the
viability of an - isFunction - test function (you would have to call the
object to see if it is callable, and that might have side-effects), but
it is also a very simple/obvious definition that does not introduce
issues of itself.

A (one of the many) bugbears of - isFunction - Firefox's response to:-

var x = document.createElement('OBJECT');

- which, when tested with - typeof - returns 'function'. This is seen as
incorrect, e.g.:-

<URL: http://jsninja.com/Functions#Function_Type >

The idea being that - createElement - should return an object
implementing the Element (and by implication Node) interfaces from the
W3C DOM (which is true), and that those object should not be callable
(which is an assertion that has no technical basis[1]), and therefore
that the - typeof - operation applied to such an object should not
result in 'function'.

[1] The W3C DOM is defined in terms of interfaces; sets of properties
and methods that object implementing those interfaces must possess (in
some practical sense). Neither ECMAScript, the W3C DOM specs nor the
ECMAScript bindings for the DOM interfaces place any restrictions on the
nature of the objects implementing an interface, and as ECMAScript
functions are objects there is absolutely no reason for any object
implementing a W3C DOM interface not to be an ECMAScript function. Thus
Element and Node interface implementing objects could be functions (as
could objects implementing HTMLCollection, NodeList or NamedNodeMap),
the decision is left up to the creators of the DOM providing host.

If you try to call the Firefox OBJECT element an exception is thrown,
but it is not the "x is not a function" exception that would be thrown
if the OBJECT element were not callable. The implication being that the
element is callable and the exception that is thrown is thrown within
the call. So, by a very reasonable definition of 'being a function' the
Firefox OBJECT element is a function (it can be called), and so its
resulting in 'function' when - typeof - is applied is actually a very
reasonable indicator of a truth about the nature of the object in
question.

The point being that there is no technical reason to expect to be able
to discriminate between objects implementing the Element interface (or
any other DOM specified interface) and an ECMAScript function. This
immediately brings into question the worth of having an - isFunction -
test function in the first place, especially in relation to its common
use in attempting to emulate 'method overloading' in ECMAScript. (In
fact, it brings into question the general viability of emulating 'method
overloading' in javascript, when you can only make superficial
discriminations between the types of values that are the arguments to a
function call).

The relevance for a regular expression's having, or not having, a
[[Call] method? If you cannot expect to be able to discriminate a DOM
node from a function not finding it easy to discrimination a regular
expression from a function (using - typeof - (as the specific
discrimination by duck-typing the respective object's methods/properties
is viable)) is not making things any worse.

> In WebKit, on the other hand, regex do have [[Call]] and so typeof
> returns "function", as per specs (native object + has [[Call]] ==
> "function").
<snip>
>> Many won't read the documentation of others (including pertinent
>> specifications, as witnessed recently on this NG). Developers
>> often skip right to the "what does it do" (functions, examples,
>> or tests).

I recall one of my colleagues being amused to find me reading the
SOAP/WSDL specifications prior to writing a SOAP client for our web
applications.

> It's no surprise that ES3 specs are hard to follow and full of
> ambiguities. A year ago, the only way I could understand certain
> things in specs is with the help of wonderful explanations by
> Cornford and Lasse in the archives (on related subjects).

An interesting mix of formality and informality in your choice of
identifiers there. :)

> Your last question on es-discuss proves how hard it could be to
> discern specs correctly.
>
> ES5, fortunately, takes care of some of these uncertainties.
<snip>

The ES5 spec may remove some ambiguities, but it is not going to prove
any easier for newcomers to 'get into', at least in part becasue it
introduces many new internal objects/functions that will not ease the
need to continually be going back and forth cross-refencing things.

Richard.

From: Peter Michaux on
On Nov 9, 5:02 pm, Thomas 'PointedEars' Lahn <PointedE...(a)web.de>
wrote:
> Peter Michaux wrote:
> > On Nov 9, 2:41 pm, Asen Bozhilov <asen.bozhi...(a)gmail.com> wrote:
> >> | 7.6 Identifiers
> >> | This standard specifies one departure from the grammar given in the
> >> Unicode standard: The dollar sign ($) and the
> >> | underscore (_) are permitted anywhere in an identifier. The dollar
> >> sign is intended for use only in mechanically
> >> | generated code.



> > I believe this statement is gone from the proposed ECMAScript 5 and if so
> > I think it is good they removed it.
>
> Well, I for one do not want to see code like the following spreading around:
>
> <?php
> $bar = 'baz';
> $foo = 'bar';
> echo <<<JS
> \$foo.\$ = '{$$foo}';
> JS;
> ?>
>
> Do you?

No. I think that I would not have allowed '$' to be part of identifier
in the first place.

Peter
From: Thomas 'PointedEars' Lahn on
Peter Michaux wrote:

> Thomas 'PointedEars' Lahn wrote:
>> Peter Michaux wrote:
>> > On Nov 9, 2:41 pm, Asen Bozhilov <asen.bozhi...(a)gmail.com> wrote:
>> >> | 7.6 Identifiers
>> >> | This standard specifies one departure from the grammar given in the
>> >> | Unicode standard: The dollar sign ($) and the underscore (_) are
>> >> | permitted anywhere in an identifier. The dollar sign is intended for
>> >> | use only in mechanically generated code.
>> >
>> > I believe this statement is gone from the proposed ECMAScript 5 and if
>> > so I think it is good they removed it.
>>
>> Well, I for one do not want to see code like the following spreading
>> around:
>>
>> <?php
>> $bar = 'baz';
>> $foo = 'bar';
>> echo <<<JS
>> \$foo.\$ = '{$$foo}';
>> JS;
>> ?>
>>
>> Do you?
>
> No. I think that I would not have allowed '$' to be part of identifier
> in the first place.

Then I do not understand your opinion above. A recommendation against,
as it is in Edition 3, is a step in the right direction in that sense;
a missing recommendation against, as it could be in Edition 5, is not.


PointedEars
--
realism: HTML 4.01 Strict
evangelism: XHTML 1.0 Strict
madness: XHTML 1.1 as application/xhtml+xml
-- Bjoern Hoehrmann
From: David Mark on
On Nov 11, 5:23 am, "optimistx" <optimi...(a)hotmail.com> wrote:
> David Mark wrote:
>
> ...> And don't discount the impact of function calls on performance,
> > especially when manipulating the DOM.  Their presence (or the lack
> > thereof) is often critical to performance.
>
> Would you like to give a couple of examples, which might oftern happen
> in real life programming  ?

Just manipulate the DOM in a loop with and without function calls.
And understand that the browser waits until an execution context is
exited before re-rendering the document. As documents get larger and
more complex, the problem becomes more apparent.