Code Guidelines

[Dmitry A. Soshnikov]

On Jan 1, 8:43 pm, "Dmitry A. Soshnikov" <[email protected]>
wrote:

[snip]

Ok, I've "appreciated" this demagogy in this part of your answer

Sorry, Garrett I didn't see a half of your answer because of "read
more >>" link (I didn't see it before here), so I thought you write
only "Of cause and ...". I'll read the full your answer and will add
some answer to mine previous. It wasn't your demagogy in this place,
apologize.

/ds

 

[Garrett Smith]

On Jan 1, 8:43 pm, "Dmitry A. Soshnikov" <[email protected]>
wrote:

[snip]

Ok, I've "appreciated" this demagogy in this part of your answer

Sorry, Garrett I didn't see a half of your answer because of "read
more >>" link (I didn't see it before here), so I thought you write
only "Of cause and ...". I'll read the full your answer and will add
some answer to mine previous. It wasn't your demagogy in this place,
apologize.

You're using Google Groups, then, I take it.

 

[Dmitry A. Soshnikov]

On Dec 31 2009, 11:23 pm, Garrett Smith <[email protected]>
wrote:

[snip]

Continue to answer from this point (as I've mentioned, I didn't see
that half of your answer because of "read more >> " link).

By "use", I believe you mean to describe code that is accessing the
`capitalize` method, and not code that exists where the script that
defines `capitalize` exists.

Yep, because (and I've already repeated not once) and
`String.prototype.capitalize' and `M.capitalize' can be defined in the
same exactly place (file) and used in the same exactly places.

Either way, I don't think it matters much. Once the API is published,
you don't get to decide who calls what. You can say: "I defined this
property, but don't use it," and if there is no value in using it, then
probably nobody will use it. If there is some value in using that
feature, then it has a better chance of being used. How would you know
who is using `capitalize`?

Either way, the method is globally accessible.

Yeah, and that's exactly I'm talking about, when telling that there's
no difference.

I think we are arguing the same point.

Yeah, I see that too.

That is, you don't know what may be defined tomorrow.

That public interface, is a property of global object, and so it could
be replaced by a simple assignment.

Anyone using that namespace could be expected to not redeclare that
namespace and to not use another piece of code that does.

YUI's YAHOO.namespace method fails on this account.

YAHOO.namespace fails because it adds user-defined properties to the
YAHOO object. Calling YAHOO.namespace("example") creates YAHOO.example,
if it does not exist alreay. YUI's namespace strategy makes it easy for
conflits to occur. Consider a client using YUI that wants to define
YAHOO.touchevent namespace. Will a future release of YUI have its own
YAHOO.touchevent object? YAHOO has no way to be certain that a client of
YAHOO had not followed YUI's advice and used
YAHOO.namespace("touchevent"). If YUI decides to use YAHOO.touchevent =
{}, then the namespace will be obliterated.

That's it.

String.prototype is a built-in. If it is to be called a "module", then
it is a built-in module. If you've modified it, then it is a built-in
module with a mix of user-defined properties.

Yeah, and I repeat, the main goal is about useful and elegant code
such as 'string'.capitalize() where `.capitalize' is put *logicaly*
there where it's place for it - in the strings "module/class". And
that's all about mostly when there's no some issues as 3rd-party libs
using.

If user-defined properties are defined, then where should these
definitions occur?

If the definition of user-defined additions to String.prototype is
defined in a author file that is defining another module, then the
author is defining two things in that file instead of one. So those
modifications should not occur in same author file as another module's code.

By "author file" I mean the file the author edits, not necessarily the
same file the http client receives.

The author file should be defining one thing only.

I don't see a big issue. What's the prob - user can define
`String.prototype's extension in separate file - then will be "one
file for one thing", where "thing" is "patching built-in with useful
methods for to write more useful code instead of
Ext.util.Format.something".

The only user-defined identifier that is ReadOnly is the Identfier for
FunctionExpression. And that doesn't work in JScript, as you probably know.

Yeah, thanks, be sure, I know (although, it's not about the topic).

By that fact, you are are right; any one library can replace APE.dom.

A conflict can occur when *one* external module or library also modifies
the property String.prototype.capitalize.

Yes, sure. Have you noted that we're talking mostly about issues with
3rd-party libs? Meanwhile, we've put this fact into the issues when
augmenting can be the issue in case when some lib will do the same.
But what I'm talking about - is mostly regardless all mentioned issues
- that it's not a bad practice, when you understand why you do so.
This will help to write more useful and elegant code. But sure, when
to augment with using 3rd-party libs - that's already "for own fear
and risk".

The point is to not do that; to not modify objects you don't own.

Instead, I am suggesting that methods exist as part of units or modules
and with an easily identifiable role.

This can be achieved by defining one global namespace and hanging
properties off that.

I understand that, and this structure is sure useful, but when
describing some methods that related to the strings - for what
additional module is needed? That "M" (and to write in one place
'string'.trim() and in other M.trimLeft(string))? For to know that
that's your extenstion but not a built-in? For do not make conflict
with the next Standard built-ins? Sure all of this clear, but when the
issue will be, then will find the solution. But for now we can write
more elegant and useful (and logically more correct in my opinion)
code such as 'string'.trimLeft().

If it is OK to modify String.prototype, is it okay for everyone to do
that, or just an internal organization?

Is it ok to modify objects you don't own in general? If so, are there
exceptions to that rule?

Good question. I think so: for exactly built-ins can be exceptions as
built-ins come from the beggining and every user (you or 3rd-library)
can do with them anything they want. So again, if you don't use some
3rd-party library, it can be useful to augment some built-in for to
write more useful and elegant code.

If you want to touch some object of 3rd-party (which you also can do -
to patch it) - you already do it for your own fear and risk. And here
can be useful to touch the properties which should appear in the next
releases (e.g. if you're using v.2 and know that in v.3 will be a
method doThat() - so you add your own implementations of doThat()). I
understand, that in case of built-ins can be exactly the same, but in
augmenting of both: built-ins or some 3rd-party library you may also
add your own patches regardless new versions - that which just useful
for you.

[...]

That just means - that ideologically it's normal to augment built-ins
if language is constructed so and if this fact is in it's ideology.

The language allowing something does not make that thing ideal. The
language makes assignment to identifier end up with globals. How many
times have you seen a missing - var - statement.

for(i - 0; i < 10; i++)

?

Well, yeah, and that's why I've told repeatedly that user should
understand what he is doing. If he does, he can use the system in a
full power, if not - can catch every time errors such as example
above.

One useful way to modify built-ins is to add the standard feature for
implementations that have not yet implemented it, or have implemented it
wrong, but preceeding that with a feature test, e.g.
if(!String.prototype.trim) ... .

Yep, sure, I've told above about that. But also, you may add your own
additional functionality regardless new versions (maybe such
functionality which will never be added by Standard or by some lib).

If the rule "don't modify objects you don't own", is followed, and the
only exception to that rule is to add a global property, then conflicts
should not occur.


I got that. I don't see a good reason for modifying objects you don't
own. I see a few downsides:-
1) increases potential conflict with
* new standard
* new version of 3rd party library
* code defined somewhere else in the organization

Yep, I've told about the issues.

2) Method presence doesn't provide indication where that method is
likely to be defined.

You mean if "M.foo.bar" means directory "M", subdirectory/file/module
"foo", method "bar" - you know where it is. And with
'string'.yourOwnMethod() you don't know where to search the definition
of the `yourOwnMethod'? I don't see that this a big issue. As variant
you can provide `built-ins-extensions.js' and do it there (or as
usually, some `core.js' or sort of and there sub routine for
initialize extensions of the built-ins).

So again, I'd like to say about my position: if do not touch all the
issues (main of which are: (a) Augmenting of the Object.prototype and
(b) using 3rd-party libs) - it can be useful in your own projects, and
you can write more clear, useful and elegant code (and that's all this
about, 'cause from functionality point of view, repeat, there's no any
difference where to put this code). But sure, if you do so with
regarding the described issues (especially using 3rd-party libs) - you
always do this for your own fear and risk.

/ds

 

[Dmitry A. Soshnikov]

On Jan 1, 8:43 pm, "Dmitry A. Soshnikov" <[email protected]>
wrote:

[snip]

Everything has
String.prototype, right?
Absolutely right.
Well, now if you modify that, then everything
has that modification.
Of cause
...
Ok, I've "appreciated" this demagogy in this part of your answer

Sorry, Garrett I didn't see a half of your answer because of "read
more >>" link (I didn't see it before here), so I thought you write
only "Of cause and ...". I'll read the full your answer and will add
some answer to mine previous. It wasn't your demagogy in this place,
apologize.

You're using Google Groups, then, I take it.

Yes I use Google Groups to see/answer. And what do you?

/ds

 

[John G Harris]

In comp.lang.javascript message <[email protected]
8924D9443D28E23ED5CD>, Wed, 30 Dec 2009 16:22:09, John G Harris


I think that you need to read what I wrote more slowly.

The proportion of people whose Web browsers and/or newsreaders are
routinely set up to have tab stops at other than 8N+1 must be
negligible.

The number of people using a browser or news reader to edit code is even
more negligible.

Remember :
the most important reader must be the writer,

No, the most important reader is the poor unfortunate who has the job of
updating or correcting the code, especially when they are not the
original author.

the code as written is not necessarily the code as transmitted.

John

 

[Garrett Smith]

Dmitry A. Soshnikov wrote:
Dmitry A. Soshnikov wrote:
[snip]
A public library that modifies
the built-ins can't really be trusted to work with other code.

[snip]

Let me again to mention the real dependency (regardless some "build
tools") - the dependency *is*, when some code uses that `.capitalize'
method, regardless how was it described.

If to take in mind you "build tool", I think augmenting of some built-
in object you'd like to put in some "global/general/built-in/common
-.js" which includes to *every* file. Meanwhile, "m.js" with own
namespace `M' and method `M.capitalize' will be included only in
needed files, right? Do I understand you correctly? Is this you want
to tell me? If so, let me again to mention about real dependency -
when code will *use* concrete and exact `.capitalize' method,
regardless *including* by some "build tool". Moreover, nothing
prevents to place `String.prototype.capitalize' also "m.js".

A module that adds a property to something it doesn't own introduces
something globally accessible that unrelated to the module itself. It is
doing more than it should. It is not really modular.

First, not exactly "globally".

The thing that the module adds is globally accessible anywhere the
module is used.

Second, it's not the module who puts

"something" into the "something". That *you* augment the built-in
module with new functionality to make more readable and useful code (I
remind, `String.prototype' is a module itself - so you put new
functionality into it. But not "some module is doing more than it
should").

I did not understand that.


[...]

Here you're describing something concrete and already regardless topic
(it's not so interesting how `capitalize' is implemented in ExtJS or
in Prototype.js, this method was taken only for an abstract example of
augmenting) - is it a good or bad practice to augment built-ins. So I
let myself to answer shortly - even regardless is a "good" or "bad"
candidate for "some next Standard", it's absolutely not a bad practice
from my point of view - if you understand what are you doing. That
will let to write more clear and useful code.

The reason for looking at a concrete example was to look at why one
might modify String.prototype vs create own object.

Modifying String.prototype has some not so good consequences. They are:
(1) greater likelihood to conflict with something else than
YourOwn.stringFormat.capitalize. (a) future version of ES, (b) other
third party libs. (2) is less clear about where it is defined.

Does `captitalize` have to do with strings *in general*, or does it have
to do with the way your application *uses* strings? If so, then there is
greater likelihood of conflict with a future ES version. Otherwise, if
the method is *not* purely related to strings, then what is the
justification for adding it to String.prototype?

[...]

So, concluding this ('cause I don't wanna to make a useless dispute -
I see what see, I know what I know), some questions I have to you:

1. Do you understand that your *statement* about augmentations of
built-ins - is just your own (humble) opinion? (Actually, exactly the
same as mine. But in difference from yours, mine doesn't forbid, but
explain why it's good and when it can be the issue).

I don't see design decisions as amtters of personal preference, if
that's what you mean. I see them as having consequences.

The consequences of modifying objects you don't own outweigh any
benefits to the coding style.

Also, I'd like to mention, that firstly your statement sounded as
"Don't modify objects you don't own". There you didn't talk about
"built-ins" bug about abstract "not own" objects. Although, in our
talk I found out that you mean also built-ins. For me, touching some
*other* objects that I don't own (but not a built-ins) - is also can
be useless practice (although, I don't use words "bad practice",
'cause even regarding not to built-ins but to some other - it could be
useful to make some patch on some 3rd-party code, although, they can
do it themselves in new version of library).

Are you suggesting to modify a 3rd party method by shadowing it with a
patch?

That sort of reverse inheritance creates a dependency cycle.

That can easily cause a problem where the "patch" causes a bug somewhere
else.

Format (other)
TableRenderer (own)

Lets say your TableRenderer depends on Format and Format.capitalize has
a problem, so you replace it it your code with:-

Format.capitalize = function() { /*...*/ };

And it works. Great so you patched it. Now it capitalizes those funny
german characters just as the German customers want, and it ignores some
wacky leading whitespace chars that somehow the user managed to paste
into the text input. Fixed it. Good.

Now for example, something else in Format, Format.captitalizeTrim
(whatever) depends on capitalize. TableRenderer doesn't care; that
captitalizeTrim code path never gets executed. When capitalizeTrim is
called, it gets *your* patch, but only when TableRenderer is present on
the page. When TableRenderer is not present, it does not get your patch.
Say now that captitalizeTrim has problems with your patch, perhaps only
occasionally.

TableRenderer has dependency in Format, Format has dependency within
TableRenderer.

That dependency cycle creates a problem.

Instead either:
a) create your own capitalize routine, but not replace the existing.
b) modify the source code directly and test it wherever it is being used.

Obviously (a) is much easier and smaller in scope, better for a hotfix,
but if the patch is safe and would fix (possibly hidden) bugs elsewhere,
then it makes sense to fix the bug.

You might also want to file a bug report, though don't expect an
immediate fix with third libraries. I have filed bugs over 1 year ago
that remain open. Of course I patched those bugs myself in the source code.

2. I'd like to hear how exactly your position sounds. I've already
mentioned my position about this question: "I don't force anyone to
augment built-ins, I don't spread this idea, I'm just not agree with
the statement that augmenting of built-ins in dynamic language with
mutable objects - is a bad practice. Again - it's normal practice and
let to write more useful code against that long ugly as in ExtJS for
`.capitalize'".

Are there any good reasons for modifying the built-ins?

So whatever you write (for whom this "Code Guidelines"?) - will you
write it or not (that it's a "bad practice") - I don't mind. But if
some using this "Code Guidelines" will (or will try to) judge anyone
by that question (about augmenting of built-ins) - I'll tell again,
that that people don't understand why they are judging so and they
don't think with their own head. Also that will be a bad practice of
using such "Code Guidelines" for *novices*, which will think that
everything written there (in statement manner!) - is conclusive true.
But it's not so.

I'm writing the Code Guidelines for basis code reviews here.

An example of modifying not own objects that we saw recently was where
dojo adds a _listeners property to a function.

The next document is Code Review Guidelines. We are going to have good
code reviews here.

 

[Garrett Smith]

Dmitry A. Soshnikov wrote:
Dmitry A. Soshnikov wrote:
Dmitry A. Soshnikov wrote:
[snip]
A public library that modifies
the built-ins can't really be trusted to work with other code.

[snip]

[///]

Are you suggesting to modify a 3rd party method by shadowing it with a
patch?

Correction:

not "shadowning it with a patch" but
"replacing the value where needed".
[...]

 

[Dmitry A. Soshnikov]

[snip]

Modifying String.prototype has some not so good consequences. They are:
(1) greater likelihood to conflict with something else than
YourOwn.stringFormat.capitalize. (a) future version of ES, (b) other
third party libs. (2) is less clear about where it is defined.

Ok, let's conclude it. I completely understand that reasons (moreover,
with some of them I agree and mentioned myself).

What I was saying to you in this thread regarding to augmenting of
built-ins - is about *formulation* of the answer. Taking into account
that it's your article (or whatever it is) - you can write as you wish
including formulation such as "Don't touch/augment object that you
don't own".

Meanwhile, I suggested (and would write myself if it was my article)
something like this:

"Be careful augmenting/modifying objects that's you don't own.
Although, you can do this e.g. augmenting some built-ins (for getting
new needed functionality with more useful, logical and elegant code)
take in mind several well-known issues, main of which are: (a)
Augmenting Object.prototype because (here small explanation) and (b)
Using some 3rd-party libs (here again small explanations)."

Without saying is it a good or bad practice.

Are there any good reasons for modifying the built-ins?

I've told, from functionality point of view - actually, there's no
difference where will you put this code. But the main reasons for me
to write 'string.capitalize()' instead of
YourOwnNamespace.SomeGreatModules.ThisInternalModule.ModuleForString.capitalize
() is:

- logical place for string's methods in string module (and I'll prefer
to put this functionality into the already existing module *taking
into account all issues I'll have (if I will));

- more useful and elegant code (in OOP-style instead of procedure-
style).

And please keep in mind, I'm not asking you may I write so or not,
'cause I repeat - I understand what I'm doing and why I'm doing so and
moreover, still repeat, that's just your own opinion with your own
issues (yeah, I understand that you'll always afraid that ES will (or
will not?) provide tomorrow (after several years) new method
`capitalize' in `String.prototype' and you understanding that will
use
YourOwnNamespace.SomeGreatModules.ThisInternalModule.ModuleForString.capitalize
() for that. Meanwhile me, understanding what that's all about and why
do I need this - will augment `String.prototype' with `capitalize' and
will use it. When after 5 years ES will provide the same method (and I
guess it will have similar functionality - just like with `trim' which
people use not the first year) - I'll use built-in method).

/ds

 

[Jorge]

(...)
And please keep in mind, I'm not asking you may I write so or not,
'cause I repeat - I understand what I'm doing and why I'm doing so and
moreover, still repeat, that's just your own opinion with your own
issues (yeah, I understand that you'll always afraid that ES will (or
will not?) provide tomorrow (after several years) new method
`capitalize' in `String.prototype' and  you understanding that will
use
YourOwnNamespace.SomeGreatModules.ThisInternalModule.ModuleForString.capita lize
() for that. Meanwhile me, understanding what that's all about and why
do I need this - will augment `String.prototype' with `capitalize' and
will use it. When after 5 years ES will provide the same method (and I
guess it will have similar functionality - just like with `trim' which
people use not the first year) - I'll use built-in method).

There at least a couple of ways to avoid that situation :

1st.- Don't use a generic name such as "capitalize", use instead:
String.prototype.dmitrySoshnikovsCapitalize= function () { .. };

2nd.- Don't hard-code the name, do an indirection instead. For
example:
String.prototype[myApp.capitalize]= myApp.capitalizeFunction;

And then use "a string"[myApp.capitalize](); //Access indirectly.

3rd and best.- Get real. Forget about this until it actually becomes a
problem, if ever.

 

[Garrett Smith]

On Jan 1, 8:43 pm, "Dmitry A. Soshnikov" <[email protected]>
wrote:
[snip]

[...]

You're using Google Groups, then, I take it.

Yes I use Google Groups to see/answer. And what do you?

I use Thunderbird and eternal-september.org news server.

 

[Garrett Smith]

[snip]

Modifying String.prototype has some not so good consequences. They are:
(1) greater likelihood to conflict with something else than
YourOwn.stringFormat.capitalize. (a) future version of ES, (b) other
third party libs. (2) is less clear about where it is defined.

Ok, let's conclude it. I completely understand that reasons (moreover,
with some of them I agree and mentioned myself).

What I was saying to you in this thread regarding to augmenting of
built-ins - is about *formulation* of the answer. Taking into account
that it's your article (or whatever it is) - you can write as you wish
including formulation such as "Don't touch/augment object that you
don't own".

I am writing a Code Guidelines document. It is important for that
contents to be accurate and relevant.

Meanwhile, I suggested (and would write myself if it was my article)
something like this:

"Be careful augmenting/modifying objects that's you don't own.
Although, you can do this e.g. augmenting some built-ins (for getting
new needed functionality with more useful, logical and elegant code)
take in mind several well-known issues, main of which are: (a)
Augmenting Object.prototype because (here small explanation) and (b)
Using some 3rd-party libs (here again small explanations)."

Without saying is it a good or bad practice.

The Code Guidelines document is for code reviews.

Design advice for code reviews might want to provide an alternative
suggestion and explain consequences for the design.

I've told, from functionality point of view - actually, there's no
difference where will you put this code. But the main reasons for me
to write 'string.capitalize()' instead of
YourOwnNamespace.SomeGreatModules.ThisInternalModule.ModuleForString.capitalize
() is:

DOn't you think you're exaggerating the namespace typing issue just a
*little*?

Not even Qooxdoo and Ext have such long namespaces.

[...]

- more useful and elegant code (in OOP-style instead of procedure-
style).

How is it more "OOP" than defining a separate method on your own namespace?

[...]

use
YourOwnNamespace.SomeGreatModules.ThisInternalModule.ModuleForString.capitalize
() for that. Meanwhile me, understanding what that's all about and why
do I need this - will augment `String.prototype' with `capitalize' and
will use it. When after 5 years ES will provide the same method (and I
guess it will have similar functionality - just like with `trim' which
people use not the first year) - I'll use built-in method).

Is the `captitalize` method related directly to strings, or is it about
formatting? Are there other types of formatting routines that may be
used in conjunction with that?

 

[Dmitry A. Soshnikov]

There at least a couple of ways to avoid that situation :

1st.- Don't use a generic name such as "capitalize", use instead:
String.prototype.dmitrySoshnikovsCapitalize= function () { .. };

Yeah, funny

2nd.- Don't hard-code the name, do an indirection instead. For
example:
String.prototype[myApp.capitalize]= myApp.capitalizeFunction;

And then use "a string"[myApp.capitalize](); //Access indirectly.

Yep, the sickness which is called "softcode" - when some afraid of
hardcode and see hardcode everywhere. Also funny, I don't wanna
support such code

3rd and best.- Get real. Forget about this until it actually becomes a
problem, if ever.

Yep, I think so too.

P.S.: You forgot the 4th -
YourOwnNamespace.SomeGreatModules.ThisInternalModule.ModuleForString.capita
lize() Let's fill the code with that long lines and give for
supporting to somebody, he will be glad

/ds

 

[Dmitry A. Soshnikov]

[snip]

I am writing a Code Guidelines document. It is important for that
contents to be accurate and relevant.

Yeah, right, but fully accurate can be only exact info such as e.g.
info from Standard or sort of. Info based on own opinion cannot be the
only one accurate and relevant. As I told, yours and mine - both are
own opinion with understandable issues; and I showed you the
difference of your and my opinions. So, you can choose yourself what
will you write in Code Guidelines document. The only thing I mentioned
- if this will be the document of judging - no one can judge anyone by
this question by that's own opinion, 'cause I'll be against again.
Against the formulation.

Is the `captitalize` method related directly to strings, or is it about
formatting? Are there other types of formatting routines that may be
used in conjunction with that?

All the answers on such questions you can find yourself by the
situation and decide what to do.

Regards.

/ds

 

[Thomas 'PointedEars' Lahn]

OK, but Firefox, or Gecko implement that as a native JSObject with

How can you possibly know?

Object.prototype on the prototype chain.

A host object may have a native object in its scope chain. That does not
make it a native object.

It is a little different in IE,
where the object is not a JScript object.

location.valueOf(); // Error in IE.

location instanceof Object; // False in IE

AISB, that is not a viable test.


PointedEars

 

[Jorge]

(...)
P.S.: You forgot the 4th -
YourOwnNamespace.SomeGreatModules.ThisInternalModule.ModuleForString.capita
lize()

But that's what you called the "procedural" flavor, and I prefer the
"OOP" flavor (inherited, by extension of the prototype).

Let's fill the code with that long lines and give for
supporting to somebody, he will be glad

I read somewhere that one of Crockford's new years' resolutions was to
quit using single letter vars...

 

[Garrett Smith]

[snip]

I am writing a Code Guidelines document. It is important for that
contents to be accurate and relevant.

Yeah, right, but fully accurate can be only exact info such as e.g.
info from Standard or sort of. Info based on own opinion cannot be the
only one accurate and relevant. As I told, yours and mine - both are
own opinion with understandable issues; and I showed you the
difference of your and my opinions. So, you can choose yourself what
will you write in Code Guidelines document. The only thing I mentioned
- if this will be the document of judging - no one can judge anyone by
this question by that's own opinion, 'cause I'll be against again.
Against the formulation.

Decisions of design are not merely matters of personal opinion or fancy.
Design decisions have consequences.

Design decisions based on the author thinking that the design is "cool"
often, and in this case, miss the consequences of those decisions.

The consequences shown:

1) More likely to conflict with:
a) code added by another contributor
b) a third party library
c) future ECMAScript specification/proposal

2) Not as clear as to who owns that functionality or where the
functionality is defined ("where is this method coming from?").

It is also possible to create a dependency cycle. It is possible that
the modification makes what should be internal information accessible to
other code (e.g. adding a _listeners property to functions).

All the answers on such questions you can find yourself by the
situation and decide what to do.

If you're not willing to provide evidence for your case for why
`capitalize` is preferable here, then there aren't any benefits to that.

The only benefits you provided are that you like it.

 

[Dmitry A. Soshnikov]

Decisions of design are not merely matters of personal opinion or fancy.

Your should first tell it to yourself

Design decisions have consequences.

Design decisions based on the author thinking that the design is "cool"
often, and in this case, miss the consequences of those decisions.

Listen, ECMAScript is designed to be dynamic and mutable. Why are you
continue to propagate the static-language features just like you're
the only one who is judging here? I repeat, I don't ask you and don't
justify why can I do so (and will if it will be needed).

So about "cool", please, don't use such arguments. If you have another
opinion, which is based on your programing fear, you can easily
continue to write programs in your own design. That absolutely doesn't
mean that you're right in the only one way.

The consequences shown:

1) More likely to conflict with:
   a) code added by another contributor
   b) a third party library
   c) future ECMAScript specification/proposal

2) Not as clear as to  who owns that functionality or where the
functionality is defined ("where is this method coming from?").

It is also possible to create a dependency cycle. It is possible that
the modification makes what should be internal information accessible to
other code (e.g. adding a _listeners property to functions).

If there's no such consequences (should I repeat again, that I
understand all the issues?), why some should think that he's write
programs in "wrong" design? That's only your opinion. Only. Will you
mind?

And that's question with dependencies - you still continue to spread
some "dependency" which you think out yourself. Should I repeat/show
again, that dependency is equal?

If you're not willing to provide evidence for your case for why
`capitalize` is preferable here, then there aren't any benefits to that.

You again started to use demagogy ("you not willing"). It's possible
to ask you to give answers *to me* (please pay attention in which
style of dialog we'll talk) about all the other (built-in) methods. I
also can continue just thinking out newer and newer reasons and
justifies about position which I've choose, but I sure won't, 'cause
there's no any reason to do so, I'm interested only in truth.

And the truth here is: that's only your own (and I'm underlying -
_humble_) opinion about programing on ECMAScript. Why have you decided
that you can judgjing me and think that it's you who will choose what
is correct and what is not? I'm telling you, in my opinion that long
crap such is Ext.util.Format.capitalize(string) - is really crap of ES
programing. What's hard to understand? Please ask, I can answer and
give explanations.

And again - about capitalize - it was just abstract name. Are you
unable to think abstractly? Don't touch concrete implementations,
meanings and so on, it's just superficially, tops, think more deeply -
about the subject and the theory but not about "what is capitalize"?
Ask yourself what is "trim" (regardless that in ES5 trim is generic)?
Just ask, and think why people use it with augmenting with
String.prototype? I use. And I like it, and I haven't any problem with
that, and I understand what I'm doing. What's wrong with me then from
your position? And, excuse me, who are you to tell me (to judge
me? ) that's something wrong with me in ES?

The only benefits you provided are that you like it.

You can continue to use your system, but don't think that it's the
only one correct system. It's just the one opinion which can turn out
into the crap when you'll have some deep structure and will be forced
to write
YourOwnNamespace.SomeGreatModules.ThisInternalModule.ModuleForString.capitalize
()

Sure I like and prefer use logical and useful string.capitalize(); You
can choose your own way and write the code which I really don't like
(I'm again about Ext.util.Format.capitalize(string)).

So, please write as you wish. When some then will judge somebody using
this document, I'll tell that author of document and the person who
will judge just understand ES from their own position (or even maybe
don't completely understand).

/ds

 

[Garrett Smith]

Your should first tell it to yourself

What?


Listen, ECMAScript is designed to be dynamic and mutable. Why are you
continue to propagate the static-language features just like you're
the only one who is judging here? I repeat, I don't ask you and don't
justify why can I do so (and will if it will be needed).

Where did I propagate static language features?

So about "cool", please, don't use such arguments. If you have another
opinion, which is based on your programing fear, you can easily
continue to write programs in your own design. That absolutely doesn't
mean that you're right in the only one way.

I do not have programming fear. The arguments I have presented are
pretty logical. You've not shown counter for those, here:

If there's no such consequences (should I repeat again, that I
understand all the issues?), why some should think that he's write
programs in "wrong" design? That's only your opinion. Only. Will you
mind?

The problems of a program modifying objects it doesn't own exists
regardless of my opinion. An example of that problem was just
demonstrated by `String.prototype.trim` throwing errors when used as
specified by ES5.

And that's question with dependencies - you still continue to spread
some "dependency" which you think out yourself. Should I repeat/show
again, that dependency is equal?

The "dependency cycle" was explained in the earlier message, too.

You again started to use demagogy ("you not willing").

I asked to to show the problem and post your code but you won't; you
refuse and keep saying 'demagogy".

It's possible

to ask you to give answers *to me* (please pay attention in which
style of dialog we'll talk) about all the other (built-in) methods. I
also can continue just thinking out newer and newer reasons and
justifies about position which I've choose, but I sure won't, 'cause
there's no any reason to do so, I'm interested only in truth.

And the truth here is: that's only your own (and I'm underlying -
_humble_) opinion about programing on ECMAScript. Why have you decided
that you can judgjing me and think that it's you who will choose what
is correct and what is not?

Design decisions are not a matter of absolute right and wrong. Design
decisions have consequences.

We've been over the pros and cons and so far, the only pro is that you
like being able to use `"foo".capitalize()`.

I'm telling you, in my opinion that long

crap such is Ext.util.Format.capitalize(string) - is really crap of ES
programing. What's hard to understand? Please ask, I can answer and
give explanations.

The "it's crap" argument is hard to understand. AIUI, "it's crap" means
you don't like it, but that you instead prefer what you call "OOP".

And again - about capitalize - it was just abstract name. Are you
unable to think abstractly?

Well we're discussing abstractions here. Where do you find my arguments
to be incorrect? Or where are my failings in thinking abstractly?

Don't touch concrete implementations,

meanings and so on, it's just superficially, tops, think more deeply -
about the subject and the theory but not about "what is capitalize"?

The point of drawing out your example is to show the actual code of
something that you proposed as being the better solution.

Ask yourself what is "trim" (regardless that in ES5 trim is generic)?
Just ask, and think why people use it with augmenting with
String.prototype? I use. And I like it, and I haven't any problem with
that, and I understand what I'm doing. What's wrong with me then from
your position? And, excuse me, who are you to tell me (to judge
me? ) that's something wrong with me in ES?

For production code, for code which is, or may be integrated with public
API, for code that is intended to work in the next version of an
implementation, avoid modifying objects you don't own.

It is usually very easy to avoid modifying objects that you don't own.

In the case of String.prototype.capitalize, it is so easy that there
doesn't even have to be very severe consequences in doing that to make
avoiding it a serious consideration.

It is trivial to create your own capitalize routine, but not replace the
existing.

You can continue to use your system, but don't think that it's the
only one correct system.

That's a little too general here. The "system" is "don't modify objects
you don't own".

There may be exception for having motivation to do that, but it is
certainly not provided for in whatever sparse example or argument
presented so far.

It's just the one opinion which can turn out

into the crap when you'll have some deep structure and will be forced
to write
YourOwnNamespace.SomeGreatModules.ThisInternalModule.ModuleForString.capitalize
()

Sure I like and prefer use logical and useful string.capitalize(); You
can choose your own way and write the code which I really don't like
(I'm again about Ext.util.Format.capitalize(string)).

In code review, code that modifies objects it does not own should be
mentioned. If design of code can be improved, I want someone to say so,
for my code, at least. I want to know what I did that was odd,
confusing, inflexible, complicated.

So, please write as you wish. When some then will judge somebody using
this document, I'll tell that author of document and the person who
will judge just understand ES from their own position (or even maybe
don't completely understand).

If you have an argument for why String.prototype.capitalize is a good
thing, I haven't understood that (because I can't understand what you
won't show).

Do you put that in a user-file "built-ins.js", "string-mods.js" or
"format.js". What is `capitalize being used for? The abstraction should
be closely related to the object it deals with. The abstraction might be
about how your application uses strings and not String in general.

 

[Dmitry A. Soshnikov]

What?

What "what"? That your decision is also based on personal opinion. You
describe some well-known issues related to augmenting of built-ins and
think that such pattern (don touch them! – yeah with exclamation mark
at the end ) – is the only one which is related to the professional
programming in production on ECMAScript. But that's only one of some
patterns and this invariant pattern (don't touch!) – is exactly
invariant and inflexible. Meanwhile, me, understanding what I'm doing
and why – can use all features of the language I write with full
power.

Where did I propagate static language features?

Indirectly as the way you've chosen, though, it's fully in ideology of
dynamic based languages. There're some special patterns for most
useful augmenting and so on – to use on full power the system (the
language) on which you write.

Although, you didn't propagate static features directly and can
augment dynamically own object.

I do not have programming fear. The arguments I have presented are
pretty logical. You've not shown counter for those, here:

For me discussion is not "argument-counter" – in such ways that's just
dispute without finding the truth (which is always should be the only
one), but desire to defend the position. I don't see the big sense in
such discussions, ‘cause as a basis the own understanding, own pattern
is taken by the "The standard" which is wrong. That's only opinion,
only one of the ways which can be used or not – by situation.

You found out for yourself some pattern which is based on some
understandable issues. You then wanna to collect some rules and use
such pattern thinking that now you are free from issues and problems.
But from the other hand, fixing "problems" on one side, you can create
them on the other side. Why some should write
"YourOwnNamespace.SomeGreatModules.ThisInternalModule.ModuleForString.capitalize
()" Ah? Just because you always want to use some the only one patterns
which is protected from all issues and which is the only way? What's
the price for that? Code which looks overheated, too much detailed.

The problems of a program modifying objects it doesn't own exists
regardless of my opinion. An example of that problem was just
demonstrated by `String.prototype.trim` throwing errors when used as
specified by ES5.

What do you mean "when used as specified by ES5"? I've told you – when
I haven't ES5 implemented – I use own, when ES5 will provide it – I
easily switch to implementation of the ES5 and will use it. So, that's
just demagogy – for what uses `.trim.apply(someThing)" with own
implementation? Sure if I need the way using as specified by ES5, I'll
use ES5's implementation.

The "dependency cycle" was explained in the earlier message, too.

Which is equal, right? I've heard.

I asked to to show the problem and post your code but you won't; you
refuse and keep saying 'demagogy".

What kind of "problem and code" are you talking about? I repeat, the
most essential thing – is theory and *approach* to that. And from this
point of view there could be several approaches which is best fit to
situation, but not think out inflexible pattern which is always should
be used writing that long lines.

It's possible



Design decisions are not a matter of absolute right and wrong. Design
decisions have consequences.

Sure, and should I repeat that I completely understand all the issues?
Should I? That I know about 3rd-party libs, Object.prototype and so
on? What' the problem? If I know about that and if I understand what
I'm doing – for what reason should I write such "long crap" insteadof
ideological and useful method call on object itself but not the long
"YourOwnNamespace.SomeGreatModules.ThisInternalModule.ModuleForString.capitalize
()"?

Just explain me why, taking into account that I completely understand
all the issues. And if know that there will be no such situation, for
what reason should I write by that inflexible invariant pattern which
you think out to program in enemy environment, where it is not known,
what libraries load, as why extend etc. - in general, uncontrollable
system, where you should afraid of everything and for that's aim think
out "cool" pattern which helps to avoid that (yeah, I understand that
the price is – not so ideological and useful code).

We've been over the pros and cons and so far, the only pro is that you
like being able to use `"foo".capitalize()`.

I'm telling you, in my opinion that long


The "it's crap" argument is hard to understand. AIUI, "it's crap" means
you don't like it, but that you instead prefer what you call "OOP".

You're using specially the most "strong" parts of my cites to show
that I use some non-logical arguments, right? You can stop trying to
do it, I've already appreciate it

But I meant the following, then all the code is penetrated by lines
such as (I let my self copy-paste one line):

YourOwnNamespace.SomeGreatModules.ThisInternalModule.ModuleForString.capitalize
()
YourOwnNamespace.SomeGreatModules.ThisInternalModule.ModuleForString.capitalize
()
YourOwnNamespace.SomeGreatModules.ThisInternalModule.ModuleForString.capitalize
()
YourOwnNamespace.SomeGreatModules.ThisInternalModule.ModuleForString.capitalize
()
YourOwnNamespace.SomeGreatModules.ThisInternalModule.ModuleForString.capitalize
()
YourOwnNamespace.SomeGreatModules.ThisInternalModule.ModuleForString.capitalize
()
YourOwnNamespace.SomeGreatModules.ThisInternalModule.ModuleForString.capitalize
()
YourOwnNamespace.SomeGreatModules.ThisInternalModule.ModuleForString.capitalize
()

If
(YourOwnNamespace.SomeGreatModules.ThisInternalModule.ModuleForString.capitalize
&&
YourOwnNamespace.SomeGreatModules.ThisInternalModule.ModuleForString.capitalize
()) {

YourOwnNamespace.SomeGreatModules.ThisInternalModule.ModuleForString.capitalize
()
} else {

YourOwnNamespace.SomeGreatModules.ThisInternalModule.ModuleForString.capitaliz}

Of cause, it's can be in general with some other objects in the system
and this question can be not related to the augmenting the built-ins,
but I don't see any reason to do this with built-ins if I understand
and know the system which I program.

Well we're discussing abstractions here. Where do you find my arguments
to be incorrect? Or where are my failings in thinking abstractly?

You can leave provocation questions, I don't mind on them. I didn't
say about "incorrect, failings in thinking". I asked mostly to think/
talk about the ideology and the theory. Sure we should show some on
practice, but the main goal – is approach independently the exact
practice examples such as with capitalize(). I repeat, that this name
has been chosen just for abstraction with real example in e.g. ExtJS,
no more, no less. And you continue: "what is capitalize? Why is? Where
is it? Why is it there? Who are they? Why?" – that's I was talking
about – that's concrete deep practice things in this dialog is not so
interesting and not so essential. The approach and ideology are
essential.

Don't touch concrete implementations,


The point of drawing out your example is to show the actual code of
something that you proposed as being the better solution.

I've already told.

For production code, for code which is, or may be integrated with public
API, for code that is intended to work in the next version of an
implementation, avoid modifying objects you don't own.

For production professional code, I'll use the system on all power,
flexible by situation, depends on variants I have – as in code
(looking, ideology elegance), as in performance. You can choose your
own way.

It is usually very easy to avoid modifying objects that you don't own.

In the case of String.prototype.capitalize, it is so easy that there
doesn't even have to be very severe consequences in doing that to make
avoiding it a serious consideration.

It is trivial to create your own capitalize routine, but not replace the
existing.

Why should I replace existing? Do you hear what I'm talking about? I
know and understand what can be, understand all the issues. If I'll
see the issues (if I ever will) I choose the other flexible way
programming in ideology of the language on which I write. You can
choose your own invariant pattern which you think out based on well-
known issues.

What the problem do you see?

In code review, code that modifies objects it does not own should be
mentioned. If design of code can be improved, I want someone to say so,
for my code, at least. I want to know what I did that was odd,
confusing, inflexible, complicated.

If all are taken into account, shouldn't. Why should? Why some should
say me: "A-ha! You're modifying built-ins, your code is not
professional, your code is not for production! A-ha!" Why I don't
understand if I know why did I use so and by what reason.

If you have an argument for why String.prototype.capitalize is a good
thing, I haven't understood that (because I can't understand what you
won't show).

Well, I just can suggest to continue trying to understand that the
system you use can be used on all power depends on situation and
taking into account all the well-known issues.

What's the problem? Did I say that I don't understand some of those
issues? Did I, please answer? Or maybe I really don't understand them?
Or maybe I propagate and spread that: "Augment built-ins everywhere
independent the exact case! I don't wanna listen about issues and I
don't understand them!" Did I, please answer?

I've told repeatedly that I completely understand what's the all about
and why can I choose this that way, that I'm not limited by some
invariant pattern which can protect from all the issues but with some
special price for that – code which seems to me to overheated and odd
for ECMAScript programming.

I see that you operate with terms "you just like it, but my arguments
are about concrete issues", right? What arguments? Didn't I see and
understand all that arguments, please answer? Didn't I tell you that I
see the prob in *formulation*? That your chosen pattern is just only
of some variants which can be also professional and exec in production
environment. That you haven't even rights to write "don't use/touch!"
So for that I suggested: "Be careful…" which is more fairly. Will you
mind?

/ds

 

[Garrett Smith]

What "what"? That your decision is also based on personal opinion.

Who said that?

You

describe some well-known issues

Is "dependency cycle" well known?

Are the side effects of modifying String.prototype well-known? Are the
potential problems too distant to be seen, or are they imaginary, and
demagogy?

related to augmenting of built-ins and

think that such pattern (don touch them! – yeah with exclamation mark
at the end ) – is the only one which is related to the professional
programming in production on ECMAScript. But that's only one of some
patterns and this invariant pattern (don't touch!) – is exactly
invariant and inflexible. Meanwhile, me, understanding what I'm doing
and why – can use all features of the language I write with full
power.

Full power?

Indirectly as the way you've chosen, though, it's fully in ideology of
dynamic based languages.

Indirectly as the way I've chosen? What do you mean?

There're some special patterns for most

useful augmenting and so on – to use on full power the system (the
language) on which you write.

Again with the full power.

Although, you didn't propagate static features directly and can
augment dynamically own object.

OK, so I did not propagation static features. Good. Glad we cleared that
up.

For me discussion is not "argument-counter" – in such ways that's just
dispute without finding the truth (which is always should be the only
one), but desire to defend the position. I don't see the big sense in
such discussions, ‘cause as a basis the own understanding, own pattern
is taken by the "The standard" which is wrong. That's only opinion,
only one of the ways which can be used or not – by situation.

Design decisions should be based on pros and cons; not some absolute
ideal of how the author would have redesigned some other piece of code.

Objects can talk to each other but should not be modifying each other.
That way it's clear what each thing is and what each thing does.

That does not mean static typing. Some times you want to have an
aggregate of borrowed properties. YUI calls it "augmentObject", I call
it "mixin". Either name is fine by me, really it is obvious enough.

var AB = APE.mixin(A, B);

That way I've created an object dynamically, not statically. But notice
that I am not saying something like:

A.js:

function A(){

}

B.prototype.ddd = function(){
//lets fix this buggy method.
this.ddd = Math.abs(this.d);
};

A.prototype = new B;

Oh, now the same problem as with TableRenderer, I've just created a
dependency cycle. NOw B depends on A. F.

You found out for yourself some pattern which is based on some
understandable issues. You then wanna to collect some rules and use
such pattern thinking that now you are free from issues and problems.

Why not?

But from the other hand, fixing "problems" on one side, you can create
them on the other side. Why some should write
"YourOwnNamespace.SomeGreatModules.ThisInternalModule.ModuleForString.capitalize
()" Ah?

Did I ever suggest doing that?

Just because you always want to use some the only one patterns

which is protected from all issues and which is the only way? What's
the price for that? Code which looks overheated, too much detailed.

too much detail? No, not too much detail, just sarcastically long and
useless namespace.

Packages with uselessness and adjectives, such as "SomeGreatModules",
ought to be commented on in review with alternative suggestions.

If you want to make a real argument, going from abstraction to
concretion, we can see an example. We have already seen the example with
Crockford's buggy `String.prototype.trim`.


Still stands.

Wrong design? No, not right or wrong. I tend to more think in terms of
actions and consequences.

Saying "I know what I'm doing" while ignoring the known consequences of
doing something is your choice. For production code, I would probably
flag that and, depending on what it was doing, suggest that the program
do otherwise.

Is it difficult to use your own objects and not modify the built-ins?
No, we've established that it is not difficult. The only remaining
problem is that you like seeing "foo".capitalize.

What do you mean "when used as specified by ES5"? I've told you – when
I haven't ES5 implemented – I use own, when ES5 will provide it – I
easily switch to implementation of the ES5 and will use it. So, that's
just demagogy

There you go with your demagogy again. Go launch up a recent version of
Firefox and try String.prototype.trim.

– for what uses `.trim.apply(someThing)" with own

implementation? Sure if I need the way using as specified by ES5, I'll
use ES5's implementation.

ES5 implementation is standard behavior. What is the good reason for
redefining the language to your deviations? Any justificaiton for doing
that would seem to be confusing to others who are expecting built-ins to
work as normal. I also see some arrogance in that approach; as if you
think your version of the language must be better.

Which is equal, right? I've heard.

What is equal? Do you know what a dependency cycle is? I explained a
situation about a user-defined, hypothetical `TableRenderer` widget that
wanted to modify one of its dependencies called `Format`, to fix
`Format.capitalize` related bug.

Format
^
|
TableRenderer


TableRenderer depends on Format.

A bug related to Format.capitalize is "fixed" it (the author "knows what
he is doing") inside the TableRenderer widget file. Now Format is
depending on TableRenderer.



Format
^
|
TableRenderer
^
|
Format

After the modification, Format works differently when TableRenderer is
used. This inconsistency may or may not work fine for the usage
patterns. Regardless, consistent behavior would be less confusing (and
without the confusing coupling).

What kind of "problem and code" are you talking about? I repeat, the
most essential thing – is theory and *approach* to that. And from this
point of view there could be several approaches which is best fit to
situation, but not think out inflexible pattern which is always should
be used writing that long lines.


Sure, and should I repeat that I completely understand all the issues?
Should I? That I know about 3rd-party libs, Object.prototype and so
on? What' the problem? If I know about that and if I understand what
I'm doing – for what reason should I write such "long crap" instead of
ideological and useful method call on object itself but not the long
"YourOwnNamespace.SomeGreatModules.ThisInternalModule.ModuleForString.capitalize
()"?

Just explain me why, taking into account that I completely understand
all the issues. And if know that there will be no such situation, for
what reason should I write by that inflexible invariant pattern which
you think out to program in enemy environment, where it is not known,
what libraries load, as why extend etc. - in general, uncontrollable
system, where you should afraid of everything and for that's aim think
out "cool" pattern which helps to avoid that (yeah, I understand that
the price is – not so ideological and useful code).


You're using specially the most "strong" parts of my cites to show
that I use some non-logical arguments, right? You can stop trying to
do it, I've already appreciate it

But I meant the following, then all the code is penetrated by lines
such as (I let my self copy-paste one line):

YourOwnNamespace.SomeGreatModules.ThisInternalModule.ModuleForString.capitalize
()
YourOwnNamespace.SomeGreatModules.ThisInternalModule.ModuleForString.capitalize
()
YourOwnNamespace.SomeGreatModules.ThisInternalModule.ModuleForString.capitalize
()
YourOwnNamespace.SomeGreatModules.ThisInternalModule.ModuleForString.capitalize
()
YourOwnNamespace.SomeGreatModules.ThisInternalModule.ModuleForString.capitalize
()
YourOwnNamespace.SomeGreatModules.ThisInternalModule.ModuleForString.capitalize
()
YourOwnNamespace.SomeGreatModules.ThisInternalModule.ModuleForString.capitalize
()
YourOwnNamespace.SomeGreatModules.ThisInternalModule.ModuleForString.capitalize
()

If
(YourOwnNamespace.SomeGreatModules.ThisInternalModule.ModuleForString.capitalize
&&
YourOwnNamespace.SomeGreatModules.ThisInternalModule.ModuleForString.capitalize
()) {

YourOwnNamespace.SomeGreatModules.ThisInternalModule.ModuleForString.capitalize
()
} else {

YourOwnNamespace.SomeGreatModules.ThisInternalModule.ModuleForString.capitaliz}

Of cause, it's can be in general with some other objects in the system
and this question can be not related to the augmenting the built-ins,
but I don't see any reason to do this with built-ins if I understand
and know the system which I program.

A bunch of nonsense there.

That is not what I argued. It is thoughtless, invalid code, written in
what would appear to be global context, and will result in SyntaxError
because of calling undefined identifier `If`, and having a misplaced
`else` block.

It is weak sarcasm and doesn't seem like a strong argument for
augmenting built-ins.

You can leave provocation questions, I don't mind on them.

What, this:
"Are you unable to think abstractly?"

?

I think abstractly a lot. Language is an abstraction. So is music.

I didn't

say about "incorrect, failings in thinking". I asked mostly to think/
talk about the ideology and the theory. Sure we should show some on
practice, but the main goal – is approach independently the exact
practice examples such as with capitalize(). I repeat, that this name
has been chosen just for abstraction with real example in e.g. ExtJS,
no more, no less. And you continue: "what is capitalize? Why is? Where
is it? Why is it there? Who are they? Why?" – that's I was talking
about – that's concrete deep practice things in this dialog is not so
interesting and not so essential. The approach and ideology are
essential.

How can anyone know why it is there without looking at all that is using
it?

I've already told.

I didn't see you're solution. (the code you repeated 10x or so, with
invalid syntax is irrelevant).

For production professional code, I'll use the system on all power,

I have no idea what that means.

flexible by situation, depends on variants I have – as in code
(looking, ideology elegance), as in performance. You can choose your
own way.

What ideology and what performance?

You seemed to agree earlier that there are problems with such design
approach.

Does perceived benefit of using "".capitalize (you like it) outweigh
those problems?

As for choices, an author may choose choose to serve invalid HTML, or
non conformant HTML. It is not wrong, but there are problems with doing
that, even if those problems are not immediately apparent to the one who
is writing that code.

Why should I replace existing?

I really don't know.

I can't see any good reason for replacing existing functionality.

Do you hear what I'm talking about? I

know and understand what can be, understand all the issues. If I'll
see the issues (if I ever will) I choose the other flexible way
programming in ideology of the language on which I write. You can
choose your own invariant pattern which you think out based on well-
known issues.

What the problem do you see?

Increased likelihood of onflicts with code added by another contributor,
a third party library, a future ECMAScript specification/proposal.

Not as clear as to who owns that functionality or where the
functionality is defined ("where is this method coming from?").

There is also the possibility of creating a dependency cycle or leaking
implementation details out to the system.

With host objects, the possibility of errors exists. With native
functions, too, though that is under certain conditions in ES5
(including getters without setters, as implemented in Spidermonkey).

If all are taken into account, shouldn't. Why should? Why some should
say me: "A-ha! You're modifying built-ins, your code is not
professional, your code is not for production! A-ha!" Why I don't
understand if I know why did I use so and by what reason.


Well, I just can suggest to continue trying to understand that the
system you use can be used on all power depends on situation and
taking into account all the well-known issues.

What's the problem? Did I say that I don't understand some of those
issues? Did I, please answer?

You did not say that explicitly, no. Well, except for that part about
dependency cycle.

Or maybe I really don't understand them?

I believe that you like the effect of modifying String.prototype, seeing
"foo".capitalize, and that you don't find an alternative that is as
attractive.

You seem to see the problems associated with modifying String.prototype.
Probably because it is not causing problems for you directly. Maybe you
just are used to doing it that way, or that you think you're immune in
some way to them.

Or maybe I propagate and spread that: "Augment built-ins everywhere
independent the exact case! I don't wanna listen about issues and I
don't understand them!" Did I, please answer?

I've told repeatedly that I completely understand what's the all about
and why can I choose this that way, that I'm not limited by some
invariant pattern which can protect from all the issues but with some
special price for that – code which seems to me to overheated and odd
for ECMAScript programming.

I see that you operate with terms "you just like it, but my arguments
are about concrete issues", right?

No, none whatsover.

You've not shown one single concretion. You asked me to do that earlier
and I went right for your String.prototype.capitalize. Then you
questioned my ability to think abstractly.

What arguments? Didn't I see and

understand all that arguments, please answer? Didn't I tell you that I
see the prob in *formulation*? That your chosen pattern is just only
of some variants which can be also professional and exec in production
environment. That you haven't even rights to write "don't use/touch!"
So for that I suggested: "Be careful…" which is more fairly. Will you
mind?

"Be careful" is not really going to be defining something that could be
flagged in code. It is too vague.

You can say "be careful, the code modifies somebody else's object and
there are known problems with that." That is part of code review
guidelines.