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

Groups > comp.lang.javascript > #16740 > unrolled thread

Built-in native method

Back to article view | Back to comp.lang.javascript

Contents

  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

Page 2 of 2 — ← Prev page 1 [2]

#16936

W dniu 2012-10-28 21:23, Thomas 'PointedEars' Lahn pisze:
> Cezary Tomczyk wrote:
>
>> W dniu 2012-10-28 20:10, Thomas 'PointedEars' Lahn pisze:
>>> Cezary Tomczyk wrote:
>>>> 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.
>>>
>>> 1. You are benchmarking the wrong feature there.
>>
>> Ok, maybe I should do two separate tests.
>
> You wanted to test `==' vs. `==='.  What you are actually testing there is
> `typeof ""' vs. `typeof {}'.  Keep in mind that the `typeof' operation
> *always* results in a string value.

OMG, you have absolutely right. What I was thinking about during 
creating those tests, I don't know :-)

Ok, now should be better:
http://jsperf.com/three-double-equal

And the name of this test should not contains "typeof" word any more.

>>> 2. I do not think you need loops with jsperf.
>>
>> Is there better way?
>
> Yes, omit them.  jsperf loops by itself, and if it is any good it uses
> nested loops.

I removed loops. Thanks for tip.

>>> 3. Never trust benchmarks.
>>
>> Then one of the alternative is to measure time by using new
>> Date().getTime() :/
>
> No, the reasonable alternative is to profile real code under real conditions
> if and when slow speed becomes a problem.  A V8 JavaScript profiler is
> included in the Chromium/Chrome Developer Tools; Firebug contains one for
> SpiderMonkey as well.  Premature optimization is the root of all evil. [tm]

Using "profiler" that's probably the best way. As for "Premature 
optimization" generally speaking I agree, but first of all "Premature 
optimization" must be somehow defined, because every developer 
understand it in a very different way. Let's say that this is just a 
different topic.

> The issue of `==' vs. `===' is not so much speed; it is the outcome of
> either operation, which can be unexpected in the former case.

Test results, even if it comes from jsperf, showing that mostly === is 
faster around from 70% up to 100% than ==.

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

[toc] | [prev] | [next] | [standalone]

#16922

W dniu 2012-10-25 00:03, Thomas 'PointedEars' Lahn pisze:
[...]
>    if (String.prototype.propertyIsEnumerable("trim"))

Quick results from Google Chrome 22.0.1229.94 console.

String.prototype.propertyIsEnumerable("trim")
false
String(String.prototype.trim);
"function trim() { [native code] }"
String.prototype.trim = function(){ alert('test'); return false; };
function (){ alert('test'); return false; }
String.prototype.trim
function (){ alert('test'); return false; }
String(String.prototype.trim);
"function (){ alert('test'); return false; }"
String.prototype.propertyIsEnumerable("trim")
false

In both of cases means that object can not be enumerated by a for[...]in 
loop. And as I understand it correctly this doesn't help with determine 
if method is really built-in or not. Or maybe I missed something? Hm...

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

[toc] | [prev] | [next] | [standalone]

#16924

Cezary Tomczyk wrote:

> W dniu 2012-10-25 00:03, Thomas 'PointedEars' Lahn pisze:
> [...]
>>    if (String.prototype.propertyIsEnumerable("trim"))
> 
> Quick results from Google Chrome 22.0.1229.94 console.

Unreadable.  What is your input, what V8's output?  Which OS and platform?
 
> In both of cases means that object can not be enumerated by a for[...]in
> loop. And as I understand it correctly this doesn't help with determine
> if method is really built-in or not.

Possible; whether property attributes are retained is implementation-
dependent.  But now that you know that *you* can overwrite 
String.prototype.trim(), a solution to your problem should present itself.

> Or maybe I missed something? Hm...

Equally possible. 


PointedEars
-- 
Sometimes, what you learn is wrong. If those wrong ideas are close to the 
root of the knowledge tree you build on a particular subject, pruning the 
bad branches can sometimes cause the whole tree to collapse.
  -- Mike Duffy in cljs, <news:Xns9FB6521286DB8invalidcom@94.75.214.39>

[toc] | [prev] | [next] | [standalone]

#16925

W dniu 2012-10-28 17:12, Thomas 'PointedEars' Lahn pisze:
> Cezary Tomczyk wrote:
>
>> W dniu 2012-10-25 00:03, Thomas 'PointedEars' Lahn pisze:
>> [...]
>>>     if (String.prototype.propertyIsEnumerable("trim"))
>>
>> Quick results from Google Chrome 22.0.1229.94 console.
>
> Unreadable.  What is your input, what V8's output?  Which OS and platform?

OS: Windows 7
Platform: Win32

Let me do in that way:

ID - Input data in Google Chrome console
R - result in console

ID:   String.prototype.propertyIsEnumerable("trim")
R:    false

ID:   String(String.prototype.trim);
R:    "function trim() { [native code] }"

ID:   String.prototype.trim = function(){ alert('test'); return false; };
R:    function (){ alert('test'); return false; }

ID:   String.prototype.trim
R:    function (){ alert('test'); return false; }

ID:   String(String.prototype.trim);
R:    "function (){ alert('test'); return false; }"

ID:   String.prototype.propertyIsEnumerable("trim")
R:    false

Better?

>> In both of cases means that object can not be enumerated by a for[...]in
>> loop. And as I understand it correctly this doesn't help with determine
>> if method is really built-in or not.
>
> Possible; whether property attributes are retained is implementation-
> dependent.  But now that you know that *you* can overwrite
> String.prototype.trim(), a solution to your problem should present itself.

Oh, well. Yes, I can overwrite. This is always possible. Then there is 
only hope that 3-rd party external library will correctly parse results 
from my custom method. But this is easy to verify, I know.

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

[toc] | [prev] | [next] | [standalone]

#16926

Cezary Tomczyk wrote:

> W dniu 2012-10-28 17:12, Thomas 'PointedEars' Lahn pisze:
>> Cezary Tomczyk wrote:
>>> W dniu 2012-10-25 00:03, Thomas 'PointedEars' Lahn pisze:
>>> [...]
>>>>     if (String.prototype.propertyIsEnumerable("trim"))
>>> Quick results from Google Chrome 22.0.1229.94 console.
>> Unreadable.  What is your input, what V8's output?  Which OS and
>> platform?
> 
> OS: Windows 7
> Platform: Win32

I would consider "Windows 7 32-bit" the OS then and "Intel x86 or 
compatibles" the (hardware) platform, but I know what you mean.
 
> Let me do in that way:
> 
> ID - Input data in Google Chrome console
> R - result in console
> 
> ID:   String.prototype.propertyIsEnumerable("trim")
> R:    false
> 
> ID:   String(String.prototype.trim);
> R:    "function trim() { [native code] }"
> 
> ID:   String.prototype.trim = function(){ alert('test'); return false; };
> R:    function (){ alert('test'); return false; }
> 
> ID:   String.prototype.trim
> R:    function (){ alert('test'); return false; }
> 
> ID:   String(String.prototype.trim);
> R:    "function (){ alert('test'); return false; }"

JFYI: In the Chromium/Chrome console a type conversion to String so far is 
implicit for Function instances.
 
> ID:   String.prototype.propertyIsEnumerable("trim")
> R:    false
> 
> Better?

Yes; the same applies to Object.prototype.toString, and probably other 
built-in methods with V8.  Actually, retaining the property attributes is 
required for a conforming implementation per ES 5.1, §8.12.5.  I should set 
up a test case as part of the ES Matrix.


PointedEars
-- 
Use any version of Microsoft Frontpage to create your site.
(This won't prevent people from viewing your source, but no one
will want to steal it.)
  -- from <http://www.vortex-webdesign.com/help/hidesource.htm> (404-comp.)

[toc] | [prev] | [next] | [standalone]

#16929

W dniu 2012-10-28 18:07, Thomas 'PointedEars' Lahn pisze:
> Cezary Tomczyk wrote:
>
>> W dniu 2012-10-28 17:12, Thomas 'PointedEars' Lahn pisze:
>>> Cezary Tomczyk wrote:
>>>> W dniu 2012-10-25 00:03, Thomas 'PointedEars' Lahn pisze:
>>>> [...]
>>>>>      if (String.prototype.propertyIsEnumerable("trim"))
>>>> Quick results from Google Chrome 22.0.1229.94 console.
>>> Unreadable.  What is your input, what V8's output?  Which OS and
>>> platform?
>>
>> OS: Windows 7
>> Platform: Win32
>
> I would consider "Windows 7 32-bit" the OS then and "Intel x86 or
> compatibles" the (hardware) platform, but I know what you mean.

Argh, my mistake. I've got platform from browser 
window.navigator.platform which is not really true. I have a Windows 7 
64-bit and "Intel x86 or compatibles".

>> Let me do in that way:
>>
>> ID - Input data in Google Chrome console
>> R - result in console
>>
>> ID:   String.prototype.propertyIsEnumerable("trim")
>> R:    false
>>
>> ID:   String(String.prototype.trim);
>> R:    "function trim() { [native code] }"
>>
>> ID:   String.prototype.trim = function(){ alert('test'); return false; };
>> R:    function (){ alert('test'); return false; }
>>
>> ID:   String.prototype.trim
>> R:    function (){ alert('test'); return false; }
>>
>> ID:   String(String.prototype.trim);
>> R:    "function (){ alert('test'); return false; }"
>
> JFYI: In the Chromium/Chrome console a type conversion to String so far is
> implicit for Function instances.

A, there is no differences when I type in console:

String(String.prototype.trim);
and
String.prototype.trim

because they are always converted to string. Right?

[...]I should set
> up a test case as part of the ES Matrix.

When will be free time :-)

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

[toc] | [prev] | [next] | [standalone]

#16930

Cezary Tomczyk wrote:

> W dniu 2012-10-28 18:07, Thomas 'PointedEars' Lahn pisze:
>> Cezary Tomczyk wrote:
>>> ID:   String.prototype.trim = function(){ alert('test'); return false;
>>> };
>>> R:    function (){ alert('test'); return false; }
>>>
>>> ID:   String.prototype.trim
>>> R:    function (){ alert('test'); return false; }
>>>
>>> ID:   String(String.prototype.trim);
>>> R:    "function (){ alert('test'); return false; }"
>>
>> JFYI: In the Chromium/Chrome console a type conversion to String so far
>> is implicit for Function instances.
> 
> A, there is no differences when I type in console:
> 
> String(String.prototype.trim);
> and
> String.prototype.trim

There is a difference: the double-quotes.  That aside,
 
> because they are always converted to string. Right?

you are correct.
 

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$8300dec7@news.demon.co.uk>

[toc] | [prev] | [standalone]

Page 2 of 2 — ← Prev page 1 [2]

Back to top | Article view | comp.lang.javascript

csiph-web