Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]


Groups > comp.lang.javascript > #16829

Re: Built-in native method

Message-ID <67583587.7BbXikoxoM@PointedEars.de> (permalink)
From Thomas 'PointedEars' Lahn <PointedEars@web.de>
Organization PointedEars Software (PES)
Date 2012-10-24 02:15 +0100
Subject Re: Built-in native method
Newsgroups comp.lang.javascript
References <k5sbuj$bt8$1@speranza.aioe.org>
Followup-To comp.lang.javascript

Followups directed to: comp.lang.javascript

Show all headers | View raw


Cezary Tomczyk wrote:

> I have read this article:
> http://perfectionkills.com/extending-built-in-native-objects-evil-or-not/
> 
> At the end there is:
> 
> "[...] It should be now clear that extending native built-ins is
> definitely not as risky as messing with host objects. Do it carefully,
> follow spec closely, and use your reasonable judgement.[...]"
> 
> In my project I use some of the 3-rd party library. I didn't knew that
> this library overwritten many of built-in native methods.

Do not use that library then; it is junk.  A library should only overwrite 
built-in methods (that is, the properties that refer to the respective 
Function objects) when they do _not_ exist, or are not as capable as 
required (if it is reasonable to use this and no other method).  Built-in 
methods are inevitably faster than user-defined ones because in most of the 
cases the former are already compiled.

Any library that provides an emulation of a built-in method should only do 
that after it has been determined that the built-in method is unavailable:

  if (typeof foo.whatever != "function")
  {
    foo.whatever = function (…) {
      …
    };
  }

or even

  if (typeof foo.whatever != "undefined")
  {
    foo.whatever = function (…) {
      …
    };
  }

`foo' should not refer to a host object then.  And whenever a built-in 
method is overwritten by a library, it should be done so that the specified 
way of calling that method is still supported.

For example, it has been reasonable (but may be considered obsolete now) to 
overwrite a not-as-capable Math.max() method:

  /**
   * Returns the numeric maximum of all arguments.
   * 
   * @params : Number
   * @return {Number}
   *   <code>-Infinity</code> if no arguments have been passed.
   */
  function Math_max ()
  {
    var result = Number.NEGATIVE_INFINITY;

    /* NOTE: Array.prototype.slice() was not specified before ES 3 */
    for (var i = arguments.length; i--;)
    {
      var arg = parseFloat(arguments[i]);
      if (arg > result)
      {
        result = arg;
      }
    }

    return result;
  }

  var x;

  if (typeof Math.max == "function")
  {
    x = Math.max(1, 2, 3);
  }

  if (typeof x == "undefined" || x != 3)
  {
    Math.max = Math_max;
  }

> And even worst, they work different than they should. I mean, results is
> not the same as expected.
> 
> So, when I'm doing:
> 
> if (String.prototype.trim)
> 
> and its passed then this means that trim method exists.

No, it means that the String prototype object has a `trim' property whose 
value can be type-converted to `true'.

> Is there a way to check if (for example: String.prototype.trim) is a
> real built-in method?

No (looking for "[native code]" is _not_ reliable; function serialization is 
*implementation-dependent*), and there should not be a need for it.  
However, you can increase the probabililty that the property (value) is 
callable, and you can handle odd cases (this may be part of a user-defined 
wrapper):

  if (typeof bar.trim == "function")
  {
    try
    {
      var foo = bar.trim();
    }
    catch (e)
    {
      …
    }
  }

try-catch might need to be guarded for a maximum of backwards-compatibility:

  if (typeof bar.trim == "function")
  {
    eval("try { var foo = bar.trim(); }"
       + "catch (e) { … }");
  }

See also: http://PointedEars.de/es-matrix>


PointedEars
-- 
> If you get a bunch of authors […] that state the same "best practices"
> in any programming language, then you can bet who is wrong or right...
Not with javascript. Nonsense propagates like wildfire in this field.
  -- Richard Cornford, comp.lang.javascript, 2011-11-14

Back to comp.lang.javascript | Previous | Next — Previous in thread | Next in thread | Find similar | Unroll thread


Thread

Built-in native method Cezary Tomczyk <cezary.tomczyk@gmail.com> - 2012-10-19 22:07 +0200
  Re: Built-in native method JJ <jaejunks_at@_googlemail_dot._com> - 2012-10-21 06:44 +0000
    Re: Built-in native method Cezary Tomczyk <cezary.tomczyk@gmail.com> - 2012-10-21 18:46 +0200
    Re: Built-in native method Cezary Tomczyk <cezary.tomczyk@gmail.com> - 2012-10-21 19:37 +0200
      Re: Built-in native method Andreas Bergmaier <andber93@web.de> - 2012-10-22 15:47 +0200
        Re: Built-in native method Cezary Tomczyk <cezary.tomczyk@gmail.com> - 2012-10-22 18:00 +0200
          Re: Built-in native method Thomas 'PointedEars' Lahn <PointedEars@web.de> - 2012-10-24 02:17 +0100
            Re: Built-in native method Cezary Tomczyk <cezary.tomczyk@gmail.com> - 2012-10-24 22:17 +0200
              Re: Built-in native method Thomas 'PointedEars' Lahn <PointedEars@web.de> - 2012-10-25 00:32 +0200
  Re: Built-in native method Thomas 'PointedEars' Lahn <PointedEars@web.de> - 2012-10-24 02:15 +0100
    Re: Built-in native method Cezary Tomczyk <cezary.tomczyk@gmail.com> - 2012-10-24 22:35 +0200
      Re: Built-in native method Thomas 'PointedEars' Lahn <PointedEars@web.de> - 2012-10-25 00:03 +0200
        Re: Built-in native method Asen Bozhilov <asen.bozhilov@gmail.com> - 2012-10-26 03:58 -0700
          Re: Built-in native method RobG <rgqld@iinet.net.au> - 2012-10-29 16:39 -0700
        Re: Built-in native method Cezary Tomczyk <cezary.tomczyk@gmail.com> - 2012-10-28 15:32 +0100
          Re: Built-in native method Thomas 'PointedEars' Lahn <PointedEars@web.de> - 2012-10-28 17:05 +0100
            Re: Built-in native method Cezary Tomczyk <cezary.tomczyk@gmail.com> - 2012-10-28 18:39 +0100
              Re: Built-in native method Thomas 'PointedEars' Lahn <PointedEars@web.de> - 2012-10-28 20:10 +0100
                Re: Built-in native method Cezary Tomczyk <cezary.tomczyk@gmail.com> - 2012-10-28 20:23 +0100
                Re: Built-in native method Thomas 'PointedEars' Lahn <PointedEars@web.de> - 2012-10-28 21:23 +0100
                Re: Built-in native method Cezary Tomczyk <cezary.tomczyk@gmail.com> - 2012-10-28 22:03 +0100
        Re: Built-in native method Cezary Tomczyk <cezary.tomczyk@gmail.com> - 2012-10-28 15:49 +0100
          Re: Built-in native method Thomas 'PointedEars' Lahn <PointedEars@web.de> - 2012-10-28 17:12 +0100
            Re: Built-in native method Cezary Tomczyk <cezary.tomczyk@gmail.com> - 2012-10-28 17:49 +0100
              Re: Built-in native method Thomas 'PointedEars' Lahn <PointedEars@web.de> - 2012-10-28 18:07 +0100
                Re: Built-in native method Cezary Tomczyk <cezary.tomczyk@gmail.com> - 2012-10-28 19:22 +0100
                Re: Built-in native method Thomas 'PointedEars' Lahn <PointedEars@web.de> - 2012-10-28 19:53 +0100

csiph-web