Prev: Dynamic iframe caching problem workaround needed for Firefox
Next: JavaScript code mangler / scrambler / ... khm, more than obfuscator... :)
From: Dmitry A. Soshnikov on 5 Jan 2010 06:01
On 4 янв, 08:26, Garrett Smith <dhtmlkitc...(a)gmail.com> wrote:

[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
From: Thomas 'PointedEars' Lahn on 5 Jan 2010 06:23
Garrett Smith wrote:

> Asen Bozhilov wrote:
>> Garrett Smith wrote:
>>> Host Objects:
>>> * Operators:
>>> - DO not use delete operator with host object (IE Errors)
>>
>> That error can you see isn't only in IE. Try it code above in Firefox
>> 3.5:
>>
>> delete window.location; //Security error" code: "1000
>
> 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
--
Prototype.js was written by people who don't know javascript for people
who don't know javascript. People who don't know javascript are not
the best source of advice on designing systems that use javascript.
-- Richard Cornford, cljs, <f806at$ail$1$8300dec7(a)news.demon.co.uk>
From: Jorge on 5 Jan 2010 10:41
On Jan 5, 11:11 am, "Dmitry A. Soshnikov" <dmitry.soshni...(a)gmail.com>
wrote:
> (...)
> 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... :-)
--
Jorge.

From: Garrett Smith on 5 Jan 2010 13:51
Dmitry A. Soshnikov wrote:
> On 4 янв, 08:26, Garrett Smith <dhtmlkitc...(a)gmail.com> wrote:
>
> [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).

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

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.
--
Garrett
comp.lang.javascript FAQ: http://jibbering.com/faq/
From: Dmitry A. Soshnikov on 7 Jan 2010 15:18
On 7 янв, 09:59, Garrett Smith <dhtmlkitc...(a)gmail.com> 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 so if
you're free from well-known issues related to it.

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?

[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
First  |  Prev  |  Next  |  Last
Pages: 9 10 11 12 13 14 15 16 17 18 19 20 21
Prev: Dynamic iframe caching problem workaround needed for Firefox
Next: JavaScript code mangler / scrambler / ... khm, more than obfuscator... :)