Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]
Groups > comp.lang.javascript > #16829
| 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
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
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