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

Groups > comp.lang.javascript > #16923

Re: Built-in native method

Followups directed to: comp.lang.javascript

Show all headers | View raw

Cezary Tomczyk wrote:

> W dniu 2012-10-25 00:03, Thomas 'PointedEars' Lahn pisze:
>> Cezary Tomczyk wrote:
>>> 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.
>>
>> What are you getting at?  I do not use junk libraries, I strongly
>> recommend against them at every opportunity, and I explain why; and I am
>> working on better ones for everybody (including me) to use freely and for
>> free, and to contribute to them.
> 
> It's not about me. I just can't change it.

Yes, you can.
 
>>>> 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.
>>
>> A developer who does not know how to do it right has failed at their job.
> 
> You never make mistakes? I don't believe in it.

Everybody makes mistakes; we can learn from them to make it better next 
time.  But making mistakes because of overlooking some detail, and making 
mistakes because one does not know what they are doing in the first place, 
are very different things.  You *know* now that you have made a mistake by 
either participating in a bad project, using a bad library, or both; not 
correcting it now would be yet another mistake on your part.
 
>>>>     if (typeof foo.whatever != "function")
>>>
>>> I would use !== here. Its slightly faster than != because there is no
>>> type conversion.
>>
>> Nonsense.  `typeof' yields a result of type String.
> 
> That's weird for me. I thought that === will be much faster than ==
> because there is no internal type conversion.

This should be self-evident: There is no type conversion when both operands 
are of the same type.  See also ES 5.1, §11.9.

> I created the test:
> 
> http://jsperf.com/typeof-equals-triple-double
> 
> and its seems that == is even sometimes faster. But it depends on browser.
> 
> However, JSHint report me that I need replace every == by === because
> settings in JSHint require always ===.

Delete JSHint.

> I wonder why this is required in our project by other developers?

I do not know.  Perhaps because they cannot deal with type conversion as 
they are used to statically and strictly typed languages?  Very few people 
actually understand these languages and their applications, which accounts 
for a lot of bad code written in them.

> Correct me if I'm wrong, but if we know what type of object will be then
> there is no need to use ===, right?

No, it depends on the operands, and it depends on whether the operands are 
object (reference)s to begin with.  Neither a `typeof' operation nor 
evaluating a string literal results in an object (reference).

>>>>     {
>>>>       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
>>
>> That is only the documentation of one implementation.  Refer to the
>> Specification first.
> 
> You mean this one:
> http://ecma-international.org/ecma-262/5.1/#sec-15.5.4.20 ?

Yes.
 
>>>>> 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. :-)
>>
>>    String.prototype.trim = 42;
>>
>>    if (String.prototype.trim)
>>    {
>>      /* TypeError */
>>      "foo".trim();
>>    }
> 
> That's possible. Then we should here check if String.prototype.trim is a
> function, right?

Yes.  The call may still fail in some cases, but you would have done your 
best to prevent it.  This is what defensive coding is about.
 
> However, as for question "why I need to check it?". Reason is simple:
> library, which is included in project, have a few methods (not only
> "trim") that are very badly implemented. Trim is just one of them.

So, assuming you are a responsible developer and a responsible person in 
general, you should ask yourself: Why is this project using bad code now?  
And why do you want to keep on using bad code in your project?  Does that 
not inevitably make *your* (project's) code bad code as well?  Consider the 
repercussions of (your) design decisions.
 
> What I want to get? I want to use built-in trim method only if it is
> really built-in or use my custom trim method. Because trim that coming
> from external library (by extending native built-in object String) is
> badly implemented.

I have already told you what your options are at this point:

A. You can stop using that library (and perhaps use a better one);
B. You can fix the library;
C. You can demand a fix from its author(s).

I do not think there are other options.

-- 
PointedEars

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