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

Groups > comp.lang.javascript > #16840

Re: Built-in native method

Show all headers | View raw

W dniu 2012-10-24 03:15, Thomas 'PointedEars' Lahn pisze:
> 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

Sometimes it is just impossible. And especially you should know about that.

> 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.

Generally speaking I agree. However, I don't why they wrote many methods 
in a wrong way. I can't relay on their methods and that's why I just 
wanted to check if method is really native method. There is no perfect 
solution.

> 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:

Yes, but only on one condition: if developer know how to do it in right way.

>    if (typeof foo.whatever != "function")

I would use !== here. Its slightly faster than != because there is no 
type conversion.

>    {
>      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.

But if foo.whatever is defined then I'm not sure if this foo.whatever 
working as expected. I mean, as defined in documentation. For example: 
https://developer.mozilla.org/en-US/docs/JavaScript/Reference/Global_Objects/String/Trim

Maybe its good to write here small unit test and try to check what is 
the result from method foo.whatever. Then I can be sure if the method 
working well or not.

Am I correct?

> 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'.

As usually, delivering full explanation. :-)

>> 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.

I don't know better way to check if method is really built-in.

> 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) { … }");
>    }

I think its not about if property (value) is callable. Even, if property 
is callable this means only that property (value) is... callable. There 
is no guarantee that property (value) will return the correct result. Right?

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

I know this table.

> PointedEars

-- 
Cezary Tomczyk
http://www.ctomczyk.pl/

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