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

Groups > comp.lang.javascript > #16927

Re: Built-in native method

Show key headers only | View raw

W dniu 2012-10-28 17:05, Thomas 'PointedEars' Lahn pisze:
> Cezary Tomczyk wrote:

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

That's why in my job I always asking other developers: "why did you do 
in that way?". If developer can explain in a clear way, I mean in that 
way I can understand, will provide me real example as a evidence and 
eventually source of algorithm (or idea) then working in that way for me 
is best optimized.

> either participating in a bad project, using a bad library, or both; not
> correcting it now would be yet another mistake on your part.

Well, then there is at least few options:

1. Try to find the right people for change.
2. Accept the situation as it is and try to create a solution that will 
protect against errors of others.
3. Change project.
4. Build own project.

>>>>>      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 even extended little bit this test 
http://jsperf.com/typeof-equals-triple-double by comparing two different 
objects and IE9, Google Chrome 22.0.1229.94, Opera 12.02 for 4 tests are 
more or less similar, but Firefox 16.0.2 surprised me little bit:

triple equals: 8167 Ops/sec
double equals: 4752 Ops/sec
triple equals - different objects: 90830 Ops/sec
double equals - different objects: 89815 Ops/sec

All of them tested on Windows 7, 64 bit.

What a huge difference. Weird for me, little bit.

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

Not all options are bad, I would say. Sometimes it prevent from a small, 
but very important bugs.

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

I thought about situation where both of operands are the same type.

I've just reviewed my bookmarks and see nice article: 
http://dmitrysoshnikov.com/notes/note-2-ecmascript-equality-operators/#safe-cases-of-codecode.

"The main thing which you should know that algorithms of == and === 
operator are completely equivalent, word-for-word, if types of operands 
are the same."

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

It's not my decision. It is required by project on which I'm co-working 
now. This project depend on 3-rd parties. Anyway, I've got your point, I 
understand and even know what consequences will be in the future, but 
let's no talk about situations that I cannot change.

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

For now I must work with option B (by wrapping bad methods with my 
custom methods as a temporary workaround) and count on fixes from point C.

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