Velocity Reviews - Computer Hardware Reviews

Velocity Reviews > Newsgroups > Programming > Javascript > Code Guidelines

Reply
Thread Tools

Code Guidelines

 
 
Dmitry A. Soshnikov
Guest
Posts: n/a
 
      01-07-2010
On 7 янв, 09:59, Garrett Smith <(E-Mail Removed)> wrote:

[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?

> > 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?
>


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.

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


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
 
Reply With Quote
 
 
 
 
Garrett Smith
Guest
Posts: n/a
 
      01-07-2010
Dmitry A. Soshnikov wrote:
> On 7 янв, 09:59, Garrett Smith <(E-Mail Removed)> wrote:
>
> [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).
>
>> 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;"?
>


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.

>>> 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?
>>

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

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

>
> 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).
>
>> Is it difficult to use your own objects and not modify the built-ins?

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


I have no idea what your point is.

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


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.

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



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

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.

[..]
--
Garrett
comp.lang.javascript FAQ: http://jibbering.com/faq/
 
Reply With Quote
 
 
 
 
Jorge
Guest
Posts: n/a
 
      01-08-2010
On Jan 7, 11:34*pm, Garrett Smith <(E-Mail Removed)> wrote:
> Dmitry A. Soshnikov wrote:
> (...)
> > Who is here ignoring the known consequences?

>
> You. Crockford. Probably others.


Smith, you're as funny as a clown.
--
Jorge.
 
Reply With Quote
 
Garrett Smith
Guest
Posts: n/a
 
      01-08-2010
Jorge wrote:
> On Jan 7, 11:34 pm, Garrett Smith <(E-Mail Removed)> wrote:
>> Dmitry A. Soshnikov wrote:
>> (...)
>>> Who is here ignoring the known consequences?

>> You. Crockford. Probably others.

>
> 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*
--
Garrett
comp.lang.javascript FAQ: http://jibbering.com/faq/
 
Reply With Quote
 
Jorge
Guest
Posts: n/a
 
      01-08-2010
On Jan 7, 11:34 pm, Garrett Smith <(E-Mail Removed)> wrote:
> Dmitry A. Soshnikov wrote:
> (...)
> > Who is here ignoring the known consequences ?

> 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*
--
Jorge.
 
Reply With Quote
 
Dmitry A. Soshnikov
Guest
Posts: n/a
 
      01-08-2010
On Jan 8, 1:34*am, Garrett Smith <(E-Mail Removed)> 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:

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()'.

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


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]

> > Who is here ignoring the known consequences?

>
> 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
 
Reply With Quote
 
Garrett Smith
Guest
Posts: n/a
 
      01-08-2010
Dmitry A. Soshnikov wrote:
> On Jan 8, 1:34 am, Garrett Smith <(E-Mail Removed)> 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:
>
> 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()'.
>
>>> 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.
>>

>
> 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[i] = " \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[i] = data[i][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").

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


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

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


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.

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


Your idealistic philosophies and ideology, coupled with your arrogance
are getting in the way of rational decision making.
--
Garrett
comp.lang.javascript FAQ: http://jibbering.com/faq/
 
Reply With Quote
 
Garrett Smith
Guest
Posts: n/a
 
      01-08-2010
Garrett Smith wrote:
> Dmitry A. Soshnikov wrote:
>> On Jan 8, 1:34 am, Garrett Smith <(E-Mail Removed)> wrote:
>>
>> [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".

--
Garrett
comp.lang.javascript FAQ: http://jibbering.com/faq/
 
Reply With Quote
 
Dmitry A. Soshnikov
Guest
Posts: n/a
 
      01-09-2010
On Jan 9, 2:18*am, Garrett Smith <(E-Mail Removed)> wrote:
> Dmitry A. Soshnikov wrote:
> > On Jan 8, 1:34 am, Garrett Smith <(E-Mail Removed)> 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:

>
> > 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()'.

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

>
> > 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[i] = " \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[i] = data[i][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").
>
> >> 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).

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

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

>
> Your idealistic philosophies and ideology, coupled with your arrogance
> are getting in the way of rational decision making.
> --
> Garrett
> comp.lang.javascript FAQ:http://jibbering.com/faq/


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
 
Reply With Quote
 
Dmitry A. Soshnikov
Guest
Posts: n/a
 
      01-09-2010
On Jan 9, 2:30*am, Garrett Smith <(E-Mail Removed)> wrote:

> 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
 
Reply With Quote
 
 
 
Reply

Thread Tools

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

BB code is On
Smilies are On
[IMG] code is On
HTML code is Off
Trackbacks are On
Pingbacks are On
Refbacks are Off


Similar Threads
Thread Thread Starter Forum Replies Last Post
Code guidelines for checks ? nicolas.raoul@gmail.com Java 5 07-13-2007 04:47 PM
article - Guidelines for writing efficient C code Marco C Programming 19 04-12-2006 01:22 AM
Case Gallery rules and Guidelines Silverstrand Case Modding 0 06-20-2005 11:38 PM
Code Guidelines JIT ASP .Net 2 11-02-2004 06:57 AM
Java Code Convention Guidelines question... New Java 11 01-09-2004 07:48 PM



Advertisments