Augmenting Types

Discussion in 'Javascript' started by Ryan Chan, Jan 3, 2010.

  1. Ryan Chan

    Ryan Chan Guest

    Have read Douglas Crockfore's JavaScript The Good Parts, it recommend
    Augmenting Types, e.g.

    Function.prototype.method = function(name, func) {
    this.prototype[name] = func;
    return this;
    };

    String.method('trim', function() {
    return this.replace(/^\s+|\s+$/g, '');
    });


    Is this a good thing in your opinion?
     
    Ryan Chan, Jan 3, 2010
    #1
    1. Advertising

  2. Ryan Chan

    David Mark Guest

    On Jan 3, 12:40 am, Ryan Chan <> wrote:
    > Have read Douglas Crockfore's JavaScript The Good Parts, it recommend
    > Augmenting Types, e.g.


    ....among other bad things.

    >
    > Function.prototype.method = function(name, func) {
    >     this.prototype[name] = func;
    >     return this;
    >
    > };
    >
    > String.method('trim', function() {
    >     return this.replace(/^\s+|\s+$/g, '');
    >
    > });


    Dear God. That's another step towards the abyss. :) First I find
    out that YUI is crap and now this? Oh well, JSLint is nice anyway
    (most of it).

    >
    > Is this a good thing in your opinion?


    No.
     
    David Mark, Jan 3, 2010
    #2
    1. Advertising

  3. Ryan Chan wrote:

    > Have read Douglas Crockfore's JavaScript The Good Parts, it recommend
    > Augmenting Types, e.g.
    >
    > Function.prototype.method = function(name, func) {
    > this.prototype[name] = func;
    > return this;
    > };
    >
    > String.method('trim', function() {
    > return this.replace(/^\s+|\s+$/g, '');
    > });
    >
    >
    > Is this a good thing in your opinion?


    No, because the call to String.method() would unconditionally overwrite the
    property value in case there was already such a method. There needs to be
    one in conforming implementations of ECMAScript Edition 5, so if you use
    this exact pattern, you would in effect be replacing the faster built-in
    method by a slower user-defined one. It is understandable that the book
    does not consider this possibility as Edition 5 was published not before
    2009-12. However, that does not excuse the lack of feature test before the
    assignment or the lack of a property registry to work around unwanted
    enumeration.

    As to the question you wanted to ask: Such syntactic sugar can be a good
    thing if done properly, and there is little wrong with it in this example.
    However, if you augment built-in prototype objects you need to be aware
    that all objects that have them in their prototype chain inherit those
    properties, and that at least new prototype properties are enumerable (see
    for-in iteration). Especially, if you augment the Object prototype object
    the new properties will show up with for-in iteration over Array instances,
    as their prototype chain is

    [object Array] --> Array.prototype --> Object.prototype


    PointedEars
    --
    Prototype.js was written by people who don't know javascript for people
    who don't know javascript. People who don't know javascript are not
    the best source of advice on designing systems that use javascript.
    -- Richard Cornford, cljs, <f806at$ail$1$>
     
    Thomas 'PointedEars' Lahn, Jan 3, 2010
    #3
  4. Ryan Chan wrote:
    > Have read Douglas Crockfore's JavaScript The Good Parts, it recommend
    > Augmenting Types, e.g.
    >
    > Function.prototype.method = function(name, func) {
    > this.prototype[name] = func;
    > return this;
    > };
    >


    This is not a good thing.

    The `method` method is not related to all Functions; only constructors.

    It takes more time to comprehend that method than:-

    MyConstructor.prototype.foo = fooFunc;

    That method is unnecessary, not well named, adds overhead, adds clutter.

    I criticized this part in another thread:
    http://groups.google.com/group/comp...b741525ab6d/cd561210abc96faa#cd561210abc96faa

    > String.method('trim', function() {
    > return this.replace(/^\s+|\s+$/g, '');
    > });
    >


    No, it is not a good idea to replace a built-in method with a
    hand-rolled version; not without good reason. In fact, without good
    reason, that has some negative consequences.

    String.prototype.trim is an ES5 standard method. It is implemented in
    Tracemonkey (in Firefox).

    A good reason for doing that would be, say, if an implementation did not
    yet support the new method, or if it was shown to be buggy, but only
    then after performing a /feature test/. The FAQ contains an example of
    just that.

    When Douglas wrote that, he probably did not consider the possibility
    that String.prototype.trim would be added to the language.

    The consequence of adding String.prototype.trim is that it replaces the
    built-in String.prototype.trim with a user-defined version. That
    user-defined version will not perform as fast as native code that it
    replaced and will throw errors when used in a generic context.

    | The following steps are taken:
    | 1. Call CheckObjectCoercible passing the this value as its argument.
    | 2. Let S be the result of calling ToString, giving it the this value
    | as its argument.
    | 3. Let T be a String value that is a copy of S with both leading and
    | trailing white space removed. The definition of white space is the
    | union of WhiteSpace and LineTerminator.
    | 4. Return T.
    |
    | NOTE The trim function is intentionally generic; it does not require
    | that its this value be a String object. Therefore, it can be
    | transferred to other kinds of objects for use as a method.

    The following are specified to work in ES5:

    var trimFn = String.prototype.trim;
    trimFn.call( window.getSelection() )
    trimFn.call( new Error("You broke it.") );
    trimFn.call( window.location );
    trimFn.call( document.links[0] );

    var range = document.createRange();
    range.selectNode(document.body);

    trimFn.call(range);

    In Firefox, they correctly do convert the thisArt to string, as
    specified by the standard.

    However, when Douglas' method replaces that, it results in a TypeError.

    By creating your own namespace, collisions like that can be avoided.
    --
    Garrett
    comp.lang.javascript FAQ: http://jibbering.com/faq/
     
    Garrett Smith, Jan 3, 2010
    #4
  5. Garrett Smith wrote:

    > Ryan Chan wrote:
    >> Have read Douglas Crockfore's JavaScript The Good Parts, it recommend
    >> Augmenting Types, e.g.
    >>
    >> Function.prototype.method = function(name, func) {
    >> this.prototype[name] = func;
    >> return this;
    >> };
    >>

    >
    > This is not a good thing.
    >
    > The `method` method is not related to all Functions; only constructors.


    Non sequitur. All Function instances may be used as constructor.

    > It takes more time to comprehend that method than:-
    >
    > MyConstructor.prototype.foo = fooFunc;


    Only that this is not equivalent (note the `return'), and if feature-tests
    were added as they should be, there would probably be the clutter that you
    are talking of below, in the main code.

    > That method is unnecessary,


    No.

    > not well named,


    True, it would only qualify as `method' if it checked for method references
    for the second argument, and the property name misses a verb (e.g.
    setMethod).

    > adds overhead,


    Any abstraction does. That is not a good reason for not doing it.

    > adds clutter.


    Define: clutter.

    > By creating your own namespace, collisions like that can be avoided.


    Whereas `namespace' should be understood as syntactic sugar created by
    aggregation, not (yet) as a language feature. One should therefore be
    aware that the less probability of name collision that this "namespacing"
    provides comes with a performance penalty.


    PointedEars
    --
    Danny Goodman's books are out of date and teach practices that are
    positively harmful for cross-browser scripting.
    -- Richard Cornford, cljs, <cife6q$253$1$> (2004)
     
    Thomas 'PointedEars' Lahn, Jan 3, 2010
    #5
  6. Ryan Chan

    Jorge Guest

    On Jan 3, 6:40 am, Ryan Chan <> wrote:
    > Have read Douglas Crockfore's JavaScript The Good Parts, it recommend
    > Augmenting Types, e.g.
    >
    > Function.prototype.method = function(name, func) {
    >     this.prototype[name] = func;
    >     return this;
    >
    > };
    >
    > String.method('trim', function() {
    >     return this.replace(/^\s+|\s+$/g, '');
    >
    > });
    >
    > Is this a good thing in your opinion?


    The -handy- ability to -miraculously- extend types on the fly -at
    runtime- is another of these awesome JS's features that Brendan Eich
    put there just for you not to use it. LOL.
    --
    Jorge.
     
    Jorge, Jan 3, 2010
    #6
  7. Ryan Chan

    David Mark Guest

    On Jan 3, 10:42 am, Jorge <> wrote:
    > On Jan 3, 6:40 am, Ryan Chan <> wrote:
    >
    > > Have read Douglas Crockfore's JavaScript The Good Parts, it recommend
    > > Augmenting Types, e.g.

    >
    > > Function.prototype.method = function(name, func) {
    > >     this.prototype[name] = func;
    > >     return this;

    >
    > > };

    >
    > > String.method('trim', function() {
    > >     return this.replace(/^\s+|\s+$/g, '');

    >
    > > });

    >
    > > Is this a good thing in your opinion?

    >
    > The -handy- ability to -miraculously- extend types on the fly -at
    > runtime- is another of these awesome JS's features that Brendan Eich
    > put there just for you not to use it. LOL.



    Get a brain, Jorge. That's not what was asked.
     
    David Mark, Jan 3, 2010
    #7
  8. On 3 Ñнв, 08:40, Ryan Chan <> wrote:
    > Have read Douglas Crockfore's JavaScript The Good Parts, it recommend
    > Augmenting Types, e.g.
    >
    > Function.prototype.method = function(name, func) {
    >     this.prototype[name] = func;
    >     return this;
    >
    > };
    >
    > String.method('trim', function() {
    >     return this.replace(/^\s+|\s+$/g, '');
    >
    > });
    >
    > Is this a good thing in your opinion?


    For do not repeat myself: <URL:
    http://groups.google.ru/group/comp.lang.javascript/browse_thread/thread/b5d5cf808c064462/bbfb83eb82ef9b41?hl=en#bbfb83eb82ef9b41>

    You should understand first the main issues related to the augmenting
    of the built-ins. After that you can decide yourself is it a good
    thing or not.

    In general, if you understand what you're doing, it's not a bad
    practice at all.

    /ds
     
    Dmitry A. Soshnikov, Jan 3, 2010
    #8
  9. Ryan Chan

    Jorge Guest

    On Jan 3, 4:46 pm, David Mark <> wrote:
    > On Jan 3, 10:42 am, Jorge <> wrote:
    >
    >
    >
    >
    >
    > > On Jan 3, 6:40 am, Ryan Chan <> wrote:

    >
    > > > Have read Douglas Crockfore's JavaScript The Good Parts, it recommend
    > > > Augmenting Types, e.g.

    >
    > > > Function.prototype.method = function(name, func) {
    > > >     this.prototype[name] = func;
    > > >     return this;

    >
    > > > };

    >
    > > > String.method('trim', function() {
    > > >     return this.replace(/^\s+|\s+$/g, '');

    >
    > > > });

    >
    > > > Is this a good thing in your opinion?

    >
    > > The -handy- ability to -miraculously- extend types on the fly -at
    > > runtime- is another of these awesome JS's features that Brendan Eich
    > > put there just for you not to use it. LOL.

    >
    > Get a brain, Jorge.  That's not what was asked.


    Dear God. NO. That's another step towards the abyss. :)
    --
    Jorge.
     
    Jorge, Jan 3, 2010
    #9
  10. Ryan Chan

    David Mark Guest

    On Jan 3, 10:50 am, "Dmitry A. Soshnikov" <>
    wrote:
    > On 3 Ñнв, 08:40, Ryan Chan <> wrote:
    >
    > > Have read Douglas Crockfore's JavaScript The Good Parts, it recommend
    > > Augmenting Types, e.g.

    >
    > > Function.prototype.method = function(name, func) {
    > >     this.prototype[name] = func;
    > >     return this;

    >
    > > };

    >
    > > String.method('trim', function() {
    > >     return this.replace(/^\s+|\s+$/g, '');

    >
    > > });

    >
    > > Is this a good thing in your opinion?

    >
    > For do not repeat myself: <URL:http://groups.google.ru/group/comp.lang.javascript/browse_thread/thre...>
    >
    > You should understand first the main issues related to the augmenting
    > of the built-ins. After that you can decide yourself is it a good
    > thing or not.
    >
    > In general, if you understand what you're doing, it's not a bad
    > practice at all.
    >


    In a Web page, it's generally a terrible idea as scripts typically
    have to co-exist with others. It pays to be defensive. ;) And that
    "method" method is ridiculous.
     
    David Mark, Jan 3, 2010
    #10
  11. Ryan Chan

    David Mark Guest

    On Jan 3, 11:00 am, Jorge <> wrote:
    > On Jan 3, 4:46 pm, David Mark <> wrote:
    >
    >
    >
    > > On Jan 3, 10:42 am, Jorge <> wrote:

    >
    > > > On Jan 3, 6:40 am, Ryan Chan <> wrote:

    >
    > > > > Have read Douglas Crockfore's JavaScript The Good Parts, it recommend
    > > > > Augmenting Types, e.g.

    >
    > > > > Function.prototype.method = function(name, func) {
    > > > >     this.prototype[name] = func;
    > > > >     return this;

    >
    > > > > };

    >
    > > > > String.method('trim', function() {
    > > > >     return this.replace(/^\s+|\s+$/g, '');

    >
    > > > > });

    >
    > > > > Is this a good thing in your opinion?

    >
    > > > The -handy- ability to -miraculously- extend types on the fly -at
    > > > runtime- is another of these awesome JS's features that Brendan Eich
    > > > put there just for you not to use it. LOL.

    >
    > > Get a brain, Jorge.  That's not what was asked.

    >
    > Dear God. NO. That's another step towards the abyss.  :)


    Is that the "Jorge" re-mix? :(
     
    David Mark, Jan 3, 2010
    #11
  12. On 3 Ñнв, 19:06, David Mark <> wrote:
    > On Jan 3, 10:50 am, "Dmitry A. Soshnikov" <>
    > wrote:
    >
    >
    >
    > > On 3 Ñнв, 08:40, Ryan Chan <> wrote:

    >
    > > > Have read Douglas Crockfore's JavaScript The Good Parts, it recommend
    > > > Augmenting Types, e.g.

    >
    > > > Function.prototype.method = function(name, func) {
    > > >     this.prototype[name] = func;
    > > >     return this;

    >
    > > > };

    >
    > > > String.method('trim', function() {
    > > >     return this.replace(/^\s+|\s+$/g, '');

    >
    > > > });

    >
    > > > Is this a good thing in your opinion?

    >
    > > For do not repeat myself: <URL:http://groups.google.ru/group/comp.lang.javascript/browse_thread/thre...>

    >
    > > You should understand first the main issues related to the augmenting
    > > of the built-ins. After that you can decide yourself is it a good
    > > thing or not.

    >
    > > In general, if you understand what you're doing, it's not a bad
    > > practice at all.

    >


    > terrible idea
    > terrible
    > terrible idea


    Please, don't use demagogy, propaganda, and statement forms (novices
    also read this and they can believe that propaganda is conclusive
    true, but it's not always so) ;) Exchanging with meanings can't
    operate with that. Or if you would like, please add "imHo" every time
    you want to write so. It will be fairly, are you agree? ;)

    > In a Web page, it's generally a terrible idea as scripts typically
    > have to co-exist with others.


    Well, yeah, I've mentioned - user should understand all the issues. If
    he see the issues, he can decide do not do that. If not - he can do
    that. It seems quite simple. Of cause, user should understand what
    he's doing and why he's doing so.

    For do not repeat myself, one more link: <URL:
    http://groups.google.ru/group/comp.lang.javascript/browse_thread/thread/24ceb2af21b27a3b/560a9fb04339fdb8#f4ea783833329f83>

    /ds
     
    Dmitry A. Soshnikov, Jan 3, 2010
    #12
  13. Ryan Chan

    David Mark Guest

    On Jan 3, 11:38 am, "Dmitry A. Soshnikov" <>
    wrote:
    > On 3 Ñнв, 19:06, David Mark <> wrote:
    >
    >
    >
    > > On Jan 3, 10:50 am, "Dmitry A. Soshnikov" <>
    > > wrote:

    >
    > > > On 3 Ñнв, 08:40, Ryan Chan <> wrote:

    >
    > > > > Have read Douglas Crockfore's JavaScript The Good Parts, it recommend
    > > > > Augmenting Types, e.g.

    >
    > > > > Function.prototype.method = function(name, func) {
    > > > >     this.prototype[name] = func;
    > > > >     return this;

    >
    > > > > };

    >
    > > > > String.method('trim', function() {
    > > > >     return this.replace(/^\s+|\s+$/g, '');

    >
    > > > > });

    >
    > > > > Is this a good thing in your opinion?

    >
    > > > For do not repeat myself: <URL:http://groups.google.ru/group/comp.lang.javascript/browse_thread/thre...>

    >
    > > > You should understand first the main issues related to the augmenting
    > > > of the built-ins. After that you can decide yourself is it a good
    > > > thing or not.

    >
    > > > In general, if you understand what you're doing, it's not a bad
    > > > practice at all.

    >
    > > terrible idea
    > > terrible
    > > terrible idea


    I didn't write this. (?!)

    >
    > Please, don't use demagogy, propaganda, and statement forms (novices
    > also read this and they can believe that propaganda is conclusive
    > true, but it's not always so) ;)


    Please don't forge quotes. :(
     
    David Mark, Jan 3, 2010
    #13
  14. On 3 Ñнв, 19:47, David Mark <> wrote:


    >
    > > > terrible idea
    > > > terrible
    > > > terrible idea

    >
    > I didn't write this. (?!)
    >
    >
    >
    > > Please, don't use demagogy, propaganda, and statement forms (novices
    > > also read this and they can believe that propaganda is conclusive
    > > true, but it's not always so) ;)

    >
    > Please don't forge quotes.  :(


    That was specially to show that I see your speaking manner and free
    you from trying to do that (you can stop trying it, I've already
    "appreciate" it) ;) You know, it also can be so, when person don't
    completely understand what he's talking about, he can use some
    demagogy and statement form for to show to the other readers, that
    he's speaking with the sure tone. Sure better to use some strong words
    such as "terrible" and so on. It can be treated by those who don't
    completely understand the subject, that that person speaks (always)
    truly.

    You statement with the sure tone that it's "terrible idea", although,
    it's just your (humble.) opinion. Will you mind?

    P.S.: Though, all this does not cancel really awful and terrible
    ideas ;) I also can use this words when the idea is really terrible.

    /ds
     
    Dmitry A. Soshnikov, Jan 3, 2010
    #14
  15. On 3 Ñнв, 19:06, David Mark <> wrote:

    >And that
    > "method" method is ridiculous.


    I didn't touch the concrete method(s) of Crockford, I don't mind. I
    was talking about the general theory of the augmenting of the built-
    ins.

    But yep, the "method" method is ridiculous, I agree ;)

    /ds
     
    Dmitry A. Soshnikov, Jan 3, 2010
    #15
  16. On Sun, 3 Jan 2010 at 08:38:18, in comp.lang.javascript, Dmitry A.
    Soshnikov wrote:
    >On 3 0

    <snip>
    >> terrible idea
    >> terrible
    >> terrible idea

    >
    >Please, don't use demagogy, propaganda, and

    <snip>

    Please don't give such misleading quotes. They are a form of demagogy
    and propaganda.


    You could have quoted like this :

    >> In a Web page, it's generally a terrible idea


    <your complaint about 'terrible'>

    >>as scripts typically
    >> have to co-exist with others.


    <your agreement about 'co-exist'>

    John
    --
    John Harris
     
    John G Harris, Jan 3, 2010
    #16
  17. On 3 Ñнв, 20:51, John G Harris <> wrote:
    > On Sun, 3 Jan 2010 at 08:38:18, in comp.lang.javascript, Dmitry A.Soshnikov wrote:
    > >On 3 0

    >   <snip>
    > >> terrible idea
    > >> terrible
    > >> terrible idea

    >
    > >Please, don't use demagogy, propaganda, and

    >
    >   <snip>
    >
    > Please don't give such misleading quotes. They are a form of demagogy
    > and propaganda.
    >


    Please, pay attention that I used it specially (as a kind of irony) to
    show, how it looks. For what reason, I should give in on provocation
    and accept such rules when one person statements his humble opinion
    with sure tone "That's wrong. That's terrible." (this person tries to
    take the main role and to take the dialog in his hands) and the other
    one should prove why it's not so (this person is kind of that
    justifies). It's direct demagogy which I see and don't wanna accept.
    That's it. Objections?

    > You could have quoted like this :
    >
    > >> In a Web page, it's generally a terrible idea

    >
    >   <your complaint about 'terrible'>
    >


    I know that, thanks.

    > >>as scripts typically
    > >> have to co-exist with others.

    >
    >   <your agreement about 'co-exist'>
    >


    I also know that, thanks.

    /ds
     
    Dmitry A. Soshnikov, Jan 3, 2010
    #17
  18. Ryan Chan

    Jorge Guest

    On Jan 3, 6:51 pm, John G Harris <> wrote:
    > (...)
    > >> as scripts typically
    > >> have to co-exist with others.

    >
    > <your agreement about 'co-exist'>


    "agreement" ?

    The typicality of that hypothetical coexistence is very debatable.
    And, in any case, "others" is !== "unknown scripts". Do you allow
    "unknown" code to run in your page ? Does any of these -hypothetical-
    cohabitant scripts break anything ? And if they do, why ? Don't their
    authors know about .hasOwnProperty() existence and purpose ? Is that
    reason enough to ditch .prototype inheritance altogether ? The answer,
    in general, is NOT yes. The answer, in general, is of course NOT.
    --
    Jorge.
     
    Jorge, Jan 3, 2010
    #18
  19. Ryan Chan

    David Mark Guest

    On Jan 3, 1:50 pm, Jorge <> wrote:
    > On Jan 3, 6:51 pm, John G Harris <> wrote:
    >
    > > (...)
    > > >> as scripts typically
    > > >> have to co-exist with others.

    >
    > > <your agreement about 'co-exist'>

    >
    > "agreement" ?
    >
    > The typicality of that hypothetical coexistence is very debatable.


    That's ludicrous. How many Web pages use a single script from a
    single author (well, I know of a few at least). :)

    > And, in any case, "others" is !== "unknown scripts". Do you allow
    > "unknown" code to run in your page ?


    Me? Not typically, no. Am I typical?

    > Does any of these -hypothetical-
    > cohabitant scripts break anything ?


    You are babbling.

    > And if they do, why ? Don't their
    > authors know about .hasOwnProperty() existence and purpose ?


    You truly are a student of Crockford. For about the millionth time,
    that method doesn't work in "ancient" browsers like Safari 2. I see
    it used without proper feature detection and wonder if the authors
    realize their scripts will suddenly halt at that spot. Does that seem
    a sound degradation strategy to you?

    And of all the miserable JS libraries out there, how many actually
    filter for-in loops in any form?

    > Is that
    > reason enough to ditch .prototype inheritance altogether ?


    Does it seem to you that I've "ditched" ".prototype inheritance".
    Look again.

    > The answer,
    > in general, is NOT yes.
    > The answer, in general, is of course NOT.


    Lucid as always. :)
     
    David Mark, Jan 3, 2010
    #19
  20. Ryan Chan

    JR Guest

    On Jan 3, 3:40 am, Ryan Chan <> wrote:
    > Have read Douglas Crockfore's JavaScript The Good Parts, it recommend
    > Augmenting Types, e.g.
    >
    > Function.prototype.method = function(name, func) {
    >     this.prototype[name] = func;
    >     return this;
    >
    > };


    I've read the book too, but in my version (2008 in Portuguese) that
    function is slightly different, with one very important feature test:

    Function.prototype.method = function (name, func) {
    if (!this.prototype[name]) {
    this.prototype[name] = func;
    // I didn't see this return this mentioned above.
    }
    };

    And there is a precautionary note about augmenting types, specially
    when the page utilizes different libraries / codes.
    I also have not read Douglas recommending this type of thing, but
    saying that it was possible to do so, arguing that it could make
    improvements in the expressiveness of JavaScript.

    However, I must admit that that 'part' of the book is confusing and
    can mislead readers about the matter (augmenting types); in other
    words, a reader might unwittingly adopt the book's example as a good
    practice, what would be a temerity.

    > String.method('trim', function() {
    >     return this.replace(/^\s+|\s+$/g, '');
    >
    > });
    >
    > Is this a good thing in your opinion?


    No, it isn't, even in case you know exactly what you're doing.

    --
    JR
     
    JR, Jan 4, 2010
    #20
    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. Sathyaish
    Replies:
    2
    Views:
    590
    Sathyaish
    May 22, 2005
  2. David Bolen
    Replies:
    4
    Views:
    409
    David Bolen
    Aug 28, 2003
  3. Soren Kuula
    Replies:
    2
    Views:
    564
    Henry S. Thompson
    Dec 1, 2005
  4. disappearedng

    Augmenting functions

    disappearedng, Nov 13, 2008, in forum: Javascript
    Replies:
    6
    Views:
    85
    John G Harris
    Nov 14, 2008
  5. optimistx

    Augmenting ECMA-262 specs: crazy idea?

    optimistx, Nov 6, 2009, in forum: Javascript
    Replies:
    8
    Views:
    157
    Dmitry A. Soshnikov
    Nov 9, 2009
Loading...

Share This Page