Call a function syntax

Discussion in 'Javascript' started by chirs, Oct 27, 2003.

  1. chirs

    chirs Guest

    I am trying to understand a piece of code. In a javascrpit file,
    there is a function:

    function ItemStyle(){
    var names=['len','spacing','popInd','popPos','pad','outCol','overCol','outClass','overClass','outBorder','overBorder','outAlpha','overAlpha','normCursor','nullCursor'];
    addProps(this,arguments,names,true);
    };

    In the html file, it calls the function as:

    var hBar = new ItemStyle(40, 10, '', 0, 0, '10#336699', '10#6699CC',
    'highText', 'highText', '', '',
    null, null, 'hand', 'default');

    How can it pass the 15 arguments to the function when the function
    does not have parameters?
    chirs, Oct 27, 2003
    #1
    1. Advertising

  2. chirs

    Lee Guest

    chirs said:
    >
    >I am trying to understand a piece of code. In a javascrpit file,
    >there is a function:
    >
    >function ItemStyle(){
    >var
    >names=['len','spacing','popInd','popPos','pad','outCol','overCol','outClass','overClass','outBorder','overBorder','outAlpha','overAlpha','normCursor','nullCursor'];
    >addProps(this,arguments,names,true);
    >};
    >
    >In the html file, it calls the function as:
    >
    >var hBar = new ItemStyle(40, 10, '', 0, 0, '10#336699', '10#6699CC',
    >'highText', 'highText', '', '',
    > null, null, 'hand', 'default');
    >
    >How can it pass the 15 arguments to the function when the function
    >does not have parameters?


    The "arguments" attribute of the function (seen as a local variable
    within the function) is the array of arguments passed to it.
    Lee, Oct 27, 2003
    #2
    1. Advertising

  3. chirs

    Graham J Guest

    > How can it pass the 15 arguments to the function when the function
    > does not have parameters?


    You don't have to formally declare the arguments of JavaScript
    functions if you don't want to. They are passed in the 'arguments'
    array.
    Graham J, Oct 27, 2003
    #3
  4. Graham J wrote:

    >> How can it pass the 15 arguments to the function when the function
    >> does not have parameters?

    >
    > You don't have to formally declare the arguments of JavaScript
    > functions if you don't want to. They are passed in the 'arguments'
    > array.


    Although it is described in the Core Reference as such and you can
    access its properties like the elements of an array (using the index
    operator), I would not call it an array, since it is lacking features
    of the Array prototype, like the join(...) method, and would call it
    a collection instead.


    PointedEars
    Thomas 'PointedEars' Lahn, Nov 23, 2003
    #4
  5. > >> How can it pass the 15 arguments to the function when the function
    > >> does not have parameters?

    > >
    > > You don't have to formally declare the arguments of JavaScript
    > > functions if you don't want to. They are passed in the 'arguments'
    > > array.

    >
    > Although it is described in the Core Reference as such and you can
    > access its properties like the elements of an array (using the index
    > operator), I would not call it an array, since it is lacking features
    > of the Array prototype, like the join(...) method, and would call it
    > a collection instead.


    Strictly speaking, this is correct. The nature of the arguments object was a
    Netscape error that Microsoft copied and put into the ECMAScript standard. There
    are many errors in the standard. ECMA is a substandard standards organization.

    The arguments object has a length member, but in all other respects it is just
    an object. I use

    var a = Array.prototype.slice.apply(arguments);

    to turn it into a genuine array.

    http://www.crockford.com/javascript/remedial.html
    Douglas Crockford, Nov 23, 2003
    #5
  6. In article <2eb1b$3fc0f762$44a4afcc$>,
    Douglas Crockford <> writes
    <snip>
    >ECMA is a substandard standards organization.

    <snip>

    ECMA is a European Computer Manufacturers Association, not a standards
    organisation. It's produced a lot of standards, some of them very
    useful, but they don't all have to be good for people who aren't large
    computer companies.

    John
    --
    John Harris
    John G Harris, Nov 23, 2003
    #6
  7. Douglas Crockford wrote:

    Who wrote this? Please include an attribution line.
    vvvvvvvvvvvvvvv
    >> >> How can it pass the 15 arguments to the function when the function
    >> >> does not have parameters?
    >> >
    >> > You don't have to formally declare the arguments of JavaScript
    >> > functions if you don't want to. They are passed in the 'arguments'
    >> > array.

    >>
    >> Although it is described in the Core Reference as such and you can
    >> access its properties like the elements of an array (using the index
    >> operator), I would not call it an array, since it is lacking features
    >> of the Array prototype, like the join(...) method, and would call it
    >> a collection instead.

    >
    > Strictly speaking, this is correct. The nature of the arguments object was a
    > Netscape error that Microsoft copied and put into the ECMAScript standard.


    An `arguments array' is not specified in ECMAScript 3, but
    the `arguments object' is (in sections 10.1.6 and 10.1.8.)

    > There are many errors in the standard.


    Such as? I was writing about Netscape's Core JavaScript 1.5
    Reference at DevEdge, not ECMAScript (Ed. 3).

    > ECMA is a substandard standards organization.


    Hm?

    "Ecma International is an industry association founded in 1961,
    dedicated to the standardization of information and communication
    systems." (http://ecma-international.org/)


    PointedEars
    Thomas 'PointedEars' Lahn, Nov 23, 2003
    #7
  8. > >> Although it is described in the Core Reference as such and you can
    > >> access its properties like the elements of an array (using the index
    > >> operator), I would not call it an array, since it is lacking features
    > >> of the Array prototype, like the join(...) method, and would call it
    > >> a collection instead.

    > >
    > > Strictly speaking, this is correct. The nature of the arguments object was a
    > > Netscape error that Microsoft copied and put into the ECMAScript standard.

    >
    > An `arguments array' is not specified in ECMAScript 3, but
    > the `arguments object' is (in sections 10.1.6 and 10.1.8.)
    >
    > > There are many errors in the standard.

    >
    > Such as? I was writing about Netscape's Core JavaScript 1.5
    > Reference at DevEdge, not ECMAScript (Ed. 3).


    Errors in the language design: The arguments array is not an array. Reserved
    words cannot be used as names in the object literal notation. Reserved words
    cannot be used in dot notation. '+' does type coersion to string in some cases.
    typeof null == 'object'. Excess function parameters are ignored. 'this' is set
    to the global object when calling inner functions. A leading '0' may or may not
    be interpreted as octal. 'undefined' can be redefined. The 'width' statement can
    sometimes clobber members of the global object.

    The Specification itself suffers from being at the wrong level of detail. It is
    at once too vague and too implementation specific. Worst of all, it is very
    difficult to read and understand.

    > > ECMA is a substandard standards organization.

    >
    > Hm?
    >
    > "Ecma International is an industry association founded in 1961,
    > dedicated to the standardization of information and communication
    > systems." (http://ecma-international.org/)


    ECMA issued the ECMAScript Language Specification, which is a poorly written
    specification which requires complying implementation to intentionally repeat
    the mistakes from the first implementations. Generally, real standard bodies
    have attempted where possible to correct or at least deprecate past mistakes.

    Netscape chose ECMA because they thought that, being a light-weight
    organization, they would be easy to push around. Netscape should not have been
    seeking a standard at that point in time because the language was too immature.
    ECMA wanted the business, so a substandard standard was produced.

    On balance, ECMAScript works much better as a standard than web browsers. W3C
    makes ECMA look like a Class Act, but that's another story.

    http://www.crockford.com/javascript/javascript.html
    Douglas Crockford, Nov 23, 2003
    #8
  9. "Douglas Crockford" <> writes:

    > Errors in the language design: The arguments array is not an
    > array.


    Are we sure we want it to be?

    If you had the function
    function foo(b,c) {
    arguments.length = b;
    alert(c);
    }
    and you call it as
    foo(1,"bar");
    what should happen?

    If "arguments" is an array, then "c" should become undefined. If not,
    it is still "bar".

    I would prefer the arguments object to be just an object, and the
    length property to be read only.

    > Reserved words cannot be used as names in the object literal
    > notation. Reserved words cannot be used in dot notation.


    That's a matter of taste. I prefer keywords to be restricted. It makes
    programs easier to read if "if" means the same everywhere.
    They should drop all the reserved words that are not keywords, though.

    > '+' does type coersion to string in some cases. typeof null ==
    > 'object'.


    A Java-ism, definitly. I would drop "null" completely. We don't need
    both undefined and null.

    > Excess function parameters are ignored.


    I like that (and I'm not sure whether you mean that you can send too
    few or too many arguments to a function). I definitly don't think
    it's an error.

    > 'this' is set to the global object when calling inner functions.


    Bad desing. Agree completely! Highly annoying.

    > A leading '0' may or may not be interpreted as octal. 'undefined'
    > can be redefined.


    So can Infinity and NaN. They should all be keywords like "true and
    "false"

    > The 'width' statement can sometimes clobber members of the global
    > object.


    "with" :).
    I wouldn't know, I never use it :)

    > The Specification itself suffers from being at the wrong level of
    > detail. It is at once too vague and too implementation
    > specific. Worst of all, it is very difficult to read and understand.


    Hear, hear!

    /L
    --
    Lasse Reichstein Nielsen -
    DHTML Death Colors: <URL:http://www.infimum.dk/HTML/rasterTriangleDOM.html>
    'Faith without judgement merely degrades the spirit divine.'
    Lasse Reichstein Nielsen, Nov 24, 2003
    #9
  10. Douglas Crockford wrote:
    ^^^^^^^^^^^^^^^^^^^^^^^^^
    Attribution line, please!
    vvvvvvvvvvvvvvvvvvvvvvvvv
    >> >> Although it is described in the Core Reference as such and you can
    >> >> access its properties like the elements of an array (using the index
    >> >> operator), I would not call it an array, since it is lacking features
    >> >> of the Array prototype, like the join(...) method, and would call it
    >> >> a collection instead.
    >> >
    >> > Strictly speaking, this is correct. The nature of the arguments object was a
    >> > Netscape error that Microsoft copied and put into the ECMAScript standard.

    >>
    >> An `arguments array' is not specified in ECMAScript 3, but
    >> the `arguments object' is (in sections 10.1.6 and 10.1.8.)
    >>
    >> > There are many errors in the standard.

    >>
    >> Such as? I was writing about Netscape's Core JavaScript 1.5
    >> Reference at DevEdge, not ECMAScript (Ed. 3).

    >
    > Errors in the language design: The arguments array is not an array.


    What part of

    | An `arguments array' is not specified in ECMAScript 3, but
    | the `arguments object' is (in sections 10.1.6 and 10.1.8.)

    do I need to spell for you? ECMAScript is the standard when
    it comes to JavaScript, and nothing else.

    > Reserved words cannot be used as names in the object literal notation.
    > Reserved words cannot be used in dot notation.


    That is why they are called `_reserved_ words'!

    > '+' does type coersion to string in some cases.


    That is a feature, not an error in language design. It is, however, an
    error in your code based on a false assumption. JavaScript 1.x is a
    *weak* typed language by design, and `+' is the concatenation operator
    for string values. If you watch the operator precedence and type of
    operands, with a working ECMAScript implementation you will get no
    unexpected behavior.

    > typeof null == 'object'.


    | 4.3.11 Null Value
    |
    | The null value is a primitive value that represents
    | the null, empty, or non-existent reference.

    Since a reference points to an object, what other
    type would you choose for `null' than `object'?

    > Excess function parameters are ignored.


    -v

    > 'this' is set to the global object when calling inner functions.


    What are `inner functions'?

    That `this' points to the top-level object in functions that are not
    called with the lookup operator is a feature, not a bug. Only what I
    find disturbing is that there is no way to refer to the global object
    directly, independent of the context.

    > A leading '0' may or may not be interpreted as octal.


    But not by chance. There are rules that define
    when it is interpreted as octal and when not.

    > 'undefined' can be redefined.


    And?

    > The 'width' statement can sometimes clobber members of the global object.


    There is no `width' statement. You probably mean the `with' statement
    which is considered bad practice in several languages (Zend developers
    even refuse to implement it because of the ambiguity that would evolve
    then in PHP code). Besides, there are errors in implementations of
    ECMAScript, especially in IE's JScript.

    > The Specification itself suffers from being at the wrong level of detail.
    > It is at once too vague and too implementation specific.


    That is merely a statement, where is the proof?

    I fail to find implementation-specific parts in ECMAScript and since
    ECMAScript is a language to be implemented, the specification is
    required to be this way.

    > Worst of all, it is very difficult to read and understand.


    A specification of a programming language is a work of science
    for implementors, it is not designed to be easily readable and
    understandable for the average programmer. There are the
    JavaScript Guide, Reference, MSDN and other documentation
    available to serve that purpose. Perhaps you should stick to
    that if ECMAScript is to complicated for you.

    >> > ECMA is a substandard standards organization.

    >>
    >> Hm?
    >>
    >> "Ecma International is an industry association founded in 1961,
    >> dedicated to the standardization of information and communication
    >> systems." (http://ecma-international.org/)

    >
    > ECMA issued the ECMAScript Language Specification, which is a poorly written
    > specification which requires complying implementation to intentionally repeat
    > the mistakes from the first implementations. Generally, real standard bodies
    > have attempted where possible to correct or at least deprecate past mistakes.


    How the heck did you get that idea? Netscape invented the JavaScript
    language and used its Associate Membership(!) in ECMA to standardize
    most of JavaScript user agent independent features as ECMAScript.
    However, Netscape continued (and is still continuing) to develop
    JavaScript. After M$ finally found out that there is a Web out there,
    they took elements from ECMAScript and the current JavaScript version
    of these days mixed with own extensions and created JScript. In fact,
    Netscape is revising JavaScript versions which later become ECMAScript
    specifications for the most part. ECMAScript 3, where some features of
    previous versions are in fact deprecated, is based upon JavaScript as
    supported in Mozilla/5.0 or you can say JavaScript 1.5 as supported in
    Mozilla/5.0 is an implementation of ECMAScript 3. JavaScript 2.0 will
    be standardized as ECMAScript 4, the proposal is already underway.

    And, please forgive my ignorance, what do you mean by "real standard
    bodies"?

    > Netscape chose ECMA because they thought that, being a light-weight
    > organization, they would be easy to push around. Netscape should not have been
    > seeking a standard at that point in time because the language was too immature.
    > ECMA wanted the business, so a substandard standard was produced.


    Sounds like M$ propaganda.

    > http://www.crockford.com/javascript/javascript.html


    I have never read such a load of FUD crap.


    PointedEars
    Thomas 'PointedEars' Lahn, Nov 24, 2003
    #10
  11. Albert Wagner wrote:

    > Thomas 'PointedEars' Lahn <> wrote:
    >> > http://www.crockford.com/javascript/javascript.html

    >>
    >> I have never read such a load of FUD crap.

    >
    > [...] Just exactly what on that site do you consider FUD?


    Take the ECMA stuff for example:

    | JavaScript, aka Mocha, aka LiveScript, aka JScript, aka ECMAScript,
    | is one of the world's most popular programming languages.

    JavaScript is _not_ ECMAScript, it is and has always been,
    Netscape(/AOLTW)'s implementation of the latter.[1] JScript
    is *neither* JavaScript *nor* ECMAScript, it is *Microsoft's*
    implementation of ECMAScript, as one could have also read in
    the FAQ of this NG.[2]

    AFAIS, Mocha is a Java decompiler[3] and such has nothing to
    do with ECMAScript, JavaScript or other implementations of the
    former at all.

    | The ECMA committee that has stewardship over the language is developing
    | extensions which, while well intentioned, will aggravate one of the
    | language's biggest problems: There are already too many versions.
    | This creates confusion.

    ECMA does neither watch over JavaScript nor does it develop extensions
    for it. ECMA International, as an "industry association [...] dedicated
    to the standardization of information and communication systems[...]"[4]
    where also Netscape/AOLTW and Microsoft are members of[5], watches over
    ECMAScript. There are exactly 3 versions/editions of ECMAScript or
    ECMA-262 right now: ECMAScript (Ed. 1), ECMAScript (Ed.) 2 and
    ECMAScript 3, while only the first and the third are widely
    implemented[6] (and only the third being available for download now[7]).
    There are six JavaScript versions until now: JavaScript 1.0, JavaScript
    1.1, JavaScript 1.2, JavaScript 1.3, JavaScript 1.4 and JavaScript 1.5.
    Of those, versions other than 1.4 are implemented in Netscape browsers
    (1.4 being implemented along with other versions as server-side
    JavaScript in versions of the Netscape Enterprise Server; 1.5 in all
    Mozilla/5.0 based browsers incl. Netscape 6+) and versions other than
    1.2 are fully compatible with ECMAScript.[1] JavaScript 2.0 as
    developed by Waldemar Horwat at Netscape/AOLTW is likely to become an
    implementation of ECMAScript 4, currently implemented in Epimetheus only.[8]

    Other implementations of ECMAScript include different versions of
    Microsoft JScript, supported in M$ Internet Explorer and UAs that
    use the IE browser component.[9]

    | The design of the language on the whole is quite sound. Surprisingly,
    | the ECMAScript committee does not appear to be interested in
    | correcting these problems. Perhaps they are more interested in making
    | new ones.

    Quite sound to whom? What a problem must the author have with "evil"
    ECMA not following his misguided attempts to tell us that

    | JavaScript's C-like syntax, including curly braces and the clunky for
    | statement, makes it appear to be an ordinary procedural language. This
    | is misleading because JavaScript has more in common with functional
    | languages like Lisp or Scheme than with C or Java.

    Because it allows for closures, currying and anonymous functions? OMG.
    Obviously the author has never found (or did not wanted to find?) time
    to read the ECMAScript specification thoroughly (see below.)

    | The official specification for the language is published by ECMA.

    Wrong. The official specification for _ECMAScript_ is published by
    ECMA. The official specification for JavaScript, if you can call the
    Client-Side/Server-Side/Core JavaScript Guide and Reference this, is
    published and has always been published by Netscape(/AOLTW) as *they*
    are to implement ECMAScript as JavaScript.

    | The specification is of extremely poor quality. It is difficult to
    | read, and very difficult to understand.

    Because the author is unable to read technical specifications, they must
    be "of extremely poor quality." Well, there are at least two people (I
    assume of one that he does because of his statements in this newsgroup)
    that find it very well put and of good quality as recent research on
    grammar productions has (again) proven.[10]

    | This has been a contributor to the Bad Book problem because authors
    | have been unable to use the standard document to improve their own
    | understanding of the language.

    As said before[11], technical specifications of programming languages to
    be implemented are never meant to be understood easily by the average
    programmer. They provide rules which implementors should obey if they
    want to call their implementation conforming to one of the described
    programming language.[12]

    | ECMA and the TC39 committee should be deeply embarrassed.

    Again an attempt of FUD only because the author lacks understanding
    of the purpose of the specification and ECMAScript in general.


    PointedEars
    ___________
    [1]
    http://devedge.netscape.com/library/manuals/2000/javascript/1.5/guide/intro.html#1013654
    http://jibbering.com/faq/#FAQ2_6
    [2] http://jibbering.com/faq/#FAQ2_7
    [3] http://google.com/search?q=Mocha&filter=0
    [4] http://www.ecma-international.org/
    [5] http://www.ecma-international.org/memento/associat.htm
    http://www.ecma-international.org/memento/ordinary.htm
    [6]
    http://devedge.netscape.com/library/manuals/2000/javascript/1.5/guide/preface.html#1003515
    [7] http://www.ecma-international.org/publications/standards/Ecma-262.htm
    [8] http://mozilla.org/js/language/
    [9]
    http://msdn.microsoft.com/library/default.asp?url=/library/en-us/script56/html/js56jsoriJScript.asp
    [10] <news:bpj08v$1pmhf0$-berlin.de>
    [11] <news:>
    [12] ECMAScript Ed. 3, Page 1:

    | 1 Scope
    |
    | This Standard defines the ECMAScript scripting language.
    |
    |
    | 2 Conformance
    |
    | A conforming implementation of ECMAScript must provide [...]
    |
    | A conforming implementation of this International standard shall
    | interpret [...]
    |
    | A conforming implementation of ECMAScript is permitted to provide
    | [...]
    |
    | A conforming implementation of ECMAScript is permitted to support
    | [...]
    |
    |
    | 3 Normative References
    | [...]
    Thomas 'PointedEars' Lahn, Nov 24, 2003
    #11
  12. Thomas 'PointedEars' Lahn <> writes:

    > Take the ECMA stuff for example:
    >
    > | JavaScript, aka Mocha, aka LiveScript, aka JScript, aka ECMAScript,
    > | is one of the world's most popular programming languages.
    >
    > JavaScript is _not_ ECMAScript, it is and has always been,
    > Netscape(/AOLTW)'s implementation of the latter.[1] JScript
    > is *neither* JavaScript *nor* ECMAScript, it is *Microsoft's*
    > implementation of ECMAScript, as one could have also read in
    > the FAQ of this NG.[2]


    You are looking at his survey page. It is not intended as exact informatio

    >
    > AFAIS, Mocha is a Java decompiler[3] and such has nothing to
    > do with ECMAScript, JavaScript or other implementations of the
    > former at all.


    .... and you are wrong:
    <URL:http://www.mozilla.org/classic/libmdesc.html>
    These are equivalent when written in the address bar of Netscape 4:
    mocha:alert("X");
    javascript:alert("X");
    livescript:alert("X");

    So, Javascript aka. Livescript aka. Mocha is correct.

    When you write
    <script type="text/javascript">
    IE interprets the content using its JScript interpreter.
    It is fair to say that JScript is also known as Javascript,
    so Javascript aka. JScript is correct.

    What is the language implemented by Opera?
    They call it Javascript. It differs from Netscape's Javascript.
    It implements ECMAScript v3 + extensions.
    What is it?

    The word "Javascript" long ago stopped only referring to Netscape's
    brand of ECMAScript. It is now, like Kleenex, a common word used about
    similar products from other compagnies.

    The one you can split hairs about is ECMAScript. There is no language
    called ECMAScript, only a specification. There are languages with
    other names impelementing this specification. At least, that's one way
    to see it.
    Another is to say that Javascript is ECMAScript (plus som more). And
    that Javascript Core *is* ECMAScript.
    People rutinely refer to ECMASCript as the standard for Javascript.
    It is somewhat fair to say that ECMAScript is also known as Javascript.

    Most people don't make a difference between the various ECMAScript
    implementations.

    > | The ECMA committee that has stewardship over the language is developing
    > | extensions which, while well intentioned, will aggravate one of the
    > | language's biggest problems: There are already too many versions.
    > | This creates confusion.
    >
    > ECMA does neither watch over JavaScript nor does it develop extensions
    > for it. ECMA International, as an "industry association [...] dedicated
    > to the standardization of information and communication systems[...]"[4]
    > where also Netscape/AOLTW and Microsoft are members of[5], watches over
    > ECMAScript.

    ....

    So, ECMA is not making the changes, the compagnies that are members of
    it does. Fair. If ECMA is accepting anything Netscape Corp. creates
    without looking at it, then I also agree that ECMA is not a very
    good standards institution. If anything can be made standard, then
    you have no qulaity guarantee.

    > | The design of the language on the whole is quite sound. Surprisingly,
    > | the ECMAScript committee does not appear to be interested in
    > | correcting these problems. Perhaps they are more interested in making
    > | new ones.
    >
    > Quite sound to whom? What a problem must the author have with "evil"
    > ECMA not following his misguided attempts to tell us that


    WEll, only he can know that. I guess he thinks there were some bad desing
    choices when Javascript was developed (and I agree with some of them).
    He calls them "errors", which you seem to take literally.

    Obviously you can find the places in the specification that says that
    what he considers errors, is in fact required by the specification.
    He thinks the specification should be (or rather: should have been)
    changed.

    > | JavaScript's C-like syntax, including curly braces and the clunky for
    > | statement, makes it appear to be an ordinary procedural language. This
    > | is misleading because JavaScript has more in common with functional
    > | languages like Lisp or Scheme than with C or Java.
    >
    > Because it allows for closures, currying and anonymous functions?


    Yes (except currying, unless you use that for the ability to return a
    function), and prototypical object inheritance.

    And I agree.

    If Javascript/ECMAScript had tail recursion, you could program
    functional programs in it.

    > OMG.
    > Obviously the author has never found (or did not wanted to find?) time
    > to read the ECMAScript specification thoroughly (see below.)


    Oh, I'm pretty sure he has. The page you are reading from is not
    an objective review of the language. It is giving a subjective opinion
    about the state of ECMAScript implementations in general and the
    standard in particular.

    > | The official specification for the language is published by ECMA.
    >
    > Wrong. The official specification for _ECMAScript_ is published by
    > ECMA.


    ECMAScript aka. Javscript (Core). Yes.

    > The official specification for JavaScript, if you can call the
    > Client-Side/Server-Side/Core JavaScript Guide and Reference this,


    You can't. It is far from being specific enough to being a
    specification. It is, at best, a manual.

    > is published and has always been published by Netscape(/AOLTW) as
    > *they* are to implement ECMAScript as JavaScript.



    > | The specification is of extremely poor quality. It is difficult to
    > | read, and very difficult to understand.
    >
    > Because the author is unable to read technical specifications, they must
    > be "of extremely poor quality." Well, there are at least two people (I
    > assume of one that he does because of his statements in this newsgroup)
    > that find it very well put and of good quality as recent research on
    > grammar productions has (again) proven.[10]


    It is very *thorough*. I *don't* think it is very well structured.
    I much prefer "the Revised^4 Report on the Algorithmic Language Scheme"
    ("R4RS", <URL:http://www.swiss.ai.mit.edu/~jaffer/r4rs_toc.html>) or
    "the Definition of Standard ML (Revised)"
    (<URL:http://www.diku.dk/forskning/topps/activities/kit2/def97.html>)
    Neither have, ofcourse, gone through a standards body.

    /L
    --
    Lasse Reichstein Nielsen -
    DHTML Death Colors: <URL:http://www.infimum.dk/HTML/rasterTriangleDOM.html>
    'Faith without judgement merely degrades the spirit divine.'
    Lasse Reichstein Nielsen, Nov 24, 2003
    #12
  13. Lasse Reichstein Nielsen wrote:

    > Thomas 'PointedEars' Lahn <> writes:
    >> Take the ECMA stuff for example:
    >>
    >> | JavaScript, aka Mocha, aka LiveScript, aka JScript, aka ECMAScript,
    >> | is one of the world's most popular programming languages.
    >>
    >> JavaScript is _not_ ECMAScript, it is and has always been,
    >> Netscape(/AOLTW)'s implementation of the latter.[1] JScript
    >> is *neither* JavaScript *nor* ECMAScript, it is *Microsoft's*
    >> implementation of ECMAScript, as one could have also read in
    >> the FAQ of this NG.[2]

    >
    > You are looking at his survey page. It is not intended as exact informatio


    That was what he appended to his posting following his
    "argumentation" and what we are discussion about.

    >> AFAIS, Mocha is a Java decompiler[3] and such has nothing to
    >> do with ECMAScript, JavaScript or other implementations of the
    >> former at all.

    >
    > .... and you are wrong:


    I just did not *see*/tested unregistered URI schemes and relied on
    friend Google.

    > <URL:http://www.mozilla.org/classic/libmdesc.html>
    > These are equivalent when written in the address bar of Netscape 4:
    > mocha:alert("X");
    > javascript:alert("X");
    > livescript:alert("X");
    >
    > So, Javascript aka. Livescript aka. Mocha is correct.


    Mozilla/5.0 including Netscape 6+ implements JavaScript 1.5 and I get

    | mocha is not a registered protocol.

    `livescript:alert("bla")' does nothing, interestingly.

    So I say: It is incorrect. See the point?

    > When you write
    > <script type="text/javascript">
    > IE interprets the content using its JScript interpreter.


    No, it interprets what is similar to JavaScript with its script
    interpreter. AFAIK that is not a JScript interpreter but one
    that knows also VBScript, part of the Windows Script Host.

    > It is fair to say that JScript is also known as Javascript,
    > so Javascript aka. JScript is correct.


    It is incorrect, JScript is _not_ JavaScript.

    > What is the language implemented by Opera?
    > They call it Javascript. It differs from Netscape's Javascript.
    > It implements ECMAScript v3 + extensions.
    > What is it?


    It is Opera's implementation of ECMAScript, and they falsely call
    it JavaScript.

    > The word "Javascript" long ago stopped only referring to Netscape's
    > brand of ECMAScript. It is now, like Kleenex, a common word used about
    > similar products from other compagnies.


    Most people call `Internet' now what is in fact the World Wide Web,
    a software application of and for the hardware Internet. People
    call many things by the wrong name because they cannot or refuse to
    understand that this makes a difference.

    > The one you can split hairs about is ECMAScript. There is no language
    > called ECMAScript, only a specification.


    ECMAScript is a (programming) language, and its specification proves
    that before its page #1. Brainfuck, Blank and stuff like that are
    programming languages, too. They do not need to be (widely) implemented
    to be it.

    > There are languages with other names impelementing this specification.
    > At least, that's one way to see it.


    There are languages which implement features of (the) ECMAScript (language).

    > Another is to say that Javascript is ECMAScript (plus som more).
    > And that Javascript Core *is* ECMAScript.


    No, it is not.

    > People rutinely refer to ECMASCript as the standard for Javascript.


    You are again being pointless, see above.

    > It is somewhat fair to say that ECMAScript is also known as Javascript.
    >
    > Most people don't make a difference between the various ECMAScript
    > implementations.


    See above.

    >> | The ECMA committee that has stewardship over the language is developing
    >> | extensions which, while well intentioned, will aggravate one of the
    >> | language's biggest problems: There are already too many versions.
    >> | This creates confusion.
    >>
    >> ECMA does neither watch over JavaScript nor does it develop extensions
    >> for it. ECMA International, as an "industry association [...] dedicated
    >> to the standardization of information and communication systems[...]"[4]
    >> where also Netscape/AOLTW and Microsoft are members of[5], watches over
    >> ECMAScript.

    > ....
    >
    > So, ECMA is not making the changes, the compagnies that are members of
    > it does.


    But regarding their implementations not in their function as member, but
    for themselves.

    > Fair. If ECMA is accepting anything Netscape Corp. creates
    > without looking at it,


    They do not and I have never written that.

    > then I also agree that ECMA is not a very good standards institution.
    > If anything can be made standard, then you have no qulaity guarantee.


    See above.

    > Obviously you can find the places in the specification that says that
    > what he considers errors, is in fact required by the specification.
    > He thinks the specification should be (or rather: should have been)
    > changed.


    I already know what he "thinks", but I cannot agree with it. As he
    tries to impose his opinion on others referring to the document, and I
    was asked to tell what I find wrong about it, I answered the question
    and stated my case.

    >> | JavaScript's C-like syntax, including curly braces and the clunky for
    >> | statement, makes it appear to be an ordinary procedural language. This
    >> | is misleading because JavaScript has more in common with functional
    >> | languages like Lisp or Scheme than with C or Java.
    >>
    >> Because it allows for closures, currying and anonymous functions?

    >
    > Yes (except currying, unless you use that for the ability to return a
    > function), and prototypical object inheritance.
    >
    > And I agree.
    >
    > If Javascript/ECMAScript had tail recursion, you could program
    > functional programs in it.


    And if my grandma had wheels, she would be a motorcycle.

    >> OMG.
    >> Obviously the author has never found (or did not wanted to find?) time
    >> to read the ECMAScript specification thoroughly (see below.)

    >
    > Oh, I'm pretty sure he has.


    I am pretty sure he has not. What is stated about the execution
    of statements does not fit to a functional language at all.

    > The page you are reading from is not an objective review of the
    > language. It is giving a subjective opinion about the state of
    > ECMAScript implementations in general and the standard in
    > particular.


    Exactly and that is why I call it "a load of FUD crap" when someone
    tries to argument with it.

    >> | The official specification for the language is published by ECMA.
    >>
    >> Wrong. The official specification for _ECMAScript_ is published by
    >> ECMA.

    >
    > ECMAScript


    Yes.

    > aka. Javscript (Core). Yes.


    No.

    >> The official specification for JavaScript, if you can call the
    >> Client-Side/Server-Side/Core JavaScript Guide and Reference this,

    >
    > You can't. It is far from being specific enough to being a
    > specification. It is, at best, a manual.


    You note the `if'? So if you state that the Guide and Reference is
    not a JavaScript specification, then ECMAScript cannot be a JavaScript
    specification, too, since Netscape's JavaScript as described in the
    Guide and Reference has been always a superset of ECMAScript. So there
    is no JavaScript specification at all.


    PointedEars
    Thomas 'PointedEars' Lahn, Nov 24, 2003
    #13
  14. Thomas 'PointedEars' Lahn <> writes:

    > Lasse Reichstein Nielsen wrote:


    > I just did not *see*/tested unregistered URI schemes and relied on
    > friend Google.


    That's where I found the information. I had never heard of Mocha or
    mocha: and livescript: schemas before.

    >> So, Javascript aka. Livescript aka. Mocha is correct.

    >
    > Mozilla/5.0 including Netscape 6+ implements JavaScript 1.5 and I get
    >
    > | mocha is not a registered protocol.
    >
    > `livescript:alert("bla")' does nothing, interestingly.
    >
    > So I say: It is incorrect. See the point?


    No. Netscape 4, made by the people who created Javascript, used the
    words "mocha" and "livescript" about it too. They might not do that
    any more, but they did. At some point, Javascript was also known as
    Mocha and Livescript (and personally, I would have preferred if they
    stayed with "Livescript"). And some people still remember.

    I can't see what Mozilla has to do with this.

    >> When you write
    >> <script type="text/javascript">
    >> IE interprets the content using its JScript interpreter.

    >
    > No, it interprets what is similar to JavaScript with its script
    > interpreter. AFAIK that is not a JScript interpreter but one
    > that knows also VBScript, part of the Windows Script Host.


    The Windows Scripting Host has several separate interpreters built in.
    It can also be extended with, e.g., PerlScript or PythonScript.

    The interpreter IE uses for scripts with type="text/javascript" is
    the JScript interpreter.

    >> It is fair to say that JScript is also known as Javascript,
    >> so Javascript aka. JScript is correct.

    >
    > It is incorrect, JScript is _not_ JavaScript.


    No, but it is *also known as* Javascript. Perhaps incorrectly, but it
    is. You would be hard pressed to find people who would claim that
    "IE doesn't support Javascript".

    > It is Opera's implementation of ECMAScript, and they falsely call
    > it JavaScript.


    Actually, they don't (I should have checked!).
    They call it ECMAScript+DOM, and they list their support for non-standard
    JavaScript and JScript properties. So that was a lousy argument for me :)

    > Most people call `Internet' now what is in fact the World Wide Web,
    > a software application of and for the hardware Internet. People
    > call many things by the wrong name because they cannot or refuse to
    > understand that this makes a difference.


    Language is a funny beast, and in most countries it is fully
    democratic. If enough people decide that something is called
    something, then that's what it's called.

    While I would love to agree with you, and only use Javascript for the
    products of Netscape Corp, even the name of this group shows that that
    is now how the word is used. (As a side note, the similar Danish group
    is named dk.<something>.clientside, which (while not Danish) is
    actually a more fitting name)

    When people ask "Javascript" questions, we make sure to give answers
    that work in both Opera ECMAScript and JScript too ... because we know
    that that is what is meant.

    > ECMAScript is a (programming) language,


    Ok, I was reaching there. It is a programming language.

    What the ECMAScript standard says is:
    ---
    This ECMA Standard is based on several originating technologies, the
    most well known being JavaScript (Netscape) and JScript
    (Microsoft). The language was invented by Brendan Eich at Netscape and
    first appeared in that company's Navigator 2.0 browser. It has
    appeared in all subsequent browsers from Netscape and in all browsers
    from Microsoft starting with Internet Explorer 3.0.
    ---
    (BTW, notice that they call it "The language", as if Javascript and
    JScript are the same language.)

    >> Another is to say that Javascript is ECMAScript (plus som more).
    >> And that Javascript Core *is* ECMAScript.

    >
    > No, it is not.


    Ok, Javascript Core is an implementation of ECMAScript, extended with
    extra features?

    >>> ECMA does neither watch over JavaScript


    Was the point here that ECMA watches over ECMAScript, not Javascript?

    >> Obviously you can find the places in the specification that says that
    >> what he considers errors, is in fact required by the specification.
    >> He thinks the specification should be (or rather: should have been)
    >> changed.

    >
    > I already know what he "thinks", but I cannot agree with it.


    That's your choice. I agree with some of it.

    > As he tries to impose his opinion on others referring to the
    > document, and I was asked to tell what I find wrong about it, I
    > answered the question and stated my case.


    You were pointing out that what the standard specified, was different
    from what he wanted. There was no need to find the places in the
    specification. We know it disagrees.

    >>> | JavaScript's C-like syntax, including curly braces and the clunky for
    >>> | statement, makes it appear to be an ordinary procedural language. This
    >>> | is misleading because JavaScript has more in common with functional
    >>> | languages like Lisp or Scheme than with C or Java.



    >> If Javascript/ECMAScript had tail recursion, you could program
    >> functional programs in it.

    >
    > And if my grandma had wheels, she would be a motorcycle.


    Just a comment. One thing that I would want changed in ECMAScript.

    > I am pretty sure he has not. What is stated about the execution
    > of statements does not fit to a functional language at all.


    No. And?

    In *many* ways, Javascript/ECMAScript has *more in common* with
    languages like Scheme (first class functions, dynamic typing) and Self
    (prototype based object inheritance) than with ordinary procedural
    (and even class based OO) languages.

    The similarity to Scheme is not as clear as that to Self, but it's
    there. If you program Javascript/ECMAScript like you program Java,
    you will make lousy programs. The language is different and the
    most efficient way to program it is also different ... and has
    *more in common* with languages like Scheme and Self.

    > You note the `if'? So if you state that the Guide and Reference is
    > not a JavaScript specification, then ECMAScript cannot be a JavaScript
    > specification, too, since Netscape's JavaScript as described in the
    > Guide and Reference has been always a superset of ECMAScript. So there
    > is no JavaScript specification at all.


    Sounds fair.

    Ok, from now on, I will use the following notation:

    JavaScript (captial S): The JavaScript Core + DOM produced by Netscape
    ECMASCript : the language defined in ECMA 262 v3.
    Javascript (small s): Any implementation of ECMAScript used in a browser.

    The last group of languages needed a name, so I'll use the one that
    is commonly used about it.
    /L
    --
    Lasse Reichstein Nielsen -
    DHTML Death Colors: <URL:http://www.infimum.dk/HTML/rasterTriangleDOM.html>
    'Faith without judgement merely degrades the spirit divine.'
    Lasse Reichstein Nielsen, Nov 24, 2003
    #14
  15. "Thomas 'PointedEars' Lahn" <> wrote in message
    news:...
    <snip>
    >>>|The official specification for the language is published by
    >>>|ECMA.


    >>>Wrong. The official specification for _ECMAScript_ is
    >>>published by ECMA.

    >>
    >> ECMAScript

    >
    >Yes.
    >
    >> aka. Javscript (Core). Yes.

    >
    >No.

    <snip>

    While it self evidently can be argued that Javascript is distinct from
    other ECMA 262 conforming (or near conforming) language implementations
    but it seems to be only a pedantic word game to do so. Arguing that
    Javascript is unique to Netscape would seem to undermine the strong bias
    that comp.lang.javascript has towards cross-browser script development.
    The problem with arguing strict literal definitions of a term is that
    even if a final decision can be reached about the definitions there is
    *always* the opportunity to resume the argument with the definition of
    the words used to define the first term. Making any move in that
    direction potentially infinitely recurring.

    Ultimately, in order to move on, it would have to be accepted that a
    nominal term will be understood to mean something sufficiently like what
    the person using it intends to the person/people heating it. In the
    context of comp.lang.javascript it does not seem unreasonable to use the
    term JavaScript to mean something like "a group of programming languages
    commonly implemented in web browsers with almost indistinguishable
    syntax and behaviour, built around conformance with a version of ECMA
    262" even if someone's registered trademark may suggest otherwise. Then
    again there may be others who just think "browser scripting language",
    but in most contexts that is sufficient to understand its meaning. They
    probably don't really need to know, for example, which features
    introduced into Netscape's 1.2 version were dropped from version 1.3 in
    order to comply with ECMA 262, to understand general comments about a
    concept labelled "Javascript".

    Richard.
    Richard Cornford, Nov 24, 2003
    #15
    1. Advertising

Want to reply to this thread or ask your own question?

It takes just 2 minutes to sign up (and it's free!). Just click the sign up button to choose a username and then you can ask your own questions on the forum.
Similar Threads
  1. grbgooglefan
    Replies:
    2
    Views:
    409
    Pascal Bourguignon
    Jan 30, 2008
  2. grbgooglefan
    Replies:
    4
    Views:
    428
    Kenny McCormack
    Jan 30, 2008
  3. grbgooglefan
    Replies:
    0
    Views:
    382
    grbgooglefan
    Jan 30, 2008
  4. Alok
    Replies:
    3
    Views:
    238
  5. THAKUR PRASHANT SINGH

    Class Function call vs Normal Function call

    THAKUR PRASHANT SINGH, Feb 26, 2010, in forum: Ruby
    Replies:
    7
    Views:
    170
    THAKUR PRASHANT SINGH
    Feb 27, 2010
Loading...

Share This Page