Velocity Reviews - Computer Hardware Reviews

Velocity Reviews > Newsgroups > Programming > Javascript > Code Guidelines

Reply
Thread Tools

Code Guidelines

 
 
Garrett Smith
Guest
Posts: n/a
 
      01-04-2010
Dmitry A. Soshnikov wrote:
> On 2 янв, 03:13, Garrett Smith <(E-Mail Removed)> wrote:
>
> [snip]
>> Modifying String.prototype has some not so good consequences. They are:
>> (1) greater likelihood to conflict with something else than
>> YourOwn.stringFormat.capitalize. (a) future version of ES, (b) other
>> third party libs. (2) is less clear about where it is defined.
>>

>
> Ok, let's conclude it. I completely understand that reasons (moreover,
> with some of them I agree and mentioned myself).
>
> What I was saying to you in this thread regarding to augmenting of
> built-ins - is about *formulation* of the answer. Taking into account
> that it's your article (or whatever it is) - you can write as you wish
> including formulation such as "Don't touch/augment object that you
> don't own".
>


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

> Meanwhile, I suggested (and would write myself if it was my article)
> something like this:
>
> "Be careful augmenting/modifying objects that's you don't own.
> Although, you can do this e.g. augmenting some built-ins (for getting
> new needed functionality with more useful, logical and elegant code)
> take in mind several well-known issues, main of which are: (a)
> Augmenting Object.prototype because (here small explanation) and (b)
> Using some 3rd-party libs (here again small explanations)."
>
> Without saying is it a good or bad practice.
>


The Code Guidelines document is for code reviews.

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

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

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


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

Not even Qooxdoo and Ext have such long namespaces.

[...]

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


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

[...]

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


Is the `captitalize` method related directly to strings, or is it about
formatting? Are there other types of formatting routines that may be
used in conjunction with that?
--
Garrett
comp.lang.javascript FAQ: http://jibbering.com/faq/
 
Reply With Quote
 
 
 
 
Dmitry A. Soshnikov
Guest
Posts: n/a
 
      01-05-2010
On 4 янв, 03:26, Jorge <(E-Mail Removed)> wrote:
> On Jan 3, 4:35*pm, "Dmitry A. Soshnikov" <(E-Mail Removed)>
> wrote:
>
> > (...)
> > And please keep in mind, I'm not asking you may I write so or not,
> > 'cause I repeat - I understand what I'm doing and why I'm doing so and
> > moreover, still repeat, that's just your own opinion with your own
> > issues (yeah, I understand that you'll always afraid that ES will (or
> > will not?) provide tomorrow (after several years) new method
> > `capitalize' in `String.prototype' and *you understanding that will
> > use
> > YourOwnNamespace.SomeGreatModules.ThisInternalModu le.ModuleForString.capita lize
> > () for that. Meanwhile me, understanding what that's all about and why
> > do I need this - will augment `String.prototype' with `capitalize' and
> > will use it. When after 5 years ES will provide the same method (and I
> > guess it will have similar functionality - just like with `trim' which
> > people use not the first year) - I'll use built-in method).

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


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


Yeah, funny

> 2nd.- Don't hard-code the name, do an indirection instead. For
> example:
> String.prototype[myApp.capitalize]= myApp.capitalizeFunction;
>
> And then use "a string"[myApp.capitalize](); //Access indirectly.
>


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

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


Yep, I think so too.

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

/ds
 
Reply With Quote
 
 
 
 
Dmitry A. Soshnikov
Guest
Posts: n/a
 
      01-05-2010
On 4 янв, 08:26, Garrett Smith <(E-Mail Removed)> 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
 
Reply With Quote
 
Thomas 'PointedEars' Lahn
Guest
Posts: n/a
 
      01-05-2010
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$(E-Mail Removed)>
 
Reply With Quote
 
Jorge
Guest
Posts: n/a
 
      01-05-2010
On Jan 5, 11:11*am, "Dmitry A. Soshnikov" <(E-Mail Removed)>
wrote:
> (...)
> P.S.: You forgot the 4th -
> YourOwnNamespace.SomeGreatModules.ThisInternalModu le.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.

 
Reply With Quote
 
Garrett Smith
Guest
Posts: n/a
 
      01-05-2010
Dmitry A. Soshnikov wrote:
> On 4 янв, 08:26, Garrett Smith <(E-Mail Removed)> 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/
 
Reply With Quote
 
Dmitry A. Soshnikov
Guest
Posts: n/a
 
      01-05-2010
On 5 янв, 21:51, Garrett Smith <(E-Mail Removed)> wrote:

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


Your should first tell it to yourself

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


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

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

> The consequences shown:
>
> 1) More likely to conflict with:
> * *a) code added by another contributor
> * *b) a third party library
> * *c) future ECMAScript specification/proposal
>
> 2) Not as clear as to *who owns that functionality or where the
> functionality is defined ("where is this method coming from?").
>
> It is also possible to create a dependency cycle. It is possible that
> the modification makes what should be internal information accessible to
> other code (e.g. adding a _listeners property to functions).
>


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

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

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


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

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

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

> The only benefits you provided are that you like it.


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

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

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

/ds
 
Reply With Quote
 
Garrett Smith
Guest
Posts: n/a
 
      01-05-2010
Dmitry A. Soshnikov wrote:
> On 5 янв, 21:51, Garrett Smith <(E-Mail Removed)> wrote:
>
>> Decisions of design are not merely matters of personal opinion or fancy.

>
> Your should first tell it to yourself
>


What?

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

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


Where did I propagate static language features?

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


I do not have programming fear. The arguments I have presented are
pretty logical. You've not shown counter for those, here:
>> The consequences shown:
>>
>> 1) More likely to conflict with:
>> a) code added by another contributor
>> b) a third party library
>> c) future ECMAScript specification/proposal
>>
>> 2) Not as clear as to who owns that functionality or where the
>> functionality is defined ("where is this method coming from?").
>>
>> It is also possible to create a dependency cycle. It is possible that
>> the modification makes what should be internal information accessible to
>> other code (e.g. adding a _listeners property to functions).
>>

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


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

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


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

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

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


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

It's possible
> to ask you to give answers *to me* (please pay attention in which
> style of dialog we'll talk) about all the other (built-in) methods. I
> also can continue just thinking out newer and newer reasons and
> justifies about position which I've choose, but I sure won't, 'cause
> there's no any reason to do so, I'm interested only in truth.
>
> And the truth here is: that's only your own (and I'm underlying -
> _humble_) opinion about programing on ECMAScript. Why have you decided
> that you can judgjing me and think that it's you who will choose what
> is correct and what is not?


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

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

I'm telling you, in my opinion that long
> crap such is Ext.util.Format.capitalize(string) - is really crap of ES
> programing. What's hard to understand? Please ask, I can answer and
> give explanations.
>


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

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


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

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


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

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


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

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

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

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

>> The only benefits you provided are that you like it.

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


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

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

It's just the one opinion which can turn out
> into the crap when you'll have some deep structure and will be forced
> to write
> YourOwnNamespace.SomeGreatModules.ThisInternalModu le.ModuleForString.capitalize
> ()
>
> Sure I like and prefer use logical and useful string.capitalize(); You
> can choose your own way and write the code which I really don't like
> (I'm again about Ext.util.Format.capitalize(string)).
>


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

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


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

Do you put that in a user-file "built-ins.js", "string-mods.js" or
"format.js". What is `capitalize being used for? The abstraction should
be closely related to the object it deals with. The abstraction might be
about how your application uses strings and not String in general.
--
Garrett
comp.lang.javascript FAQ: http://jibbering.com/faq/
 
Reply With Quote
 
Dmitry A. Soshnikov
Guest
Posts: n/a
 
      01-06-2010
On 6 янв, 02:39, Garrett Smith <(E-Mail Removed)> wrote:
> Dmitry A. Soshnikov wrote:
> > On 5 янв, 21:51, Garrett Smith <(E-Mail Removed)> wrote:

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

>
> > Your should first tell it to yourself

>
> What?
>


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

> >> Design decisions have consequences.

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

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

>
> Where did I propagate static language features?
>


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

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

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

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


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

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

>
> >> The consequences shown:

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

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

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

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

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


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

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

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


Which is equal, right? I've heard.

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

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

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


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

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

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

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


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

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

> We've been over the pros and cons and so far, the only pro is that you
> like being able to use `"foo".capitalize()`.
>
> I'm telling you, in my opinion that long
>
> > crap such is Ext.util.Format.capitalize(string) - is really crap of ES
> > programing. What's hard to understand? Please ask, I can answer and
> > give explanations.

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


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

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

YourOwnNamespace.SomeGreatModules.ThisInternalModu le.ModuleForString.capitalize
()
YourOwnNamespace.SomeGreatModules.ThisInternalModu le.ModuleForString.capitalize
()
YourOwnNamespace.SomeGreatModules.ThisInternalModu le.ModuleForString.capitalize
()
YourOwnNamespace.SomeGreatModules.ThisInternalModu le.ModuleForString.capitalize
()
YourOwnNamespace.SomeGreatModules.ThisInternalModu le.ModuleForString.capitalize
()
YourOwnNamespace.SomeGreatModules.ThisInternalModu le.ModuleForString.capitalize
()
YourOwnNamespace.SomeGreatModules.ThisInternalModu le.ModuleForString.capitalize
()
YourOwnNamespace.SomeGreatModules.ThisInternalModu le.ModuleForString.capitalize
()

If
(YourOwnNamespace.SomeGreatModules.ThisInternalMod ule.ModuleForString.capitalize
&&
YourOwnNamespace.SomeGreatModules.ThisInternalModu le.ModuleForString.capitalize
()) {

YourOwnNamespace.SomeGreatModules.ThisInternalModu le.ModuleForString.capitalize
()
} else {

YourOwnNamespace.SomeGreatModules.ThisInternalModu le.ModuleForString.capitaliz}

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

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

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


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

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

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


I've already told.

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

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


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

> It is usually very easy to avoid modifying objects that you don't own.
>
> In the case of String.prototype.capitalize, it is so easy that there
> doesn't even have to be very severe consequences in doing that to make
> avoiding it a serious consideration.
>
> It is trivial to create your own capitalize routine, but not replace the
> existing.
>


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

What the problem do you see?

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


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

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

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


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

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

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

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

/ds
 
Reply With Quote
 
Garrett Smith
Guest
Posts: n/a
 
      01-07-2010
Dmitry A. Soshnikov wrote:
> On 6 янв, 02:39, Garrett Smith <(E-Mail Removed)> wrote:
>> Dmitry A. Soshnikov wrote:
>>> On 5 янв, 21:51, Garrett Smith <(E-Mail Removed)> wrote:
>>>> Decisions of design are not merely matters of personal opinion or fancy.
>>> Your should first tell it to yourself

>> What?
>>

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


Who said that?

You
> describe some well-known issues


Is "dependency cycle" well known?

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

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


Full power?

>>>> Design decisions have consequences.
>>>> Design decisions based on the author thinking that the design is "cool"
>>>> often, and in this case, miss the consequences of those decisions.
>>> Listen, ECMAScript is designed to be dynamic and mutable. Why are you
>>> continue to propagate the static-language features just like you're
>>> the only one who is judging here? I repeat, I don't ask you and don't
>>> justify why can I do so (and will if it will be needed).

>> Where did I propagate static language features?
>>

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


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

There're some special patterns for most
> useful augmenting and so on – to use on full power the system (the
> language) on which you write.
>


Again with the full power.

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


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

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

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

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


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

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

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

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

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

A.js:

function A(){

}

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

A.prototype = new B;

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

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


Why not?

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


Did I ever suggest doing that?

Just because you always want to use some the only one patterns
> which is protected from all issues and which is the only way? What's
> the price for that? Code which looks overheated, too much detailed.
>


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

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

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


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


Still stands.

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


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

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

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

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

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



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

– for what uses `.trim.apply(someThing)" with own
> implementation? Sure if I need the way using as specified by ES5, I'll
> use ES5's implementation.
>

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

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

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

>
> Which is equal, right? I've heard.
>


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

Format
^
|
TableRenderer


TableRenderer depends on Format.

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



Format
^
|
TableRenderer
^
|
Format

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

>>>>> 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.
>>> You again started to use demagogy ("you not willing").

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

>
> What kind of "problem and code" are you talking about? I repeat, the
> most essential thing – is theory and *approach* to that. And from this
> point of view there could be several approaches which is best fit to
> situation, but not think out inflexible pattern which is always should
> be used writing that long lines.
>
>> It's possible
>>
>>> to ask you to give answers *to me* (please pay attention in which
>>> style of dialog we'll talk) about all the other (built-in) methods. I
>>> also can continue just thinking out newer and newer reasons and
>>> justifies about position which I've choose, but I sure won't, 'cause
>>> there's no any reason to do so, I'm interested only in truth.
>>> And the truth here is: that's only your own (and I'm underlying -
>>> _humble_) opinion about programing on ECMAScript. Why have you decided
>>> that you can judgjing me and think that it's you who will choose what
>>> is correct and what is not?

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

>
> Sure, and should I repeat that I completely understand all the issues?
> Should I? That I know about 3rd-party libs, Object.prototype and so
> on? What' the problem? If I know about that and if I understand what
> I'm doing – for what reason should I write such "long crap" instead of
> ideological and useful method call on object itself but not the long
> "YourOwnNamespace.SomeGreatModules.ThisInternalMod ule.ModuleForString.capitalize
> ()"?
>
> Just explain me why, taking into account that I completely understand
> all the issues. And if know that there will be no such situation, for
> what reason should I write by that inflexible invariant pattern which
> you think out to program in enemy environment, where it is not known,
> what libraries load, as why extend etc. - in general, uncontrollable
> system, where you should afraid of everything and for that's aim think
> out "cool" pattern which helps to avoid that (yeah, I understand that
> the price is – not so ideological and useful code).
>
>> We've been over the pros and cons and so far, the only pro is that you
>> like being able to use `"foo".capitalize()`.
>>
>> I'm telling you, in my opinion that long
>>
>>> crap such is Ext.util.Format.capitalize(string) - is really crap of ES
>>> programing. What's hard to understand? Please ask, I can answer and
>>> give explanations.

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

>
> You're using specially the most "strong" parts of my cites to show
> that I use some non-logical arguments, right? You can stop trying to
> do it, I've already appreciate it
>
> But I meant the following, then all the code is penetrated by lines
> such as (I let my self copy-paste one line):
>
> YourOwnNamespace.SomeGreatModules.ThisInternalModu le.ModuleForString.capitalize
> ()
> YourOwnNamespace.SomeGreatModules.ThisInternalModu le.ModuleForString.capitalize
> ()
> YourOwnNamespace.SomeGreatModules.ThisInternalModu le.ModuleForString.capitalize
> ()
> YourOwnNamespace.SomeGreatModules.ThisInternalModu le.ModuleForString.capitalize
> ()
> YourOwnNamespace.SomeGreatModules.ThisInternalModu le.ModuleForString.capitalize
> ()
> YourOwnNamespace.SomeGreatModules.ThisInternalModu le.ModuleForString.capitalize
> ()
> YourOwnNamespace.SomeGreatModules.ThisInternalModu le.ModuleForString.capitalize
> ()
> YourOwnNamespace.SomeGreatModules.ThisInternalModu le.ModuleForString.capitalize
> ()
>
> If
> (YourOwnNamespace.SomeGreatModules.ThisInternalMod ule.ModuleForString.capitalize
> &&
> YourOwnNamespace.SomeGreatModules.ThisInternalModu le.ModuleForString.capitalize
> ()) {
>
> YourOwnNamespace.SomeGreatModules.ThisInternalModu le.ModuleForString.capitalize
> ()
> } else {
>
> YourOwnNamespace.SomeGreatModules.ThisInternalModu le.ModuleForString.capitaliz}
>
> Of cause, it's can be in general with some other objects in the system
> and this question can be not related to the augmenting the built-ins,
> but I don't see any reason to do this with built-ins if I understand
> and know the system which I program.
>


A bunch of nonsense there.

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

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

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

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

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


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

?

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

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


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

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

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

>
> I've already told.
>


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

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

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

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


I have no idea what that means.

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


What ideology and what performance?

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

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

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

>> It is usually very easy to avoid modifying objects that you don't own.
>>
>> In the case of String.prototype.capitalize, it is so easy that there
>> doesn't even have to be very severe consequences in doing that to make
>> avoiding it a serious consideration.
>>
>> It is trivial to create your own capitalize routine, but not replace the
>> existing.
>>

>
> Why should I replace existing?


I really don't know.

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

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


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

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

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

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

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

>
> If all are taken into account, shouldn't. Why should? Why some should
> say me: "A-ha! You're modifying built-ins, your code is not
> professional, your code is not for production! A-ha!" Why I don't
> understand if I know why did I use so and by what reason.
>
>>> So, please write as you wish. When some then will judge somebody using
>>> this document, I'll tell that author of document and the person who
>>> will judge just understand ES from their own position (or even maybe
>>> don't completely understand).

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

>
> Well, I just can suggest to continue trying to understand that the
> system you use can be used on all power depends on situation and
> taking into account all the well-known issues.
>
> What's the problem? Did I say that I don't understand some of those
> issues? Did I, please answer?


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

Or maybe I really don't understand them?

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

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

> Or maybe I propagate and spread that: "Augment built-ins everywhere
> independent the exact case! I don't wanna listen about issues and I
> don't understand them!" Did I, please answer?
>
> I've told repeatedly that I completely understand what's the all about
> and why can I choose this that way, that I'm not limited by some
> invariant pattern which can protect from all the issues but with some
> special price for that – code which seems to me to overheated and odd
> for ECMAScript programming.
>
> I see that you operate with terms "you just like it, but my arguments
> are about concrete issues", right?


No, none whatsover.

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

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


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

You can say "be careful, the code modifies somebody else's object and
there are known problems with that." That is part of code review
guidelines.
--
Garrett
comp.lang.javascript FAQ: http://jibbering.com/faq/
 
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