473,322 Members | 1,345 Online
Bytes | Software Development & Data Engineering Community
Post Job

Home Posts Topics Members FAQ

Join Bytes to post your question to a community of 473,322 software developers and data experts.

Modify String.prototype?

The FAQ shows a mod to String.prototype adding trim, trimRight and
trimLeft.

Flanagan states, "There is a strong argument against extending built-
in types with your own methods; if you do so, you are essentially
creating your own version of the JavaScript API." And he goes on to
say that this will confuse other programmers who may need to maintain/
extend your code.

Flanagan also states, "You must <i>never</iadd properties to
Object.prototype." Anything added to Object.prototype adds enumerable
properties to every object, including {}. {} shouldn't have enumerable
properties, he says. However, Crockford breaks this rule regularly.

Best practice is?
Aug 28 '08 #1
15 2134
Ma************@gmail.com writes:
Flanagan also states, "You must <i>never</iadd properties to
Object.prototype." Anything added to Object.prototype adds enumerable
properties to every object, including {}. {} shouldn't have enumerable
properties, he says. However, Crockford breaks this rule regularly.
Examples? It's not just to show what not to do?
Best practice is?
Don't.

/L
--
Lasse Reichstein Nielsen
DHTML Death Colors: <URL:http://www.infimum.dk/HTML/rasterTriangleDOM.html>
'Faith without judgement merely degrades the spirit divine.'
Aug 28 '08 #2
Lasse Reichstein Nielsen wrote:
Examples? It's not just to show what not to do?
"In Chapter 3 we saw that Object.prototype can be augmented.
Array.prototype can be augmented as well." p. 62

Chapter 3 example: beget() method that uses one object to create
another object (of the same "class").
Aug 28 '08 #3
Ma************@gmail.com wrote:
The FAQ shows a mod to String.prototype adding trim, trimRight and
trimLeft.
It should instead provide these as functions for the reasons provided by
Flanagan.
Flanagan states, "There is a strong argument against extending built-
in types with your own methods; if you do so, you are essentially
creating your own version of the JavaScript API." And he goes on to
say that this will confuse other programmers who may need to maintain/
extend your code.
We need an FAQ maintainer.
Flanagan also states, "You must <i>never</iadd properties to
Object.prototype." Anything added to Object.prototype adds enumerable
properties to every object, including {}. {} shouldn't have enumerable
No disagreement there.
properties, he says. However, Crockford breaks this rule regularly.
Yes, he does.
Best practice is?
One place to modify built-ins is for adding support for features that
are feature-tested as buggy or missing.
Aug 28 '08 #4
Ma************@gmail.com wrote:
Lasse Reichstein Nielsen wrote:
>Examples? It's not just to show what not to do?

"In Chapter 3 we saw that Object.prototype can be augmented.
Array.prototype can be augmented as well." p. 62

Chapter 3 example: beget() method that uses one object to create
another object (of the same "class").
He has a way of getting around this with:-

for(var p in o) {
if(typeof o[p] !== "function") {

}
}

This will have filter out functions that have been added to
Object.prototype.

Modifying Object.prototype has some drawbacks. It requires other users
of API to use a non-standard technique, it will have different
Object.prototype in different frames. Changing what Object.prototype has
creates a dependency on the change and a relationship, so that all
objects now have that functionality.

A cleaner design approach is to resist the temptation to bugger
Object.prototype and create your own object type (or function) to
accomplish the task.

Garrett
Aug 28 '08 #5
Ma************@gmail.com writes:
The FAQ shows a mod to String.prototype adding trim, trimRight and
trimLeft.

Flanagan states, "There is a strong argument against extending built-
in types with your own methods; if you do so, you are essentially
creating your own version of the JavaScript API."
This is IMHO essentially correct. The real question is how strong this
argument really is.
And he goes on to say that this will confuse other programmers who
may need to maintain/ extend your code.
I'd say that it *might* confuse other programmers. It also might
provide a lot of useful features for programmers not so easily
confused.
Flanagan also states, "You must <i>never</iadd properties to
Object.prototype." Anything added to Object.prototype adds enumerable
properties to every object, including {}. {} shouldn't have enumerable
properties, he says.
I disagree. IMO, the main reason not to extend the built-in types and
especially Object is that it "breaks"

my o = { ... }
for (var p in o) {
// LOOP
}

in situations where programmers expect LOOP to only iterate over the
immediate properies (excluding the inherited properies) of o. In other
words; when you're using other people's code that may not expect this
behaviour.

This is exactly why Object.prototype.hasOwnProperty() exists, and
personally I think extending Object.prototype is just much too useful
to ignore.
However, Crockford breaks this rule regularly.
Crockford is not Flanagan.
Best practice is?
I don't know what best practices are. Do whatever you want, but be
careful.

--
Joost Diepenmaat | blog: http://joost.zeekat.nl/ | work: http://zeekat.nl/
Aug 28 '08 #6
Joost Diepenmaat wrote:
Ma************@gmail.com writes:
>The FAQ shows a mod to String.prototype adding trim,
trimRight and trimLeft.

Flanagan states, "There is a strong argument against extending
built- in types with your own methods; if you do so, you are
essentially creating your own version of the JavaScript API."

This is IMHO essentially correct. The real question is how strong
this argument really is.
Flanagan has a confused notion of what "the javascript API" is to start
with; his book(s) still talk of "client-side" javascript long after that
concept has been abandoned. It would also be trivial to assert that the
creation of any global function was creating your own version of "the
javascript API", or that the purpose of exposing the built-in object
prototypes was so that they could be modified, and so modifying them
cannot be inherently wrong and should not be unexpected.
>And he goes on to say that this will confuse other programmers
who may need to maintain/ extend your code.

I'd say that it *might* confuse other programmers.
With the likelihood of its confusing other 'programmers' having a
relationship to how well they understand the nature of javascript. Where
a poor grasp of the subject is likely to result in very much else also
being confusing.
It also might provide a lot of useful features for programmers
not so easily confused.
>Flanagan also states, "You must <i>never</iadd properties
to Object.prototype." Anything added to Object.prototype adds
enumerable properties to every object, including {}. {}
shouldn't have enumerable properties, he says.

I disagree. IMO, the main reason not to extend the built-in
types and especially Object is that it "breaks"

my o = { ... }
for (var p in o) {
// LOOP
}

in situations where programmers expect LOOP to only iterate
over the immediate properies (excluding the inherited properies)
of o. In other words; when you're using other people's code
that may not expect this behaviour.

This is exactly why Object.prototype.hasOwnProperty() exists,
and personally I think extending Object.prototype is just much
too useful to ignore.
>However, Crockford breaks this rule regularly.

Crockford is not Flanagan.
>Best practice is?

I don't know what best practices are. Do whatever you want, but
be careful.
It is very hard to see extending the prototypes for String, Number,
Boolean or Function as particularly problematic or undesirable. None of
those are likely to be subject to for-in iteration.

The real best practice is probably to take responsibility for what you
are doing an asses the trade-offs and their impacts. The issues mostly
come where there isn't the control to allow accurate judgements to be
made about the impact (i.e. in general purpose library code) where
caution is then advised, otherwise documentation stating the situation
within any given context (either that prototype extensions have been
used and for for-in needs to be handled cautiously, or that for-in has
been used incautiously on particular types so prototypes must not be
extended).

Richard.

Aug 29 '08 #7
On Aug 29, 3:16*am, "Richard Cornford" <Rich...@litotes.demon.co.uk>
wrote:
>
It is very hard to see extending the prototypes for String, Number,
Boolean or Function as particularly problematic or undesirable.
But try to avoid method names such as .clone() or .create()
or .defineProperty().

Use instead names as .myVeryOwnCloner() that are likely not to be ever
chosen to extend the language, when/if it gets ~"officially" extended.

--Jorge.
Aug 29 '08 #8
Ma************@gmail.com meinte:
The FAQ shows a mod to String.prototype adding trim, trimRight and
trimLeft.

Flanagan states, "There is a strong argument against extending built-
in types with your own methods;
I always thought, that's why you have the prototype chain, and the
opportunity to modify the prototype.
if you do so, you are essentially
creating your own version of the JavaScript API."
Doesn't compute.
And he goes on to
say that this will confuse other programmers who may need to maintain/
extend your code.
There are many more things that can confuse other programmers. Poor
documentation, convoluted scripts, odd method or property names ("$",
"$$", "_$",...), lambdas, etc. Augmented prototypes: not really.
Flanagan also states, "You must <i>never</iadd properties to
Object.prototype." Anything added to Object.prototype adds enumerable
properties to every object, including {}. {} shouldn't have enumerable
properties, he says. However, Crockford breaks this rule regularly.
Since you have hasOwnProperty() and advisably use it whenever you loop
with for ... in, I don't see the problem. But then I'm probably just a
staunch Crockford fan.
Best practice is?
Dunno. I use augmented prototypes and I happy with that. You could
always use a very special prefix for your extensions, to make it as
unique as possible (though I don't).

Gregor
--
http://photo.gregorkofler.at ::: Landschafts- und Reisefotografie
http://web.gregorkofler.com ::: meine JS-Spielwiese
http://www.image2d.com ::: Bildagentur für den alpinen Raum
Aug 29 '08 #9
Jorge wrote:
"Richard Cornford" wrote:
>It is very hard to see extending the prototypes for String, Number,
Boolean or Function as particularly problematic or undesirable.

But try to avoid method names such as .clone() or .create()
or .defineProperty().

Use instead names as .myVeryOwnCloner() that are likely not to be ever
chosen to extend the language, when/if it gets ~"officially" extended.
Your rationale, if it can be even called so, is unsound at best. Keywords
MUST be and future keywords SHOULD be avoided for identifiers; anything else
is just FUD.
PointedEars
--
realism: HTML 4.01 Strict
evangelism: XHTML 1.0 Strict
madness: XHTML 1.1 as application/xhtml+xml
-- Bjoern Hoehrmann
Aug 31 '08 #10
Gregor Kofler wrote:
Ma************@gmail.com meinte:
>Flanagan also states, "You must <i>never</iadd properties to
Object.prototype." Anything added to Object.prototype adds enumerable
properties to every object, including {}. {} shouldn't have enumerable
properties, he says. However, Crockford breaks this rule regularly.

Since you have hasOwnProperty() and advisably use it whenever you loop
with for ... in, I don't see the problem. But then I'm probably just a
staunch Crockford fan.
As for Object.prototype.hasOwnProperty(), it should be noted that it is not
universally available, so augmenting Object.prototype carries with it the
necessity either to provide a method that is equivalent, or to accept that
the library will not be backwards-compatible (to JavaScript < 1.5, JScript <
5.5, ECMAScript < 3). Therefore, I have refactored library code that was
doing it.

However, I, too, see no problem augmenting prototype objects of objects that
are not likely to be subject to for-in iteration (such as String.prototype).
And a good library would provide an iterator method that helped its users
to work around the issue (mine does, in its local version).
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, <f8*******************@news.demon.co.uk>
Aug 31 '08 #11
On Aug 29, 3:38*am, Jeremy J Starcher <r3...@yahoo.comwrote:
On Thu, 28 Aug 2008 08:23:09 -0700, MartinRinehart wrote:
[...]
Flanagan also states, "You must <i>never</iadd properties to
Object.prototype." Anything added to Object.prototype adds enumerable
properties to every object, including {}. {} shouldn't have enumerable
properties, he says. However, Crockford breaks this rule regularly.

I have never read Flanagan's book, but I have heard some rather negative
reviews about it on this group.
There have been negative comments about some of the things in it,
however it is still a good general reference provided you take its
advice with a grain of salt and do additional research.
--
Rob
Aug 31 '08 #12
On Sep 1, 12:56*am, Thomas 'PointedEars' Lahn <PointedE...@web.de>
wrote:
Jorge wrote:
try to avoid method names such as .clone() or .create()
or .defineProperty().
Use instead names as .myVeryOwnCloner() that are likely not to be ever
chosen to extend the language, when/if it gets ~"officially" extended.

Your rationale, if it can be even called so, is unsound at best. *Keywords
MUST be and future keywords SHOULD be avoided for identifiers; anything else
is just FUD.
clap clap clap clap, BRAVO !

And how ** do you ** avoid using future keywords in the code written
by yours truly ?

--
Jorge.
Sep 1 '08 #13
Jorge wrote:
On Sep 1, 12:56 am, Thomas 'PointedEars' Lahn <PointedE...@web.de>
wrote:
>Jorge wrote:
>>try to avoid method names such as .clone() or .create()
or .defineProperty().
>>Use instead names as .myVeryOwnCloner() that are likely not to be
ever chosen to extend the language, when/if it gets ~"officially"
extended.

Your rationale, if it can be even called so, is unsound at best.
Keywords MUST be and future keywords SHOULD be avoided for
identifiers; anything else is just FUD.

clap clap clap clap, BRAVO !

And how ** do you ** avoid using future keywords in the code written
by yours truly ?
After googling as a stupid newbie , complete idiot and fool, etc, I found
FUD = female urination device.

So I think you can avoid future keywords with it: you simply put your
keys to the device and urinate, I think. If somebody knows better, pls
correct me.
Sep 1 '08 #14
On Sun, 31 Aug 2008 at 20:15:43, in comp.lang.javascript, Jorge wrote:
>On Sep 1, 12:56*am, Thomas 'PointedEars' Lahn <PointedE...@web.de>
wrote:
>Jorge wrote:
try to avoid method names such as .clone() or .create()
or .defineProperty().
Use instead names as .myVeryOwnCloner() that are likely not to be ever
chosen to extend the language, when/if it gets ~"officially" extended.

Your rationale, if it can be even called so, is unsound at best. *Keywords
MUST be and future keywords SHOULD be avoided for identifiers; anything else
is just FUD.

clap clap clap clap, BRAVO !

And how ** do you ** avoid using future keywords in the code written
by yours truly ?
Here's an extract from the ECMAScript standard :

7.5.1 Reserved Words
Description
Reserved words cannot be used as identifiers.

Syntax
ReservedWord ::
Keyword
FutureReservedWord
NullLiteral
BooleanLiteral

...

7.5.3 Future Reserved Words
The following words are used as keywords in proposed extensions and
are therefore reserved to allow for the possibility of future
adoption of those extensions.

[Followed by a list of words such as class and static]

So the answer to your question is very simple. You look in ECMA 262 or
equivalent to see which words might be keywords in the future.

Also, it's not that they "should" be avoided; they "must" be avoided.

John
--
John Harris
Sep 1 '08 #15
On Sep 1, 8:20*pm, John G Harris <j...@nospam.demon.co.ukwrote:
On Sun, 31 Aug 2008 at 20:15:43, in comp.lang.javascript, Jorge wrote:
On Sep 1, 12:56*am, Thomas 'PointedEars' Lahn <PointedE...@web.de>
wrote:
Jorge wrote:
try to avoid method names such as .clone() or .create()
or .defineProperty().
Use instead names as .myVeryOwnCloner() that are likely not to be ever
chosen to extend the language, when/if it gets ~"officially" extended.
Your rationale, if it can be even called so, is unsound at best. *Keywords
MUST be and future keywords SHOULD be avoided for identifiers; anything else
is just FUD.
clap clap clap clap, BRAVO !
And how ** do you ** avoid using future keywords in the code written
by yours truly ?

Here's an extract from the ECMAScript standard :

* 7.5.1 Reserved Words
* * Description
* * Reserved words cannot be used as identifiers.

* Syntax
* ReservedWord ::
* * Keyword
* * FutureReservedWord
* * NullLiteral
* * BooleanLiteral

* ...

* 7.5.3 Future Reserved Words
* * The following words are used as keywords in proposed extensions and
* * are therefore reserved to allow for the possibility of future
* * adoption of those extensions.

[Followed by a list of words such as class and static]

So the answer to your question is very simple. You look in ECMA 262 or
equivalent to see which words might be keywords in the future.

Also, it's not that they "should" be avoided; they "must" be avoided.
Yes, but the (future) 3.1 extensions may not be in that list. What
happens with them ?
Will current code collide with 3.1 extensions, or will it just shadow
them ?
An Object.prototype.clone() method for example ?

--
Jorge.
Sep 2 '08 #16

This thread has been closed and replies have been disabled. Please start a new discussion.

Similar topics

3
by: Pavils Jurjans | last post by:
Hallo, Is there some decent way how to get the object class name in a string format? Currently I use this: function getClassName(obj) { if (typeof obj != "object" || obj === null) return...
24
by: Wim Roffal | last post by:
Is there a possibility to do a string replace in javascript without regular experessions. It feels like using a hammer to crash an egg. Wim
8
by: Grant Wagner | last post by:
I'm a bit confused by String() (typeof 'string') vs new String() (typeof 'object'). When you need to access a method or property of a -String-, what type is JavaScript expecting (or rather, what...
13
by: baumann.Pan | last post by:
when define char *p = " can not modify"; p ='b' ;is not allowed, but if you declare p as char p = "can modify"; p = 'b'; is ok? why?
11
by: tlyczko | last post by:
Hello Rob B posted this wonderful code in another thread, http://groups.google.com/group/comp.lang.javascript/browse_thread/thread/c84d8538025980dd/6ead9d5e61be85f0#6ead9d5e61be85f0 I could not...
4
by: jemptymethod | last post by:
http://htmatters.net/htm/1/2006/01/EIBTI-for-Javascript-explicit-is-better-than-implicit.cfm
21
by: gary | last post by:
How would one make the ECMA-262 String.replace method work with a string literal? For example, if my string was "HELLO" how would I make it work in this instance. Please note my square...
20
by: Xcriber51 | last post by:
Hi -- I'm not entirely familiar with the norms and standard libraries of JavaScript so if the answer to this is yesterday's news, please ignore. I'm trying to write a simple text formatting...
3
by: szimek | last post by:
Hi! Like many others before recently I've found out that firstChild works little bit differently in IE and other browsers. I've got huge app that is currently IE only and used firstChild all...
0
by: ryjfgjl | last post by:
ExcelToDatabase: batch import excel into database automatically...
0
isladogs
by: isladogs | last post by:
The next Access Europe meeting will be on Wednesday 6 Mar 2024 starting at 18:00 UK time (6PM UTC) and finishing at about 19:15 (7.15PM). In this month's session, we are pleased to welcome back...
0
by: Vimpel783 | last post by:
Hello! Guys, I found this code on the Internet, but I need to modify it a little. It works well, the problem is this: Data is sent from only one cell, in this case B5, but it is necessary that data...
0
by: jfyes | last post by:
As a hardware engineer, after seeing that CEIWEI recently released a new tool for Modbus RTU Over TCP/UDP filtering and monitoring, I actively went to its official website to take a look. It turned...
0
by: ArrayDB | last post by:
The error message I've encountered is; ERROR:root:Error generating model response: exception: access violation writing 0x0000000000005140, which seems to be indicative of an access violation...
1
by: PapaRatzi | last post by:
Hello, I am teaching myself MS Access forms design and Visual Basic. I've created a table to capture a list of Top 30 singles and forms to capture new entries. The final step is a form (unbound)...
1
by: Defcon1945 | last post by:
I'm trying to learn Python using Pycharm but import shutil doesn't work
1
by: Shællîpôpï 09 | last post by:
If u are using a keypad phone, how do u turn on JavaScript, to access features like WhatsApp, Facebook, Instagram....
0
isladogs
by: isladogs | last post by:
The next Access Europe User Group meeting will be on Wednesday 3 Apr 2024 starting at 18:00 UK time (6PM UTC+1) and finishing by 19:30 (7.30PM). In this session, we are pleased to welcome former...

By using Bytes.com and it's services, you agree to our Privacy Policy and Terms of Use.

To disable or enable advertisements and analytics tracking please visit the manage ads & tracking page.