«

Jonas Raoni wrote:
> Richard Cornford escreveu:
>> I have never seen a reason for using the -constructor - property
>> of any object, and where I have seen others use it the resulting
>> code ended up in a style that I would consider inappropriate to
>> javascript.
>
> Hmmm, I just remember of using it in a situation similar to this
> one:
>
> "" instanceof String
> "".constructor == String

But what situation is "similar to this one"? The - instanceof -
expression will always return false as its left hand side operand in not
an object type, so the whole expression may as well be substituted for
the expression - false -, and using - typeof - will be precisely as
discriminating but without the implied type-conversion of the string
primitive to a String object. There is also an issue of code clarity
here as the use of the non-obvious method introduces questions of why it
is being used, and what is going on that makes this necessary.

(The - instanceof - operator is also irrelevant in this context as it
makes no use of an object's - constructor - property anyway.)

> I could use typeof

And avoid the implied type-conversation, and its overheads, in the
process.

> (which also looks better, since it's a native
> type)

? What distinction are you trying to draw by labelling - typeof - a
"native type"?

>, but I preferred comparing the constructor with the given
> argument.
>
>> If there is no reason for using the property any effort to
>> "keep it intact" is futile and wasteful.
>
> I don't think so,

In javascript an assignment has to be a runtime activity. If the
activity serves no purpose then it is both futile and wasteful.

> I don't like to assume anything as world truth and,
> "fixing" it isn't what I can call a hard job :]

In any single project there is no need assume anything; if no code ever
references a - constructor - property there is no point in worrying
about what values that property may have. To date I have never written a
single line of code that used a - constructor - property in anger, and I
can see no reason for ever doing so. Your contrived example will not
change that as it is clearly inferior to the normal alternative.

>>> It's not something dangerous as can be prototyping the
>>> Array/Object, but *I* preffer to keep the features intact.
>>
>> I am generally expected to write efficient code, so I don't
>> have ti doe what is not needed or useful.
>
> It's ok, everybody has its own point of view.

Yes, though many share the point of view that actions taken in computer
programs should serve some known purpose known to the programmer.

>>>>> new function(){
>>>>> var o = Father.prototype;
>>>>> o.type = "father";
>>>>> };
>>>> And I don't see any point in doing that at all.
>>> Hmm, it's just a closure with a shortcut variable,
>>
>> There is no closure there. And the result of the expression is an
>> object that is not an instance of - Father -, does not have -
>> Father.protoype - on its prototype chain and does not have - Father
>> - as its - constructor -, so what is the point?
>
> Didn't you perceive the code purpose???

I perceived the action of the code, and your false assertion about a
closure. I did not perceive an reason for undertaking those actions in
that way.

> Some people like to do it this way:
>
> var o = Father.prototype;
> o.type = "father";
> o.name = "lala";
>
> Instead of writing:
>
> Father.prototype.type = "father";
> Father.prototype.name = "lala";

And you did neither.

> So, "o" is just a shortcut for the prototype, what I've
> done was just to enclose the variable inside the function
> to avoid collisions. And used "new function(){}" instead
> of "(function(){})()".

Yes, you have constructed and then discarded an object as an unnecessary
side effect of a choice of an inferior approach. If you want a private
scope to avoid naming conflicts the inline execution of a function
expression will give you that without creating a superfluous object as a
side effect.

And avoiding creating that superfluous object will also avoid other
programmers reading the code and wondering why an object is being
created with the - new - operator, and why it appears to be abandoned
immediately.

>>> something like
>>> this:
>>>
>>> with({o: a.prototype}){
>>> o.abc = 123;
>>> }
>>
>> Nor there.
>
> I won't explain the purpose again, it's the same.
>
> var o = 0;
> with({o: 1})
> o = 2;
> alert(o);
>
>
>>> Just other ways to avoid overwriting the constructor.
>>
>> If that was a useful thing to be doing then your earlier
>> methods make more sense.
>
> Ah, there are a lot of ways to do the same thing, fixing the
> constructor or not, it's up to you ^^

Yes, there is a great deal of choice in the approaches that may be
taken, and anything that can be done can always be done less efficiently
and less clearly.

Richard.

Richard Cornford escreveu:
> Jonas Raoni wrote:
>> Hmmm, I just remember of using it in a situation similar to this
>> one:
>>
>> "" instanceof String
>> "".constructor == String
>
> so the whole expression may as well be substituted for
> the expression - false -

In this specific case yes.

> and using - typeof - will be precisely as
> discriminating but without the implied type-conversion of the string
> primitive to a String object.

Oh my god, it's difficult to explain for you what I'm saying.

I'll let my example clear for you:

Assume two things from the above code

- *""* is the instance of an "user class", a primitive value, an object,
well, it can receive anything.

- *String* is always an object defining the type that I'm looking for...
Can be String, Number, Function, "Father"...

So as I will receive an object and not a string as the type variable, I
can't use the typeof, because I'll have the following situation:

typeof "" == String

Which will of course evaluate to false.

Without using "constructor == type", I would have to add specific things
for each native type as follows (of course I wouldn't write it this way):

type === String && typeof value == "string"


> There is also an issue of code clarity
> here as the use of the non-obvious method introduces questions of why it
> is being used, and what is going on that makes this necessary.

What non-obvious method?

> (The - instanceof - operator is also irrelevant in this context as it
> makes no use of an object's - constructor - property anyway.)

Did you understand what I wrote?

>> I could use typeof
>
> And avoid the implied type-conversation, and its overheads, in the
> process.

Hmmm, but tell me, where did you see a type-conversion in the following
expression?

/"".constructor == String/

"".constructor has the same type of String, well, they are the same
object, it's a simple comparison by reference, not by value, so the
toString/valueOf methods aren't called.

You can be sure of what I said by using the following code (I know it
isn't needed, but you didn't respected my low knowledge either...):

String.toString = function(){
alert("Wow, it's an overhead :O");
};

alert("".constructor == String);


>> (which also looks better, since it's a native
>> type)
>
> ? What distinction are you trying to draw by labelling - typeof - a
> "native type"?

Oh my god....

"" is a "native type", not the typeof.

> In javascript an assignment has to be a runtime activity. If the
> activity serves no purpose then it is both futile and wasteful.

Hmmm, but being not useful for you, doesn't mean that it's not useful
for everybody, this is the same that the creator of "Prototype" said to
me when I asked why he prototyped the Object and Array objects. About
the Object he said it was a mistake, but for the array, he said
something like this:

"The for..in statement shouldn't be used to make loops in arrays"

For him it's ok to kill a language feature, but it's not for me and
probably for others :]

>> I don't like to assume anything as world truth and,
>> "fixing" it isn't what I can call a hard job :]
>
> In any single project there is no need assume anything; if no code ever
> references a - constructor - property there is no point in worrying
> about what values that property may have.

You're talking just about your projects, aren't you?

> To date I have never written a
> single line of code that used a - constructor - property in anger, and I
> can see no reason for ever doing so.

It's really difficult to use it. But it's a feature, it's not ok to just
ignore it.

How do you create an instance from the same class of an object? Again
the "father" example...

var o = new Father;

Tell me how I can create a new Father without knowing the class of the
variable. This may be useful for someone, I never needed, but it's not
something that you should ignore, if I spend some time I can find a
place to use it, but I won't do it, it's too late here haha.

> Your contrived example will not
> change that as it is clearly inferior to the normal alternative.

Well, you're free to think whatever you want, if you still thinking that
my example isn't a good reason, ok.

Actually I didn't looked for it, I just needed to make that code, and
the constructor solved my problem ;]

>> It's ok, everybody has its own point of view.
>
> Yes, though many share the point of view that actions taken in computer
> programs should serve some known purpose known to the programmer.

;]

>>> - as its - constructor -, so what is the point?
>> Didn't you perceive the code purpose???
>
> I perceived the action of the code, and your false assertion about a
> closure. I did not perceive an reason for undertaking those actions in
> that way.

That's true, I just read the definition of a closure and what I've done
is just an encapsulation.

I got this term from somewhere after already knowing the feature, I
don't lose much time reading such definitions.

>> Some people like to do it this way:
>>
>> var o = Father.prototype;
>> o.type = "father";
>> o.name = "lala";
>>
>> Instead of writing:
>>
>> Father.prototype.type = "father";
>> Father.prototype.name = "lala";
>
> And you did neither.

Sure, it was you who wrote the example, not me :]

>> So, "o" is just a shortcut for the prototype, what I've
>> done was just to enclose the variable inside the function
>> to avoid collisions. And used "new function(){}" instead
>> of "(function(){})()".
>
> Yes, you have constructed and then discarded an object as an unnecessary
> side effect of a choice of an inferior approach.

Hahaha, "inferior approach" is a nice definition.

> If you want a private
> scope to avoid naming conflicts the inline execution of a function
> expression will give you that without creating a superfluous object as a
> side effect.

Well, this will create a superfluous function as well:

(function(){
var a, b, c;
})();

For sure it's more compact in terms of execution, but for the sake of
prettiness, I prefer this way:

new function(){
var a, b, c;
};

I don't see your point when talking about "efficiency" in such things,
they make no difference, what makes the difference is a nice idea. In a
typical web stuff, the difference time or parsing these codes is so
small that it can't be counted. It's the same as saying: use the
do..while instead of any other loop because it's faster.

If you're complaining about running several times this code and creating
a memory bubble, tests are needed, if the engine is smart, it will free
up these objects since they don't refer to anything. Anyway the other
way that you said has the same effect...

> And avoiding creating that superfluous object will also avoid other
> programmers reading the code and wondering why an object is being
> created with the - new - operator, and why it appears to be abandoned
> immediately.

Hmmm, in my opinion the programmer must know its languages.

If you keep this point of view, your programmer could see this code:
(function(){})();

And ask: "wow, is this an alien?"

Then see: new function(){};

"wow, is this an alien?"

And then: Father.prototype.type = "father";

I'm sure it's an alien!!!

If the person doesn't know the language, anything different from what
he's used to see will take some time to understand.

>> Ah, there are a lot of ways to do the same thing, fixing the
>> constructor or not, it's up to you ^^
>
> Yes, there is a great deal of choice in the approaches that may be
> taken, and anything that can be done can always be done less efficiently
> and less clearly.

Yeah.

I'm not against your code, this style is quite famous over the web, I
just said you can fix the constructor with some characters...

Father.prototype = {
type: "father",
:
constructor: Father
};


--
Jonas Raoni Soares Silva
http://www.jsfromhell.com

Jonas Raoni wrote:
> Richard Cornford escreveu:
>> Jonas Raoni wrote:
>>> Hmmm, I just remember of using it in a situation similar
>>> to this one:
>>>
>>> "" instanceof String
>>> "".constructor == String
>>
>> so the whole expression may as well be substituted for
>> the expression - false -
>
> In this specific case yes.

And all cases where - instanceof - operates upon primitive
values as its left hand operand.

>> and using - typeof - will be precisely as discriminating
>> but without the implied type-conversion of the string
>> primitive to a String object.
>
> Oh my god, it's difficult to explain for you what I'm saying.
>
> I'll let my example clear for you:
>
> Assume two things from the above code
>
> - *""* is the instance of an "user class",

So you write the code for an empty string and want readers
to interpret that as some uncertain value? traditionally
people use - foo - for that.

> a primitive value, an
> object, well, it can receive anything.

If the left hand side operand of a dot operator is one of
the primitive values Null or Undefined a runtime error will
result.

> - *String* is always an object defining the type that I'm looking
> for... Can be String, Number, Function, "Father"...
>
> So as I will receive an object and not a string as the
> type variable,

You mean an arbitrary function that may be used as a
constructor. That is not a likely interpretation of code
that uses the name of a specific constructor.

> I can't use the typeof, because I'll have the following
> situation:
>
> typeof "" == String
>
> Which will of course evaluate to false.

And you cannot use - .constructor - because it will generate
a runtime error with some primitive types. The situation you
describe requires more elaborate testing.

> Without using "constructor == type", I would have to
> add specific things for each native type as follows
> (of course I wouldn't write it this way):
>
> type === String && typeof value == "string"

Your initial premise if false. You should not design yourself
into a situation where you don't know the type, or set of types,
of values that are employed by your code. Even in the most
general cases you should know the set of types sufficiently
clearly to be able to discriminate between then directly, or
not care about the specific type and just employ an interface
common to the entire set.

>> There is also an issue of code clarity here as the use
>> of the non-obvious method introduces questions of
>> why it is being used, and what is going on that makes
>> this necessary.
>
> What non-obvious method?

Using the - constructor - property of the String object
type-converted from a string primitive to verify that the
original value was a string.

>> (The - instanceof - operator is also irrelevant in this context as it
>> makes no use of an object's - constructor - property anyway.)
>
> Did you understand what I wrote?

I understood what you wrote as an attempt to justify making
an effort to preserve the - constructor - properties of object.
In that context any reference to - instanceof - is irrelevant
as it does not employ the - constructor - property of objects
it operates upon.

>>> I could use typeof
>>
>> And avoid the implied type-conversation, and its overheads,
>> in the process.
>
> Hmmm, but tell me, where did you see a type-conversion in the
> following expression?
>
> /"".constructor == String/

The value of the expression to the left of a dot operator is
subject to the internal - ToObject - method, which will
type-convert a string primitive value into a String object.
You have placed a string primitive value to the left of the
dot in your property accessor so there is an implied
type-conversion from that string primitive to the String
object from which the - constructor property will be read.

<snip>
>>> (which also looks better, since it's a native
>>> type)
>>
>> ? What distinction are you trying to draw by labelling
>> - typeof - a "native type"?
>
> Oh my god....
>
> "" is a "native type", not the typeof.
>
>> In javascript an assignment has to be a runtime activity.
>> If the activity serves no purpose then it is both futile
>> and wasteful.
>
> Hmmm, but being not useful for you, doesn't mean that it's
> not useful for everybody,

Where the thing that you perceive as useful is only justified
in code that has been designed to be so chaotic that the
programmer has no idea at all what types of object they are
working with I don't see any reason for doing anything to
accommodate such a design. And with the code suitably
designed assigning to - constructor - is futile and wasteful.

> this is the same that the creator of "Prototype" said
> to me when I asked why he prototyped the Object and
> Array objects. About the Object he said it was a mistake,
> but for the array, he said something like this:

Given that recent changes in Prototype.js have taken it from
not being cross-browser in practice to not even being
ECMAScript compatible (so it could never be cross-browser)
the opinions of its author should not be of interest to anyone.

> "The for..in statement shouldn't be used to make loops
> in arrays"

That is not an uncommon "best practice" guideline.

> For him it's ok to kill a language feature, but it's not
> for me and probably for others :]

In a context where for-in loops are never used it does not
matter at all, while in a context where for-in loops are
used it may be _imperative_ that the prototypes of the
objects with which it is used are not extended. A general
absolute approach to javascript authoring would be the
mistake; the decision is context/design related and once
made must be absolutely followed in that context.

>>> I don't like to assume anything as world truth and,
>>> "fixing" it isn't what I can call a hard job :]
>>
>> In any single project there is no need assume anything;
>> if no code ever references a - constructor - property
>> there is no point in worrying about what values that
>> property may have.
>
> You're talking just about your projects, aren't you?

I am talking about any project. In any actual project there is
a finite set of known code; if something is true of that code
it can be know to be true of that code. The for-in loop is a
good example. The project I am working on now uses for-in
loops to enumerate (some very) sparse Arrays. The first page
of the client-side code documentation of the project states
that nobody is allowed to add code to the project that
extends the prototype of Array. That restriction is known to
apply to the code that is used, and has been stated as
applying.

>> To date I have never written a single line of code that
>> used a - constructor - property in anger, and I can see
>> no reason for ever doing so.
>
> It's really difficult to use it.

No, it is really easy to use, but unnecessary in practice.

> But it's a feature, it's not ok to
> just ignore it.

If it is never used it is foolish to not to ignore it.

> How do you create an instance from the same class of
> an object?

By applying the - new - operator to the same constructor.

> Again the "father" example...
>
> var o = new Father;
>
> Tell me how I can create a new Father without knowing the
> class of the variable.

When did I stop knowing the 'class' of the variable?

> This may be useful for someone, I never needed, but
> it's not something that you should ignore, if I spend
> some time I can find a place to use it, but I won't do
> it, it's too late here haha.

Being able to contrive an example where - constructor - may be
useful has no impact on its usefulness (or lack of usefulness)
in code where it is not employed.

>> Your contrived example will not change that as it
>> is clearly inferior to the normal alternative.
>
> Well, you're free to think whatever you want, if you still
> thinking that my example isn't a good reason, ok.
>
> Actually I didn't looked for it, I just needed to make that
> code, and the constructor solved my problem ;]

I am left suspecting that your "problem" followed from
inappropriate code design and that actions that "solved" the
problem only plastered over a more fundamental issue
following from the design flaw.

>>> It's ok, everybody has its own point of view.
>>
>> Yes, though many share the point of view that actions taken in
>> computer programs should serve some known purpose known to the
>> programmer.
>
> ;]
>
>>>> - as its - constructor -, so what is the point?
>>> Didn't you perceive the code purpose???
>>
>> I perceived the action of the code, and your false assertion
>> about a closure. I did not perceive an reason for undertaking
>> those actions in that way.
>
> That's true, I just read the definition of a closure and what
> I've done is just an encapsulation.
>
> I got this term from somewhere after already knowing the
> feature, I don't lose much time reading such definitions.

Which is fine so long as you do not use the terms that you
don't understand in an attempt to convey meaning to others.

>>> Some people like to do it this way:
>>>
>>> var o = Father.prototype;
>>> o.type = "father";
>>> o.name = "lala";
>>>
>>> Instead of writing:
>>>
>>> Father.prototype.type = "father";
>>> Father.prototype.name = "lala";
>>
>> And you did neither.
>
> Sure, it was you who wrote the example, not me :]
>
>>> So, "o" is just a shortcut for the prototype, what I've
>>> done was just to enclose the variable inside the function
>>> to avoid collisions. And used "new function(){}" instead
>>> of "(function(){})()".
>>
>> Yes, you have constructed and then discarded an object as an
>> unnecessary side effect of a choice of an inferior approach.
>
> Hahaha, "inferior approach" is a nice definition.
>
>> If you want a private
>> scope to avoid naming conflicts the inline execution of a function
>> expression will give you that without creating a superfluous object
>> as a side effect.
>
> Well, this will create a superfluous function as well:
>
> (function(){
> var a, b, c;
> })();

A function object is created, an Activation/Variable object
is also created when it is executed.

> For sure it's more compact in terms of execution, but for the
> sake of prettiness, I prefer this way:
>
> new function(){
> var a, b, c;
> };

Here function object is created, an Activation/Variable object
is also created when it is executed _and_ a Native ECMAScript
object is created, for no good reason.

> I don't see your point when talking about "efficiency" in
> such things, they make no difference,
> what makes the difference is a nice idea. In a typical web
> stuff, the difference time or parsing these codes is so
> small that it can't be counted. It's the same as saying:
> use the do..while instead of any other loop because it's faster.

You realise that you are saying that it is reasonable to take
action in all circumstances to preserve the - constructor -
properties of object just in case some circumstances arise
where someone may want to use them, and then arguing that
there is no need to consider the efficiency of code because
in most specific cases it does not matter?

> If you're complaining about running several times this code
> and creating a memory bubble, tests are needed, if the engine
> is smart, it will free up these objects since they don't refer
> to anything.

Browsers have notoriously low priority garbage collectors.

> Anyway the other way that you said has the same effect...

The inline execution of a functions Expression does not result
in the unnecessary creation of an entirely superfluous native
ECMAScript object.

>> And avoiding creating that superfluous object will also avoid
>> other programmers reading the code and wondering why an object
>> is being created with the - new - operator, and why it appears
>> to be abandoned immediately.
>
> Hmmm, in my opinion the programmer must know its languages.

Yes, so the programmer knows that the - new - operator is used
to create objects. And knowing that and seeing the - new -
operator used they should be questioning the role of this
newly created object and its place in the bigger picture.

> If you keep this point of view, your programmer could see this code:
> (function(){})();
>
> And ask: "wow, is this an alien?"

Only if they don't know what a function expression is, how
it is evaluated, and don't know that the result of such an
expression can be called directly.

> Then see: new function(){};
>
> "wow, is this an alien?"

But that is alien. The use of the - new - operator speaks of
object construction but any object construction is futile in
this context. It is the sort of code that is destined to
mislead/confuse because it is doing something in a way that
is unnecessary and has a significant side effect for no real
reason.

> And then: Father.prototype.type = "father";
>
> I'm sure it's an alien!!!
>
> If the person doesn't know the language, anything different
> from what he's used to see will take some time to understand.

And if a person does know the language anything done in an obtuse
and inefficient way when a better alternative is obvious will
also take some time to understand, because time would be spent
trying to see the reason for choosing the obscure and inefficient
method over the obvious one. And as there is no reason for using
your approach the time spent trying to identify the reasoning
could be indefinitely extended.

It is one thing to be writing code that novices take time to
understand but writing code that takes experienced programmers
time extra time and effort to understand is stupid.

>>> Ah, there are a lot of ways to do the same thing, fixing the
>>> constructor or not, it's up to you ^^
>>
>> Yes, there is a great deal of choice in the approaches that
>> may be taken, and anything that can be done can always be
>> done less efficiently and less clearly.
>
> Yeah.
>
> I'm not against your code, this style is quite famous over the
> web, I just said you can fix the constructor with some characters...
>
> Father.prototype = {
> type: "father",
>:
> constructor: Father
> };

And I said it was a waste of effort to do so as any code that
thought it needed that information would already be too flawed
for serious consideration.

Richard.

Richard Cornford escreveu:
> And all cases where - instanceof - operates upon primitive
> values as its left hand operand.

Yes.

>> Assume two things from the above code
>>
>> - *""* is the instance of an "user class",
>
> So you write the code for an empty string and want readers
> to interpret that as some uncertain value? traditionally
> people use - foo - for that.

I just gave an example of where I used, I wasn't supposed to give a
complete example or explain what was my code about, this only became
needed when you criticized it.

>> a primitive value, an
>> object, well, it can receive anything.
>
> If the left hand side operand of a dot operator is one of
> the primitive values Null or Undefined a runtime error will
> result.

Yes.

>> So as I will receive an object and not a string as the
>> type variable,
>
> You mean an arbitrary function that may be used as a
> constructor. That is not a likely interpretation of code
> that uses the name of a specific constructor.

It was an idiot code to simulate overloading of functions based on the
types of the arguments.

>> type === String && typeof value == "string"
> Even in the most general cases you should know the set of types sufficiently
> clearly to be able to discriminate between then directly, or
> not care about the specific type and just employ an interface
> common to the entire set.

But why? Every problem has a different solution. It's strange to impose
your techniques as being the right way of doing things.

>> What non-obvious method?
>
> Using the - constructor - property of the String object
> type-converted from a string primitive to verify that the
> original value was a string.

Ah, for me it's ok, like 0.0.toFixed()

>> /"".constructor == String/
>
> The value of the expression to the left of a dot operator is
> subject to the internal - ToObject - method

It makes total sense, I didn't read the spec, so I thought everything
was Object, even the native types. But it makes sense to do it this way
too, since it will probably increase the speed. Anyway, in my opinion
it's not the case of saying it's an overhead.

>>> In javascript an assignment has to be a runtime activity.
>>> If the activity serves no purpose then it is both futile
>>> and wasteful.
>> Hmmm, but being not useful for you, doesn't mean that it's
>> not useful for everybody,
>
> Where the thing that you perceive as useful is only justified
> in code that has been designed to be so chaotic that the
> programmer has no idea at all what types of object they are
> working with I don't see any reason for doing anything to
> accommodate such a design. And with the code suitably
> designed assigning to - constructor - is futile and wasteful.

Well, I will not agree with you that it's ok to ignore it, so this
discussion will have no end.

If it's not useful in your opinion, ignore, I won't. I've made a code
using the constructor, maybe another person have done it too, so if you
change the expected behavior, things get confused.

> Given that recent changes in Prototype.js have taken it from
> not being cross-browser in practice to not even being
> ECMAScript compatible (so it could never be cross-browser)

I watched an old version, it didn't interested me. Anyway I don't blame
the author, he just made a library and by the way obtained success/fame.
If a guilty is needed for spreading this crap, I can only see the users.

> the opinions of its author should not be of interest to anyone.

This is bad, opinions shouldn't be ignored.

>> "The for..in statement shouldn't be used to make loops
>> in arrays"
>
> That is not an uncommon "best practice" guideline.

Such loop is slower too, but I think it shouldn't be killed.

>> For him it's ok to kill a language feature, but it's not
>> for me and probably for others :]
>
> In a context where for-in loops are never used it does not
> matter at all, while in a context where for-in loops are
> used it may be _imperative_ that the prototypes of the
> objects with which it is used are not extended.

If you're making something to will be shared with people or that will be
managed by others in the future, then I'm against killing features,
everything should be conserved to avoid remaking working codes. It's
just my best practice rule, you don't need to agree with that.

>> You're talking just about your projects, aren't you?
>
> The first page
> of the client-side code documentation of the project states
> that nobody is allowed to add code to the project that
> extends the prototype of Array. That restriction is known to
> apply to the code that is used, and has been stated as
> applying.

If you/your client have conditions to manage that, it's ok. I still
prefer to not do things that can damage others.

>>> To date I have never written a single line of code that
>>> used a - constructor - property in anger, and I can see
>>> no reason for ever doing so.
>> It's really difficult to use it.
>
> No, it is really easy to use, but unnecessary in practice.

Difficult = difficult to see a place to use it.

I can't say it's unnecessary, as well I can't say the eval is unnecessary.

>> But it's a feature, it's not ok to
>> just ignore it.
>
> If it is never used it is foolish to not to ignore it.

This is your way of seeing things in JavaScript. It seems that for you
it's fine to prototype the Object if you don't have any for..in
statement. For me it's not.

>> How do you create an instance from the same class of
>> an object?
>
> By applying the - new - operator to the same constructor.
>
>> Again the "father" example...
>>
>> var o = new Father;
>>
>> Tell me how I can create a new Father without knowing the
>> class of the variable.
>
> When did I stop knowing the 'class' of the variable?

There's no "when", I just pointed out a possibility.

If it's not your way of doing things (unknown 'classes'), fine.
I'm talking generally, so if it's useful for someone, then it's enough
for me, it doesn't matter if the person is doing something wrong in your
opinion, I just try to avoid messing with external codes.

> Being able to contrive an example where - constructor - may be
> useful has no impact on its usefulness (or lack of usefulness)
> in code where it is not employed.

Ok, I already know your point of view, mine one is different.

>> Actually I didn't looked for it, I just needed to make that
>> code, and the constructor solved my problem ;]
>
> I am left suspecting that your "problem" followed from
> inappropriate code design and that actions that "solved" the
> problem only plastered over a more fundamental issue
> following from the design flaw.

Well, you're free to suspect. For me the code is ok, the other way (with
typeof) will require some changes that won't give me any real benefit.

>> I got this term from somewhere after already knowing the
>> feature, I don't lose much time reading such definitions.
>
> Which is fine so long as you do not use the terms that you
> don't understand in an attempt to convey meaning to others.

Fine, but I'll use it again and again, even now, that I know the real
definition, because the main attribute for me it's enclosing variables,
so, when you see me talking closure again, you'll know the meaning xD

>> (function(){
>> var a, b, c;
>> })();
>
> A function object is created, an Activation/Variable object
> is also created when it is executed.
>>
>> new function(){
>> var a, b, c;
>> };
>
> Here function object is created, an Activation/Variable object
> is also created when it is executed _and_ a Native ECMAScript
> object is created, for no good reason.

Will this kill my computer? I'll keep doing it as it looks nice for me :]
Creating a new wasteful empty object isn't something that makes me feel
worried.

> You realise that you are saying that it is reasonable to take
> action in all circumstances to preserve the - constructor -
> properties of object just in case some circumstances arise
> where someone may want to use them

Yes, that's my point of view.

> and then arguing that
> there is no need to consider the efficiency of code because
> in most specific cases it does not matter?

No, it's a common sense that every code should be done as efficient,
small and clean as possible.

But changing "(function(){})()" to "new function(){}" is something that
won't affect the efficiency of my codes, a good idea can speed up things
in a higher factor, but such change, won't change in nothing, I prefer
to keep the cute way :]

>> Anyway the other way that you said has the same effect...
>
> The inline execution of a functions Expression does not result
> in the unnecessary creation of an entirely superfluous native
> ECMAScript object.

same effect = create something wasteful.

I know they aren't equal, but for me there's no significant difference
that forces me to use one and not the other.

>> Hmmm, in my opinion the programmer must know its languages.
>
> Yes, so the programmer knows that the - new - operator is used
> to create objects. And knowing that and seeing the - new -
> operator used they should be questioning the role of this
> newly created object and its place in the bigger picture.

Yes, such code is so strange, the "new" in front of the function will
destroy the mind of someone hahaha. It's soooo wrong, I'm feeling
ashamed of posting it :'/

If nothing is being assigned and if the this isn't stored anywhere, the
object is wasteful, there's nothing to think about it...

> And if a person does know the language anything done in an obtuse
> and inefficient way when a better alternative is obvious will
> also take some time to understand, because time would be spent
> trying to see the reason for choosing the obscure and inefficient
> method over the obvious one. And as there is no reason for using
> your approach the time spent trying to identify the reasoning
> could be indefinitely extended.

There's really no reason to do it, I do it because it looks more pretty
for me :]

> It is one thing to be writing code that novices take time to
> understand but writing code that takes experienced programmers
> time extra time and effort to understand is stupid.

Both doesn't matter for me, I program for fun... xD

This means I won't change my style to make the code more readable or
change the way I initialize things because it creates a ghost object,
whatever... I change something only when it has a visible impact.

>> Father.prototype = {
>> type: "father",
>> :
>> constructor: Father
>> };
>
> And I said it was a waste of effort to do so as any code that
> thought it needed that information would already be too flawed
> for serious consideration.

I'll keep my things safe, if you have manuals ordering people to not do
things and if they follow, you can program in the other way "if it's not
being used, you can change it" :]


PS: Again you made me lost a lot of time... I was going to ignore this
message, but I answered, but now I'm regretted, so if you answer, I'll
ignore it, since there's nothing useful in this discussion, it's over,
there's just a bunch of personal opinions that don't match.


--
Jonas Raoni Soares Silva
http://www.jsfromhell.com

Jonas Raoni said the following on 11/29/2006 1:32 AM:

<snip>

> PS: Again you made me lost a lot of time... I was going to ignore this
> message, but I answered, but now I'm regretted, so if you answer, I'll
> ignore it, since there's nothing useful in this discussion, it's over,
> there's just a bunch of personal opinions that don't match.

Jonas, meet Richard. There are typically two opinions, Richards and the
wrong one.

--
Randy
Chance Favors The Prepared Mind
comp.lang.javascript FAQ - http://jibbering.com/faq
Javascript Best Practices - http://www.JavascriptToolbox.com/bestpractices/

Randy Webb escreveu:
> Jonas, meet Richard.

Hmm, I'm quite far and I don't like discussing things about computers in
real life, in fact I hate when I see people discussing it near me out of
the job :]

> There are typically two opinions, Richards and the
> wrong one.

Hahaha, I don't agree with his opinion and mine one isn't the wrong,
this also doesn't mean that his opinion is wrong, they are different
views, you have to choose to one most suitable for you ;]


--
Jonas Raoni Soares Silva
http://www.jsfromhell.com

Jonas Raoni wrote:
> Randy Webb escreveu:
>> Jonas, meet Richard.
>
> Hmm, I'm quite far and I don't like discussing things about
> computers in real life, in fact I hate when I see people
> discussing it near me out of the job :]
<snip>

Then why are you posting to (and presumably reading) a discussion group
dedicated to a computer programming language?

Richard.

Jonas Raoni wrote:
> Richard Cornford escreveu:
>> Jonas Raoni wrote:
<snip>
>>> - *""* is the instance of an "user class",
>>
>> So you write the code for an empty string and want readers
>> to interpret that as some uncertain value? traditionally
>> people use - foo - for that.
>
> I just gave an example of where I used,

But not a good example as the same discrimination can be achieved with
typeof. If an effort is to be made to preserver the - constructor -
property in an inheritance tree then the example that may justify it
should relate to testing objects not string primitives.

> I wasn't supposed to give a complete example or explain
> what was my code about, this only became needed when you
> criticized it.

I may not have criticised it if you had managed to provide a example
that could not be trivially replaced with a more efficient alternative.

>>> a primitive value, an
>>> object, well, it can receive anything.
>>
>> If the left hand side operand of a dot operator is one of
>> the primitive values Null or Undefined a runtime error will
>> result.
>
> Yes.

With the implication that using the - constructor - property to test the
value of a genuinely unknown type is not safe unless it follows another
test that ensures the type-conversion to object does not error out.

>>> So as I will receive an object and not a string as the
>>> type variable,
>>
>> You mean an arbitrary function that may be used as a
>> constructor. That is not a likely interpretation of code
>> that uses the name of a specific constructor.
>
> It was an idiot code to simulate overloading of functions
> based on the types of the arguments.

That response seems disconnected from its context.

>>> type === String && typeof value == "string"
>> Even in the most general cases you should know the set
>> of types sufficiently clearly to be able to discriminate
>> between then directly, or not care about the specific
>> type and just employ an interface common to the entire
>> set.
>
> But why?

Because you are programming and the objects you use don't just appear
out of thin air.

> Every problem has a different solution.

And for every good solution there are a dozen worse solution.

> It's strange to impose your techniques as being the
> right way of doing things.

In what sense could I impose any technique on you (short of your working
for my employer)? Most programmers are interested in how to do things
better, if you are not that is your problem, but I will still point it
out when I see it.

>>> What non-obvious method?
>>
>> Using the - constructor - property of the String object
>> type-converted from a string primitive to verify that the
>> original value was a string.
>
> Ah, for me it's ok, like 0.0.toFixed()

If you want the string that results from calling - toFiexed - on a
Number object and you have a variable with a number primitive value to
start with then you have no better choice (except maybe doing the
implied type-conversion explicitly for clarity). But your method of
testing the type of string primitives is non-obvious and inefficient in
comparison to - typeof.

>>> /"".constructor == String/
>>
>> The value of the expression to the left of a dot operator is
>> subject to the internal - ToObject - method
>
> It makes total sense, I didn't read the spec, so I thought
> everything was Object, even the native types.

Javascript's object type is a "native type".

> But it makes sense to do it this
> way too, since it will probably increase the speed.
> Anyway, in my opinion it's not the case of saying it's
> an overhead.

Needlessly brining an object into existence is an overhead. You can
argue that it is not a very large overhead but it is still an overhead.

>>>> In javascript an assignment has to be a runtime activity.
>>>> If the activity serves no purpose then it is both futile
>>>> and wasteful.
>>> Hmmm, but being not useful for you, doesn't mean that it's
>>> not useful for everybody,
>>
>> Where the thing that you perceive as useful is only justified
>> in code that has been designed to be so chaotic that the
>> programmer has no idea at all what types of object they are
>> working with I don't see any reason for doing anything to
>> accommodate such a design. And with the code suitably
>> designed assigning to - constructor - is futile and wasteful.
>
> Well, I will not agree with you that it's ok to ignore it, so
> this discussion will have no end.

The discussion can have an end. You could attempt to demonstrate the
necessity and either succeed in demonstrating it (which would convince
me) or I could show that your necessity was an illusion and you would no
longer have any justification.

That probably would not work in practice as you don't seem to see that
you should not be programming things that you cannot justify.

> If it's not useful in your opinion, ignore, I won't. I've
> made a code using the constructor, maybe another person
> have done it too, so if you change the expected behavior,
> things get confused.

Why? I cannot change the code in the system you wrote.

>> Given that recent changes in Prototype.js have taken it from
>> not being cross-browser in practice to not even being
>> ECMAScript compatible (so it could never be cross-browser)
>
> I watched an old version, it didn't interested me. Anyway I don't
> blame the author, he just made a library and by the way obtained
> success/fame.

Infamy at least.

> If a guilty is needed for spreading this crap, I can
> only see the users.

Has the author told them that the library is not ECMAScript compatible?
Isn't it more likely the case that he is not aware himself?

>> the opinions of its author should not be of interest
>> to anyone.
>
> This is bad, opinions shouldn't be ignored.

If people don't know what they are doing any opinions they express about
how it should be done cannot be informed and so should not be taken
seriously.

>>> "The for..in statement shouldn't be used to make loops
>>> in arrays"
>>
>> That is not an uncommon "best practice" guideline.
>
> Such loop is slower too, but I think it shouldn't be killed.

It is not slower when enumeration the assigned values in a sparse array.
For example:-

var ar = [];
ar[5555555555555] = 5;

for(var n in ar){
// code here is only executed once.
}

for(var c = 0;c < ar.length;++c)[
// code here is executed 5555555555556 times,
// and ar[c] is undefined in most of those loops.
}

The former will be much faster.

>>> For him it's ok to kill a language feature, but it's not
>>> for me and probably for others :]

It is OK if you know you have done it and are willing to deal with the
consequences.

>> In a context where for-in loops are never used it does not
>> matter at all, while in a context where for-in loops are
>> used it may be _imperative_ that the prototypes of the
>> objects with which it is used are not extended.
>
> If you're making something to will be shared with people
> or that will be managed by others in the future, then I'm
> against killing features,

If the people using or maintaining the code know what they are dealing
with then it doesn't matter. They would be wrong to introduce code that
either broke because of the existing system, or broke the existing
system, but they would know not to do that.

> everything should be conserved to avoid remaking working
> codes. It's just my best practice rule, you don't need to
> agree with that.

No I don't need to agree. I believe that not writing code that serves no
useful purpose if better practice.

>>> You're talking just about your projects, aren't you?

You are editing the material you quote without marking your edits. That
is disingenuous.

>> The first page
>> of the client-side code documentation of the project states
>> that nobody is allowed to add code to the project that
>> extends the prototype of Array. That restriction is known to
>> apply to the code that is used, and has been stated as
>> applying.
>
> If you/your client have conditions to manage that, it's ok.

You mean like requiring future developers to read the documentation (or
at least its introduction) before they start coding for the system?
Well, yes we have conditions to manage that.

> I still
> prefer to not do things that can damage others.

And you don't think encouraging people to waste their time would qualify
as damaging them?

>>>> To date I have never written a single line of code that
>>>> used a - constructor - property in anger, and I can see
>>>> no reason for ever doing so.
>>> It's really difficult to use it.
>>
>> No, it is really easy to use, but unnecessary in practice.
>
> Difficult = difficult to see a place to use it.

That is a characteristic of things that are unnecessary.

> I can't say it's unnecessary, as well I can't say the eval
> is unnecessary.

Eval is unnecessary, it is just occasionally a small/fast alternative to
doing your own tokenising and parsing. But easily the vast majority of -
eval - uses in the real world follow directly from a script author not
knowing, or preferring not to use, a better alternative. As a result -
eval - use if often indicative of poorly designed code. In the same way
code that thinks it needs to be so interested in object types that it is
looking at - constructor - properties is also a symptom of not knowing,
or preferring not to use, better alternatives, and also indicative of
poorly designed code.

>>> But it's a feature, it's not ok to
>>> just ignore it.
>>
>> If it is never used it is foolish to not to ignore it.
>
> This is your way of seeing things in JavaScript.

Yes, being able to see what is irrelevant help in narrowing down to what
is important.

> It seems that for you it's fine to prototype the
> Object if you don't have any for..in
> statement.

Yes, you cannot do both without having to jump through hoops to mitigate
(and probably losing the benefits of for-in with sparse arrays along the
way), but either are reasonable in the absence of the other.

> For me it's not.

You give up a great deal of javascript's flexibility in taking that
position. And if you insist on worrying about the consequences of
aggregating code from diverse sources without understanding that code
you end up in a position where you don't extend prototypes out of fear
of the consequences, but you also cannot use for-in (at all, or without
testing each value retrieved) because others may have extended
prototypes.

>>> How do you create an instance from the same class of
>>> an object?
>>
>> By applying the - new - operator to the same constructor.
>>
>>> Again the "father" example...
>>>
>>> var o = new Father;
>>>
>>> Tell me how I can create a new Father without knowing the
>>> class of the variable.
>>
>> When did I stop knowing the 'class' of the variable?
>
> There's no "when", I just pointed out a possibility.

If it is reasonable to ask "how I can create a new Father without
knowing the class of the variable" then there must be a "when". I knew
the type of the variable when I wrote;-

var o = new Father;

- so in order to be in a position where I don't know the type of the
variable there must have been a point when I stopped knowing its type.
If there was never a "when" your question becomes moot as I am never in
a position where I don't know the type of variable.

> If it's not your way of doing things (unknown 'classes'),
> fine.

Well, it certainly is my "way" to understand what the code I am writing
is doing.

> I'm talking generally, so if it's useful for someone, then
> it's enough for me, it doesn't matter if the person is doing
> something wrong in your opinion, I just try to avoid messing
> with external codes.

How is this "external code" going to have a problem with the class
definitions you create? It is not going to know of there existence and
if you are passing objects of your classes into it it is going to be
quite important that it does not have strong attitude about the types it
receives, else it will just reject your objects as being outside its
knowledge.

Here is the advantage of interfaces (and the ease with which any 'class'
defined in javascript can implement any interface at all, or have one
added to it with augmentation). All your external code has to do is
define an interface which it expects objects passed into it to implement
and then you create 'classes' with that interface. Now you can pass
objects back and forth without either side having to have a strong
interest in the types of the actual objects used.

>> Being able to contrive an example where - constructor -
>> may be useful has no impact on its usefulness (or lack
>> of usefulness) in code where it is not employed.
>
> Ok, I already know your point of view, mine one is different.
>
>>> Actually I didn't looked for it, I just needed to make that
>>> code, and the constructor solved my problem ;]
>>
>> I am left suspecting that your "problem" followed from
>> inappropriate code design and that actions that "solved" the
>> problem only plastered over a more fundamental issue
>> following from the design flaw.
>
> Well, you're free to suspect.

I have little choice.

> For me the code is ok, the other way (with typeof)
> will require some changes that won't give me any real
> benefit.

Changes would only be necessary because of the way you wrote it in the
first place.

>>> I got this term from somewhere after already knowing the
>>> feature, I don't lose much time reading such definitions.
>>
>> Which is fine so long as you do not use the terms that you
>> don't understand in an attempt to convey meaning to others.
>
> Fine, but I'll use it again and again, even now, that I
> know the real definition, because the main attribute for
> me it's enclosing variables,

Didn't you say; "I still prefer to not do things that can damage
others"? Doesn't inappropriately applying technical terminology in front
of novices risk misleading them, and thus doing them harm.

> so, when you see me talking closure again, you'll know the
> meaning xD

The consequence will be repeated corrections, and in needing repeated
correction you will be depriving the more deserving of the time taken to
repeatedly correct you (thus harming them).

>>> (function(){
>>> var a, b, c;
>>> })();
>>
>> A function object is created, an Activation/Variable
>> object is also created when it is executed.
>>>
>>> new function(){
>>> var a, b, c;
>>> };
>>
>> Here function object is created, an Activation/Variable
>> object is also created when it is executed _and_ a Native
>> ECMAScript object is created, for no good reason.
>
> Will this kill my computer?

If you do it often enough.

> I'll keep doing it as it looks nice for me :]

Aesthetics are rarely good criteria for code design decisions.

> Creating a new wasteful empty object isn't something
> that makes me feel worried.
>
>> You realise that you are saying that it is reasonable
>> to take action in all circumstances to preserve the
>> - constructor - properties of object just in case some
>> circumstances arise where someone may want to use them
>
> Yes, that's my point of view.
>
> > and then arguing that
>> there is no need to consider the efficiency of code
>> because in most specific cases it does not matter?
>
> No, it's a common sense that every code should be done
> as efficient, small and clean as possible.

Not really, clarity if often an important criteria. The 'common sense'
is not to write code that does things that don't need doing and don't
have to be done. However, doing that does negatively impact code size,
efficiency and cleanness in addition to clarity.

> But changing "(function(){})()" to "new function(){}" is
> something that won't affect the efficiency of my codes, a
> good idea can speed up things in a higher factor, but such
> change, won't change in nothing, I prefer to keep the cute
> way :]

No single action is likely to significantly impact performance, but here
we have been discussing various things and you:-

1. Want to spend time assigning - constructor - values regardless of
whether of not they will ever be used.

2. Would prefer ''.constructor == String over typeof '' == 'string',
regardless of the implied need for the type-conversion, and construction
of an unnecessary object as a consequence.

3. Want to use - new - when you only need the private scope that
executing a function expression will give you, regardless of the
superfluous extra object created as a consequence.

And that is; in every aspect of scripting we have discussed in this
thread you are preferring a less efficient/more wasteful approach than
you could use. Individually none is likely to make much difference, but
taken together, and particularly if this pattern of preferring the less
efficient is carried through the rest of your code, they will add up.

The "big idea" may have a significant impact upon performance, but not
habitually writing universally inefficient code might save you needing
the 'big idea' in the first place.

>>> Anyway the other way that you said has the same effect...
>>
>> The inline execution of a functions Expression does not
>> result in the unnecessary creation of an entirely
>> superfluous native ECMAScript object.
>
> same effect = create something wasteful.

The execution of a function expression creates a number of objects,
exactly the same number as the execution of a constructor body implied
in the use of the - new - operator. Those objects are the price of
having a private scope and so if you want a private scope you pay that
price whatever you do. There is no waste in that, just a known cost.

Using the - new - operator on a function expression creates an
additional object, which is redundant if all you want is a private
scope.

> I know they aren't equal, but for me there's no significant
> difference that forces me to use one and not the other.

But that just means that your perception of aesthetics outweighs the
waste in needlessly creating a superfluous object in your mind.

>>> Hmmm, in my opinion the programmer must know its languages.
>>
>> Yes, so the programmer knows that the - new - operator
>> is used to create objects. And knowing that and seeing
>> the - new - operator used they should be questioning the
>> role of this newly created object and its place in the
>> bigger picture.
>
> Yes, such code is so strange, the "new" in front of the
> function will destroy the mind of someone hahaha.

It won't destroy their mind, it will make then think of the creation of
objects, and, given that programmed action is normally driven by
imperative, look for the reasoning that makes this object creation
necessary/desirable.

> It's soooo wrong, I'm feeling
> ashamed of posting it :'/

If only I believed you could see that.

> If nothing is being assigned and if the this isn't
> stored anywhere, the object is wasteful, there's
> nothing to think about it...

Yes, everything that is being done can be done without creating the
superfluous object by no greater change than the removal of the - new -
operator and the addition of some parentheses.

>> And if a person does know the language anything done in
>> an obtuse and inefficient way when a better alternative
>> is obvious will also take some time to understand,
>> because time would be spent trying to see the reason
>> for choosing the obscure and inefficient method over
>> the obvious one. And as there is no reason for using
>> your approach the time spent trying to identify the
>> reasoning could be indefinitely extended.
>
> There's really no reason to do it, I do it because it
> looks more pretty for me :]

Aesthetics may guide your authoring, others are likely to apply
reasoning while reading your code, and be mislead by your design
criteria.

>> It is one thing to be writing code that novices take
>> time to understand but writing code that takes experienced
>> programmers time extra time and effort to understand is stupid.
>
> Both doesn't matter for me, I program for fun... xD

Well your audience here are a mixture of experienced programmers and
novices (some of whom are planning on becoming experienced programmers,
and so would benefit from being guided in an appropriate direction).

> This means I won't change my style to make the code
> more readable or change the way I initialize things
> because it creates a ghost object, whatever... I
> change something only when it has a visible impact.
>
>>> Father.prototype = {
>>> type: "father",
>>> :
>>> constructor: Father
>>> };
>>
>> And I said it was a waste of effort to do so as any code that
>> thought it needed that information would already be too flawed
>> for serious consideration.
>
> I'll keep my things safe, if you have manuals ordering people to
> not do things and if they follow,

They will follow, or they won't stay employed for long.

> you can program in the other way "if
> it's not being used, you can change it" :]
>
>
> PS: Again you made me lost a lot of time... I was going to
> ignore this message, but I answered, but now I'm regretted,
> so if you answer, I'll ignore it, since there's nothing useful
> in this discussion, it's over, there's just a bunch of personal
> opinions that don't match.

OK

Richard.

Richard Cornford escreveu:
> Jonas Raoni wrote:
>> Hmm, I'm quite far and I don't like discussing things about
>> computers in real life, in fact I hate when I see people
>> discussing it near me out of the job :]
> <snip>

I said "real life", when there's no computer between me and the person.

I don't like to talk about programming socially, I prefer to make idiot
jokes, talk about soccer, etc., people may think that I'm a machine,
when it's just a nice hobby that became my job. Otherwise I would even
receive those "cool" nicks: geek, fat nerd, etc. haha, to deserve them I
just need to stay hidden from the world in my room, double my weight and
keep talking with my virtual friends while programming xD

Ah, I don't know why I'm talking about it, it's just a personal
preference to avoid becoming a problematic person, computers tends to
increase my individuality, so I ignore it when I'm not in front of it =b

> Then why are you posting to (and presumably reading) a discussion group
> dedicated to a computer programming language?

Why am I here? I sign from Assembly groups up to JavaScript, I'm here
mostly to share ideas and discuss, maybe learn new things... And if a
topic interests me in a way, I try to help too ;]

I love discussing about wasteful things, but when I see that the
discussion will enter in a loop, I quit (as I've done now) :]


--
Jonas Raoni Soares Silva
http://www.jsfromhell.com

Jonas Raoni said the following on 11/29/2006 1:31 PM:
> Randy Webb escreveu:
>> There are typically two opinions, Richards and the wrong one.
>
> Hahaha, I don't agree with his opinion and mine one isn't the wrong,
> this also doesn't mean that his opinion is wrong, they are different
> views, you have to choose to one most suitable for you ;]

That was wrong of me to post that. I have always said that when I was
wrong I would admit it and I was wrong there. I give my public apology
to Richard for the comment.

--
Randy
Chance Favors The Prepared Mind
comp.lang.javascript FAQ - http://jibbering.com/faq
Javascript Best Practices - http://www.JavascriptToolbox.com/bestpractices/