Code Guidelines

[Dmitry A. Soshnikov]

[snip already discussed not once things]

Full power?

I meant when you can you system with all its features without limiting
yourself with some invariant inflexible patterns which force you to
write in a way of some other languages

Yeah, I've heard your argument that authors of some languages such as
ECMAScript, Ruby, etc. make this ability to write useful elegant code
augmenting built-ins with new functionality just as a big and
understandable mistake. Right?

But I tell you – no, it's not. It's special useful ability to do soif
you're free from well-known issues related to it.

And you – just haven't even rights to tell in tone in your documentas
"Don't touch!" Who are you to talk in this tone?

[snip]

Again with the full power.

I've already explained. Again – that mean when you completely know the
system (the language) and able to use all its features specially
designed for that.

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.

Sure, but you don't see that specially designed feature with
augmenting objects (any object and especially built-ins) - is also
pros.

Your argument "you just like it, it's not logical argument" which
you're continue to use seems really don't understand that that "like"
– is the feature which was specially designed. To use this feature or
not – that's only your decision which maybe based on a habit from
languages such as C++ or Java.

Though, e.g. in Python it's impossible to augment built-ins, but still
possible to dynamically augment any other user-defined objects (but
you against any augmentation of any objects that you don't own, so
that's also is not your case).

Objects can talk to each other but should not be modifying each other.

That's other thing and pattern of programming and is not related to
dynamic properties definition.

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

Yep, I also use term "mixin".

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.

Because of "A.prototype = new B;"?

If you use Math.abs(...) – no everything depends on Math? Right. But
maybe do not program at all in this case?

Why not?

No, that's OK, until you start think that you think out something the
one and only which is thought inflexible and start to describe it in
tone like "Don't touch".

I repeat, in system which I know and completely control (I don't
augment Object.prototype, I don't use 3rd-party libs), it's very
useful ability designed by the author of the language – to use new
functionality directly on object – that's elegant and useful. And yeah
– sure it's the main argument of such feature, and exactly with that
argument it was designed, so please don't use that argument ("you just
like it") against me, k? You can continue to write in a way of
Pascal or C++ or Java or whatever. Yeah, programming on Ruby is also
is counter-indicative to you – there also augmentation of built-ins
(as additional modules) is often used.

[snip useless parts of talk]

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

I don't mind with Crockford's buggy `String.prototype.trim`.

Please answer, which problems will I have if I:

(a) had own implementation of ‘.trim' and used it as ‘ string '.trim()
(b) then switch to built-in implementation and use it in the same way

Why do you still continue spread some strange case when some
(ostensibly) want to overwrite built-in implementation with own?
That's again demagogy (yes, again).

[snip the same; discussed not once alreay]

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

Sure, and which consequences will I have in system I fully know and
control (for you that means: I don't augment Object.prototype and
don't use 3rd-party libs)? For what reason I should limit myself and
do not use useful and elegant feature provided by the author of the
language as a part of its ideology?

Saying "I know what I'm doing" while ignoring the known consequences

Who is here ignoring the known consequences? Should I repeat again
that I know and understand all that consequences? But in system I
fully know (and don't afraid of it) and control (you should read this
as: I don't augment Object.prototype and don't use 3rd-party libs) –
for what reason I should limit myself and do not use useful and
elegant feature provided by the author of the language as a part of
its ideology (yeah, I copy-pasted it from previous sentence).

Is it difficult to use your own objects and not modify the built-ins?

What do you mean "difficult"? How do you think for what authors of
languages such as ECMAScript or Ruby or any else provided such
feature? Sure this elegant and useful (and logical – method/properties
of strings I can but into the String.prototype – the place specially
marked for it) syntactic sugar which is *specially* provided by the
authors. And again repeat – from the functionality viewpoint there's
no difference – that's your choice to write in procedural style, but
the authors decided to make such useful sugar which is really elegant
and which is really pros from this viewpoint. For what reason I
should limit myself and do not use useful and elegant feature provided
by the author of the language as a part of its ideology (yeah, I copy-
pasted it from previous sentence).

No, we've established that it is not difficult.

I don't understand why should we talk in manner – "is it difficult to
you do not use it and do it in a way I think out and think that this
is the one and only way. Yeah, I understand that it doesn't use
special feature of dynamic augmentation of built-ins and moreover I
believe it as a language and design mistake, but help me to fill
myself protected and leave my fear. So, please, don't do it... No, not
like this... Like this: Don't do it! Don't touch! It's difficult,
right? Don't do it."

The only remaining
problem is that you like seeing "foo".capitalize.

The "problem"? Why do you call it so? It's called useful and specially
designed feature of some well-known dynamic based language with
possibility mix in new functionality (in Ruby by the way, this term
"mixin" – is official).

What is the good reason for
redefining the language to your deviations?

But who ever said this? I let myself to copy-paste again from previous
sentence:

(a) had own implementation of ‘.trim' and used it as ‘ string '.trim()
(b) then switch to built-in implementation and use it in the same way

Why do you still continue spread some strange case when some
(ostensibly) want to overwrite built-in implementation with own?
That's again demagogy (yes, again).

Any justificaiton for doing
that would

Actually I don't see any reason to do so, even without any
justification. But with that I didn't say a word about such case.

What is equal? Do you know what a dependency cycle is?

Be sure.

I explained a
situation

The situation when some overwrite built-ins existing functionality
with own one? I didn't mean this – see again example with ‘trim' (what
exactly did I mean). If you want to exactly *fix* some bug – this is
completely on your conscience when and how will you make (if ever) it.
If the system is uncontrollable, how can you program it? When
functionality of Format in your example will change, you can change it
in the same way (or remove if not needed) in your widget. But I meant
not that.

A bunch of nonsense there.
Specially.


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.

That's I've told – you see and analyze some tops, but should see
deeply. This syntax errors are completely not about the topic and you
use it (and mention) specially to show what the nonsense I write,
which means – maybe I even don't know the language on the level of
syntax errors, right? Do you like it or not, but it's called direct
"demagogy" (and yes – again)

About the "If" – I used Microsoft Word when was answering that time,
so it maybe it was converted automatically, don't know. But even that
doesn't justify your demagogy, sorry.

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

Yeah, get the 10 points for mentioning invalid syntax

What kind of solution are you talking about? Take the use-case (I let
myself to copy-paste again taking into account that you like to carp
to things which are not related to the topic – which is – maybe it's
hard to you to see main goal of the talk – that's why you should waste
your (and which is even worse - mine) time on talking about absolutely
non-related things spreading demagogy about syntax errors just like I
don't language on that newbie level, right? Right. Take the 10
points ):

I don't augment Object.prototype and don't use 3rd-party libs? For
what reason I should limit myself and do not use useful and elegant
feature provided by the author of the language as a part of its
ideology?

[snip the same]

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

What do you mean? I always knew all the issues. Now you're talking
just like you explain me something and I agree. It is pleasant to you
whether or not, but it demagogy (yeah, sorry, again).

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

Which problems? Again (I won't get tired to repeat, though, it's easy
to copy-paste myself):

I don't augment Object.prototype and don't use 3rd-party libs? For
what reason I should limit myself and do not use useful and elegant
feature provided by the author of the language as a part of its
ideology?

And yes, from the ideological viewpoint – it's very useful syntactic
sugar pros.

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

If I don't have that problems (which I also know) – (get ready – copy-
paste comes ) - for what reason I should limit myself and do not use
useful and elegant feature provided by the author of the language as a
part of its ideology?

I believe that you like the effect of modifying String.prototype, seeing
"foo".capitalize

OK, I'm glad that you understand that.

and that you don't find an alternative that is as
attractive.

Yeah, but vice versa - "foo".capitalize is better and useful
alternative for the style of other languages which have no such
ability and forced to write in procedural way (regarding to the case).

You seem to see the problems associated with modifying String.prototype.
Probably because it is not causing problems for you directly.

OK, I'm glad to that you understand (have understood) that.

Then you
questioned my ability to think abstractly.

I've explained what I meant (not this). How to see that – that your
choice.

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

It's fair and related to the ECMAScript and well-known features.

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.

Well, you can choose this formulation also, it's more fairly than your
previous with "Don't touch". Although, you can add "...there are known
problems with that if (and shortly describe the issues – that user can
decide and choose – will he use it on not)"

/ds

 

[Garrett Smith]

[snip already discussed not once things]

Full power?`

I meant when you can you system with all its features without limiting
yourself with some invariant inflexible patterns which force you to
write in a way of some other languages

What is inflexible about creating your own object? It is trivial to do
that, most times.

Yeah, I've heard your argument that authors of some languages such as
ECMAScript, Ruby, etc. make this ability to write useful elegant code
augmenting built-ins with new functionality just as a big and
understandable mistake. Right?

Did I say mention a mistake in the design of the language?

But I tell you – no, it's not. It's special useful ability to do so if
you're free from well-known issues related to it.

I've read that again a few times. The language lets you do a lot of
things. Many of them are not useful. Some of them are powerful and
sometimes dangerous.

And you – just haven't even rights to tell in tone in your document as
"Don't touch!" Who are you to talk in this tone?

What tone?

[snip]

Again with the full power.

I've already explained. Again – that mean when you completely know the
system (the language) and able to use all its features specially
designed for that.

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.

Sure, but you don't see that specially designed feature with
augmenting objects (any object and especially built-ins) - is also
pros.

When do I get to hear those? I've been waiting for a lot of messages and
losing patience.

Your argument "you just like it, it's not logical argument" which
you're continue to use seems really don't understand that that "like"
– is the feature which was specially designed. To use this feature or
not – that's only your decision which maybe based on a habit from
languages such as C++ or Java.

Great. Show me a *good* example of doing that and we'll see an exception
to the rule.

Notice, I did not say there were no exceptions to the rule, but that
you've not yet shown an example of that. The `capitalize` example was a
start, but then you started in with asking me if I can think abstractly.

Though, e.g. in Python it's impossible to augment built-ins, but still
possible to dynamically augment any other user-defined objects (but
you against any augmentation of any objects that you don't own, so
that's also is not your case).


That's other thing and pattern of programming and is not related to
dynamic properties definition.


Yep, I also use term "mixin".


Because of "A.prototype = new B;"?

No, that's bad, but not my point. I used that because it was the
simplest way to show inheritance.

If you use Math.abs(...) – no everything depends on Math? Right. But
maybe do not program at all in this case?

RIght, A.js has modifications to the B object. Now, when B is used, it
gets those modifications. A depends on B because A extends B and now B
depends on A because A extended B.

This sort of thing can sometimes be even advocated as "Best Practice".
talk about "demagogy".

Here is a great example of a very problematic reverse inheritance:
http://www.dustindiaz.com/new-in-javascript/

The problems you'll see are similar, though instead of the "subclass"
modifying the super, we have the instantiation of the constructor, or
`nue`, modifying the prototype. Here's an example:

// DO NOT USE THIS CODE.
| // Copyright Dustin Diaz
| function nue (f) {
| var args = [].slice.call(arguments, 1);
| f.prototype.constructor = f;
| f.apply(f.prototype, args);
| return f.prototype;
| }
|
| function X(a){
| if(typeof a == "number")
| this.a = a;
| }
|
| var x1 = nue(X),
| z1a = x1.a;
| var x2a = nue(X, 1).a;
|
| [x1a, x1.a]

Results:
[undefined, 1]

THe problem is caused by `nue` modifying x.prototype.

Dustin Diaz accepts none of the criticism and happily continues in his
telling Grey he is wrong, while Grey and Isaac are correct.

No, that's OK, until you start think that you think out something the
one and only which is thought inflexible and start to describe it in
tone like "Don't touch".

IF you want to touch it, then that would be an exception to the
guideline. I'm not saying that doesn't exist, but I haven't seen your
example of that.

I repeat, in system which I know and completely control (I don't
augment Object.prototype, I don't use 3rd-party libs), it's very
useful ability designed by the author of the language – to use new
functionality directly on object – that's elegant and useful. And yeah
– sure it's the main argument of such feature, and exactly with that
argument it was designed, so please don't use that argument ("you just
like it") against me, k? You can continue to write in a way of
Pascal or C++ or Java or whatever. Yeah, programming on Ruby is also
is counter-indicative to you – there also augmentation of built-ins
(as additional modules) is often used.

Why do you want to modify built-ins' or other objects?

[snip useless parts of talk]

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

I don't mind with Crockford's buggy `String.prototype.trim`.

Please answer, which problems will I have if I:

(a) had own implementation of ‘.trim' and used it as ‘ string '.trim()
(b) then switch to built-in implementation and use it in the same way

The only problem in that particular usage pattern is a minor performance
penalty.

Why would you want to use a hand-rolled version that doesn't behave as
standard?

Why do you still continue spread some strange case when some
(ostensibly) want to overwrite built-in implementation with own?
That's again demagogy (yes, again).

What strange case? String.prototype.trim side effects? That is only
manifestation of one problem of the two types of problems. The other
manifestations of that problem are conflict with other code doing the
same, and the other problem is it's not clear which code (or object)
owns String.prototype ("where is that change coming from?").

[snip the same; discussed not once alreay]

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

Sure, and which consequences will I have in system I fully know and
control (for you that means: I don't augment Object.prototype and
don't use 3rd-party libs)? For what reason I should limit myself and
do not use useful and elegant feature provided by the author of the
language as a part of its ideology?

What ideology? The problems have been explained and snipped and I'm done
with typing again and again.

Who is here ignoring the known consequences?

You. Crockford. Probably others.

Should I repeat again

that I know and understand all that consequences? But in system I
fully know (and don't afraid of it) and control (you should read this
as: I don't augment Object.prototype and don't use 3rd-party libs) –
for what reason I should limit myself and do not use useful and
elegant feature provided by the author of the language as a part of
its ideology (yeah, I copy-pasted it from previous sentence).


What do you mean "difficult"?

I do not understand the obsession with buggering String.prototype. What
do do that for?

How do you think for what authors of

languages such as ECMAScript or Ruby or any else provided such
feature? Sure this elegant and useful (and logical – method/properties
of strings I can but into the String.prototype – the place specially
marked for it) syntactic sugar which is *specially* provided by the
authors.

Why did the author do that? I don't know. I could guess or ask.

Either way it doesn't matter what Brendan's ideology is, does it?

And again repeat – from the functionality viewpoint there's

no difference – that's your choice to write in procedural style, but
the authors decided to make such useful sugar which is really elegant
and which is really pros from this viewpoint. For what reason I
should limit myself and do not use useful and elegant feature provided
by the author of the language as a part of its ideology (yeah, I copy-
pasted it from previous sentence).


I don't understand why should we talk in manner – "is it difficult to
you do not use it and do it in a way I think out and think that this
is the one and only way. Yeah, I understand that it doesn't use
special feature of dynamic augmentation of built-ins and moreover I
believe it as a language and design mistake, but help me to fill
myself protected and leave my fear. So, please, don't do it... No, not
like this... Like this: Don't do it! Don't touch! It's difficult,
right? Don't do it."

I have no idea what your point is.

The "problem"? Why do you call it so? It's called useful and specially
designed feature of some well-known dynamic based language with
possibility mix in new functionality (in Ruby by the way, this term
"mixin" – is official).


But who ever said this? I let myself to copy-paste again from previous
sentence:

(a) had own implementation of ‘.trim' and used it as ‘ string '.trim()
(b) then switch to built-in implementation and use it in the same way

Why do you still continue spread some strange case when some
(ostensibly) want to overwrite built-in implementation with own?
That's again demagogy (yes, again).

Why do yo want to replace built-in function with your own? The only good
reason for doing that, AFAIC, is if the feature is buggy, and then,
doing it only after a feature test that verifies the implementation does
not match the specification.

Actually I don't see any reason to do so, even without any
justification. But with that I didn't say a word about such case.


Be sure.


The situation when some overwrite built-ins existing functionality
with own one? I didn't mean this – see again example with ‘trim' (what
exactly did I mean). If you want to exactly *fix* some bug – this is
completely on your conscience when and how will you make (if ever) it.
If the system is uncontrollable, how can you program it? When
functionality of Format in your example will change, you can change it
in the same way (or remove if not needed) in your widget. But I meant
not that.


That's I've told – you see and analyze some tops, but should see
deeply. This syntax errors are completely not about the topic and you
use it (and mention) specially to show what the nonsense I write,
which means – maybe I even don't know the language on the level of
syntax errors, right? Do you like it or not, but it's called direct
"demagogy" (and yes – again)

About the "If" – I used Microsoft Word

This is seeming like a more and more of a waste of time.

when was answering that time,

so it maybe it was converted automatically, don't know. But even that
doesn't justify your demagogy, sorry.


Yeah, get the 10 points for mentioning invalid syntax

I'm done here. You've got 0 rational argument, post some long code that
I didn't write to try and say that long code is bad, then justify your
design decisions on that basis, but with no other reasons.

[..]

 

[Jorge]

Dmitry A. Soshnikov wrote:
(...)

You. Crockford. Probably others.

Smith, you're as funny as a clown.

 

[Garrett Smith]

Smith, you're as funny as a clown.

I'm not interested in hearing silly immature bullcrap like that. If
youcan't grow up, well, seems to be a recurring problem with you.

I'm done with your childish crap. Go and have convo with Lahn.

*plonk*

 

[Jorge]

Dmitry A. Soshnikov wrote:
(...)
You. Crockford. Probably others.

I'm not interested in hearing silly immature bullcrap like that. If
you can't grow up, well, seems to be a recurring problem with you.

I'm done with your childish crap. Go and have convo with (your pick).

*plonk*

 

[Dmitry A. Soshnikov]

[snip useless (talk === demagogy)]

Why do you want to modify built-ins' or other objects?

Maybe want, maybe not - by situation. And if, then because of ideology
(come on, you should again ask: "What ideology?" - well, try to think
and understand it, if will be hard, please ask, I explain completely,
though, I've already explained) and because of that it's useful
syntactic sugar which is provided by the authors.

I can do that, or cannot - by situation. In one project when I have
own framework - I can do everything (including simply augmentation of
the built-ins), in other project (e.g. the current one, when ExtJS is
used) - we don't modify built-ins because ExtJS can do it also
(although, ExtJS does it in a strange way - something it does
augmenting built-ins, something - in own deep namspace).

Technically there's no difference:

capitalize(string);

or

string.capitalize();

Moreover, `capitalize(string)' is shorter on one dot - ".", but it's
not your case

Thought, even technically `string.capitalize()' in theory should be
resolved faster than global `capitalize(string)' and in own deep
namespace such as `Ext.util.Format.capitalize()'.

The only problem in that particular usage pattern is a minor performance
penalty.

Excuse me? Did I understand correctly that you said that new built-in
implementation will have minor performance when I switch on it from
the own `trim' implementation that I used before? Or it's just already
trolling is started (not even demagogy)?

Why would you want to use a hand-rolled version that doesn't behave as
standard?

I don't understand again - is it trolling or is it kind of
"privileged" humor? Did I understand correctly that you switch my (b)
and (a)? For what? If I've told - first (a), then (b).

[snip useless talk]

You. Crockford. Probably others.

Excuse me?

[snip useless talk]

Why do yo want to replace built-in function with your own?

I can't believe this (that's already not even funny , so no points
for you). It's already trolling but not demagogy. Again (please pay
maximum attention now and include your brain) - first (a), then (b),
but not the vice versa, ok? Good.

[snip useless talk]

This is seeming like a more and more of a waste of time.

Yes, by the truth I've already mentioned that and wanted to conclude
this talk.

You've got 0 rational argument

Ok, take a cookie (or cracker), you have deserved it. And yeah, learn
ECMAScript and its ideology and don't limit yourself with invariant
inflexible patterns which force you to write in ideology of Java. Be
flexible and use the language Dixi.

You are free with your document. You can sit and entertain yourself
with this document. You don't really think that some "code
reviewers" (Gee, you're guys looking for me, right? ) can judge me
and say any word about professional code if I'll augment built-ins in
own project, right? Good then. Dixi.

The talk is over. Good luck.

/ds

 

[Garrett Smith]

[snip useless (talk === demagogy)]

Why do you want to modify built-ins' or other objects?

Maybe want, maybe not - by situation. And if, then because of ideology
(come on, you should again ask: "What ideology?" - well, try to think
and understand it, if will be hard, please ask, I explain completely,
though, I've already explained) and because of that it's useful
syntactic sugar which is provided by the authors.

I can do that, or cannot - by situation. In one project when I have
own framework - I can do everything (including simply augmentation of
the built-ins), in other project (e.g. the current one, when ExtJS is
used) - we don't modify built-ins because ExtJS can do it also
(although, ExtJS does it in a strange way - something it does
augmenting built-ins, something - in own deep namspace).

Technically there's no difference:

capitalize(string);

or

string.capitalize();

Moreover, `capitalize(string)' is shorter on one dot - ".", but it's
not your case

Thought, even technically `string.capitalize()' in theory should be
resolved faster than global `capitalize(string)' and in own deep
namespace such as `Ext.util.Format.capitalize()'.

The only problem in that particular usage pattern is a minor performance
penalty.

Excuse me? Did I understand correctly that you said that new built-in
implementation will have minor performance when I switch on it from
the own `trim' implementation that I used before? Or it's just already
trolling is started (not even demagogy)?

I take you have believe that your hand-rolled trim will not be slower
than native trim. That would be a very inefficient native
implementation, to perform slower, no? Did you test your beliefs?

Fine; I guess you did not test, but believe like everything else that
you are ultimately correct.

I set up a test case.

Not all readers will have the foresight to see potential problems of
modifying foreign objects. However, most should be able to compare two
times and determine that the larger time means slower performance.

I've set up a test function that uses your hand-rolled "trim" method
renamed to "dcTrim" and compared the performance of that method (as
`String.prototype.dcTrim`), to native `trim` (`String.prototype.trim`).

// Your (Crockford's) hand-rolled function.
String.prototype.dcTrim = function(){
return this.replace(/^\s+|\s+$/g, "");
};

// Names of trim functions to test.
var trimNames = ["trim", "dcTrim"];

/* Accepts a name of a function to use for trimming, as in:
* stringArray[0][trimName]();
* and logs the result to the console.
*/
function testTrim(trimName){
// populate an array of strings
var data = [],
LEN = 1000000;
data.length = LEN;

// Populate an array of data with unique strings that need trimming.
for(var i = 0; i < LEN; i++) {
data = " \t \t new test " + (Math.random() * i) + " \t \t ";
}

// Trim the strings in the data.
var startTime = +new Date;
for(i = 0; i < LEN; i++) {
data = data[trimName]();
}
var totalTime = new Date-startTime; // end time.


// Get the next test in trimNames.
var next = trimNames.pop();
console.log(trimName + ": " + totalTime);
if(next)
setTimeout("testTrim('" + next + "')", 500);
};

void setTimeout("testTrim('" + trimNames.pop()+ "')", 500);

Results in Firefox 3.5:

dcTrim: 7027
trim: 2307

The native the user-defined "dcTrim" performed three times slower.
Since you won't normally trim that many strings, you won't be saving 5
seconds. That is why I fairly called it a "minor performance penalty".

I think it's clear now that your name calling (troll) is either very
short-sighted or is a desperate attempt to win the argument (so much for
the "truth").

I don't understand again - is it trolling or is it kind of
"privileged" humor? Did I understand correctly that you switch my (b)
and (a)? For what? If I've told - first (a), then (b).

I've asked for your motivation of why you prefer using a hand-rolled
trim over the native. Trying to get you to write code is like pulling teeth.

[snip useless talk]

You. Crockford. Probably others.

Excuse me?

[snip useless talk]

You've shown 0 good examples of your ideology put to practice (no code).

I've shown problems with programs that modifying objects they don't own.

Your arrogance isn't justified any more than that of "The world's
foremost authority on javascript" (that is what he calls himself, you know).

I can't believe this (that's already not even funny , so no points
for you). It's already trolling but not demagogy. Again (please pay
maximum attention now and include your brain) - first (a), then (b),
but not the vice versa, ok? Good.

I am not trolling but trying to explain things to an arrogant man who
just wants to name-call and won't show any code or any good examples of
API design, yet continues to lecture ideology.

[snip useless talk]

I'll tell you what is useless: Your ideology. Good for nothing.

Yes, by the truth I've already mentioned that and wanted to conclude
this talk.


Ok, take a cookie (or cracker), you have deserved it. And yeah, learn
ECMAScript and its ideology

Your idealistic philosophies and ideology, coupled with your arrogance
are getting in the way of rational decision making.

 

[Garrett Smith]

[snip useless (talk === demagogy)]

Please don't snip headers. Well I guess that is too much to expect from
one who writes fake code using Microsoft Word and publishes that on the
NG as arguments via Google Groups.

[snip]

Results in Firefox 3.5:

dcTrim: 7027
trim: 2307

The native the user-defined "dcTrim" performed three times slower. Since
you won't normally trim that many strings, you won't be saving 5
seconds. That is why I fairly called it a "minor performance penalty".

Correction:
not "native user-defined", just "user-defined".

 

[Dmitry A. Soshnikov]

On Jan 8, 1:34 am, Garrett Smith <[email protected]> wrote:

[snip useless (talk === demagogy)]

Why do you want to modify built-ins' or other objects?

Maybe want, maybe not - by situation. And if, then because of ideology
(come on, you should again ask: "What ideology?" - well, try to think
and understand it, if will be hard, please ask, I explain completely,
though, I've already explained) and because of that it's useful
syntactic sugar which is provided by the authors.

I can do that, or cannot - by situation. In one project when I have
own framework - I can do everything (including simply augmentation of
the built-ins), in other project (e.g. the current one, when ExtJS is
used) - we don't modify built-ins because ExtJS can do it also
(although, ExtJS does it in a strange way - something it does
augmenting built-ins, something - in own deep namspace).

Technically there's no difference:



Moreover, `capitalize(string)' is shorter on one dot - ".", but it's
not your case

Thought, even technically `string.capitalize()' in theory should be
resolved faster than global `capitalize(string)' and in own deep
namespace such as `Ext.util.Format.capitalize()'.

Excuse me? Did I understand correctly that you said that new built-in
implementation will have minor performance when I switch on it from
the own `trim' implementation that I used before? Or it's just already
trolling is started (not even demagogy)?

I take you have believe that your hand-rolled trim will not be slower
than native trim. That would be a very inefficient native
implementation, to perform slower, no? Did you test your beliefs?

Fine; I guess you did not test, but believe like everything else that
you are ultimately correct.

I set up a test case.

Not all readers will have the foresight to see potential problems of
modifying foreign objects. However, most should be able to compare two
times and determine that the larger time means slower performance.

I've set up a test function that uses your hand-rolled "trim" method
renamed to "dcTrim" and compared the performance of that method (as
`String.prototype.dcTrim`), to native `trim` (`String.prototype.trim`).

// Your (Crockford's) hand-rolled function.
String.prototype.dcTrim = function(){
   return this.replace(/^\s+|\s+$/g, "");

};

// Names of trim functions to test.
var trimNames = ["trim", "dcTrim"];

/* Accepts a name of a function to  use for trimming, as in:
  * stringArray[0][trimName]();
  * and logs the result to the console.
  */
function testTrim(trimName){
   // populate an array of strings
   var data = [],
      LEN = 1000000;
   data.length = LEN;

// Populate an array of data with unique strings that need trimming.
   for(var i = 0; i < LEN; i++) {
     data = " \t \t new test " + (Math.random() * i) + " \t \t";
   }

// Trim the strings in the data.
   var startTime = +new Date;
   for(i = 0; i < LEN; i++) {
     data = data[trimName]();
   }
   var totalTime = new Date-startTime; // end time.

  // Get the next test in trimNames.
   var next = trimNames.pop();
   console.log(trimName + ": " + totalTime);
   if(next)
     setTimeout("testTrim('" + next + "')", 500);

};

void setTimeout("testTrim('" + trimNames.pop()+ "')", 500);

Results in Firefox 3.5:

dcTrim: 7027
trim: 2307

The native the user-defined "dcTrim" performed three times slower.
Since you won't normally trim that many strings, you won't be saving 5
seconds. That is why I fairly called it a "minor performance penalty".

I think it's clear now that your name calling (troll) is either very
short-sighted or is a desperate attempt to win the argument (so much for
the "truth").

I don't understand again - is it trolling or is it kind of
"privileged" humor? Did I understand correctly that you switch my (b)
and (a)? For what? If I've told - first (a), then (b).

I've asked for your motivation of why you prefer using a hand-rolled
trim over the native. Trying to get you to write code is like pulling teeth.

[snip useless talk]

Who is here ignoring the known consequences?
You. Crockford. Probably others.

Excuse me?

[snip useless talk]

You've shown 0 good examples of your ideology put to practice (no code).

I've shown problems with programs that modifying objects they don't own.

Your arrogance isn't justified any more than that of "The world's
foremost authority on javascript" (that is what he calls himself, you know).

I can't believe this (that's already not even funny , so no points
for you). It's already trolling but not demagogy. Again (please pay
maximum attention now and include your brain) - first (a), then (b),
but not the vice versa, ok? Good.

I am not trolling but trying to explain things to an arrogant man who
just wants to name-call and won't show any code or any good examples of
API design, yet continues to lecture ideology.

[snip useless talk]

I'll tell you what is useless: Your ideology. Good for nothing.

Yes, by the truth I've already mentioned that and wanted to conclude
this talk.

Ok, take a cookie (or cracker), you have deserved it. And yeah, learn
ECMAScript and its ideology

Your idealistic philosophies and ideology, coupled with your arrogance
are getting in the way of rational decision making.

No-no-no, don't ask anymore crackers, that was the last one I gave to
you, I've told the talk is over.

You include already lie and slander stupidly repeating and bending
your own line, although I told, that first (a), then (b), but not vice
versa, so don't ask, I haven't any food for you, troll.

/ds

 

[Dmitry A. Soshnikov]

that is too much to expect from
one who writes fake code using Microsoft Word and publishes that on the
NG as arguments via Google Groups.

Demagogy. False. Weak trolling.

No-no, don't ask, your food is over.

/ds

 

[Jorge]

(...)

The user-defined "dcTrim" performed three times slower.
(...)

That's something Dmitry already knows. Probably you're the only one
among the regulars that feels the need to write such benchmark that,
besides, has nothing to do with what he was saying.

 

[Garrett Smith]

[snip useless (talk === demagogy)]

[snip]

Don't quote the entire message. Don't quote signatures.

No-no-no, don't ask anymore crackers, that was the last one I gave to
you, I've told the talk is over.

I have no idea what "asking crackers" means to you.

You include already lie and slander stupidly repeating and bending
your own line, although I told, that first (a), then (b), but not vice
versa, so don't ask, I haven't any food for you, troll.

No lies, no slander, and you've not explained how at all you got to
those conclusions, either.

Ad hominem makes discussion impossible and consequently degrade the
quality of this group. This group is supposed to be focused on technical
discussion. Try to let that concept sink in.