a method to make js have the ability to inherit

[zzw8206262001]

Hi,I find a way to make javescript more like c++ or pyhon
There is the sample code:

function Father(self) //every contructor may have "self"
argument
{
self=self?self:this; //every class may have this statement

self.hello = function()
{
alert("father"+self.name);
}
self.name = "baibai";
}

function Child(self) //every contructor may have "self" argument
{
self=self?self:this; //every class may have this statement

//inherit from faher
Father(self);
self.hello = function()
{
alert("child"+self.name);
}
}

a = new Father();
a.hello();
b = new Child();
b.hello();

 

[Richard Cornford]

Hi,I find a way to make javescript more like c++ or pyhon
There is the sample code:

function Father(self) //every contructor may have "self" argument
{
self=self?self:this; //every class may have this statement

self.hello = function()
{
alert("father"+self.name);
}
self.name = "baibai";
}

function Child(self) //every contructor may have "self"
argument {
self=self?self:this; //every class may have this statement

//inherit from faher
Father(self);
self.hello = function()
{
alert("child"+self.name);
}
}

a = new Father();
a.hello();
b = new Child();
b.hello();

But have you achieved anything more than can be done with normal
javascript inheritance, using a fraction of the code and with
considerably less added complexity? For example, as:-

function Father(){
}
Father.prototype = {
hello:function(){
alert(this.type+this.name);
};
type:"father";
name:"father"
};


function Child(){
}
Child.prototype = new Father():
Child.prototype.type = 'child';


a = new Father();
a.hello();
b = new Child();
b.hello();

Richard.

 

[Richard Cornford]

Richard Cornford wrote:

function Father(){
}
Father.prototype = {
hello:function(){
alert(this.type+this.name);
};
type:"father";
name:"father"
};

<snip>

The name value pairs in the object literal should be comma separated not
semicolon separated. I.E:-

Father.prototype = {
hello:function(){
alert(this.type+this.name);
},
type:"father",
name:"father"
};

Richard.

 

[John G Harris]

Hi,I find a way to make javescript more like c++ or pyhon

Why ?

John

 

[Jonas Raoni]

Richard Cornford escreveu:

Richard Cornford wrote:
The name value pairs in the object literal should be comma separated not
semicolon separated. I.E:-

On the example there's another small mistake: "new Father():"

Father.prototype = {
hello:function(){
alert(this.type+this.name);
},
type:"father",
name:"father"
};

This looks cute, but it damages the language, because this should work:

var a = new Father, b = new a.constructor;

//#1
alert((a instanceof Father) + "\n" + (b instanceof Father));

So to correct it:

Father.prototype = {
hello:function(){
alert(this.type+this.name);
},
type:"father",
name:"father",
constructor: Father
};

or

new function(){
var o = Father.prototype;
o.type = "father";
:
:
};

 

[Richard Cornford]

Richard Cornford escreveu:

On the example there's another small mistake: "new Father():"

You will have the explain that as I don't see it.

This looks cute, but it damages the language, because this
should work:

var a = new Father, b = new a.constructor;

Why "should" it work? It will work if no object is assigned to a
constructor's prototype but that is only a feature of the language, it
is not actually useful.

//#1
alert((a instanceof Father) + "\n" + (b instanceof Father));

So to correct it:

Father.prototype = {
hello:function(){
alert(this.type+this.name);
},
type:"father",
name:"father",
constructor: Father
};

Why include an assignment to a - constructor - property if nobody is
going to use it?

new function(){
var o = Father.prototype;
o.type = "father";
:
:
};

And I don't see any point in doing that at all.

Richard.

 

[Jonas Raoni]

Richard Cornford escreveu:

You will have the explain that as I don't see it.

":" instead of ";"

Why "should" it work? It will work if no object is assigned to a
constructor's prototype but that is only a feature of the language, it
is not actually useful.

Don't worry, I just want to be boring... But that's true, till now I
just used the constructor once or twice.

Why include an assignment to a - constructor - property if nobody is
going to use it?

I suppose you've written this way to avoid writing several assignments
to the "Father.prototype". But if you can keep the language features
intact, why not?

It's not something dangerous as can be prototyping the Array/Object, but
*I* preffer to keep the features intact.

And I don't see any point in doing that at all.

Hmm, it's just a closure with a shortcut variable, something like this:

with({o: a.prototype}){
o.abc = 123;
}

Just other ways to avoid overwriting the constructor.

 

[Jonas Raoni]

Jonas Raoni escreveu:

Richard Cornford escreveu:
Don't worry, I just want to be boring... But that's true, till now I
just used the constructor once or twice.

Just to mention, I remembered one of the places where I used the
constructor:

alert("" instanceof String);
//i could use typeof, but in my case this looked better because "String"
was an argument
alert("".constructor == String);

 

[Richard Cornford]

Richard Cornford escreveu:

":" instead of ";"

Ah, I see. Thank you. Another typo corrected.

Don't worry, I just want to be boring... But that's true, till
now I just used the constructor once or twice.

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.

I suppose you've written this way to avoid writing several
assignments to the "Father.prototype". But if you can keep
the language features intact, why not?

If there is no reason for using the property any effort to "keep it
intact" is futile and wasteful.

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.

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?

something like
this:

with({o: a.prototype}){
o.abc = 123;
}

Nor there.

Just other ways to avoid overwriting the constructor.

If that was a useful thing to be doing then your earlier methods make
more sense.

Richard.

 

[Jonas Raoni]

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

I could use typeof (which also looks better, since it's 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, I don't like to assume anything as world truth and,
"fixing" it isn't what I can call a hard job :]

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.

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

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

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(){})()".

Nor there.

I won't explain the purpose again, it's the same.

var o = 0;
with({o: 1})
o = 2;
alert(o);

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

 

[Richard Cornford]

Richard Cornford escreveu:

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.


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

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.

I won't explain the purpose again, it's the same.

var o = 0;
with({o: 1})
o = 2;
alert(o);



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.

 

[Jonas Raoni]

Richard Cornford escreveu:

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?

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

? 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.
;]

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.

And you did neither.

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

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.

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

 

[Richard Cornford]

Richard Cornford escreveu:

In this specific case yes.

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

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.

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.

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.

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.

Oh my god....

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


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.

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.

And you did neither.

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

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.

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.

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.

 

[Jonas Raoni]

Richard Cornford escreveu:

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


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.

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.


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.

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.

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

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.

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.

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.

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.

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.

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.

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


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.

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

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

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

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.

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.

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.

 

[Randy Webb]

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

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.

 

[Jonas Raoni]

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

 

[Richard Cornford]

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.

 

[Richard Cornford]

Richard Cornford escreveu:

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.

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.

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

That response seems disconnected from its context.

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.

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.

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.

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.

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?

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.

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.

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 are editing the material you quote without marking your edits. That
is disingenuous.

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?

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.

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.

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.

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

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.


Yes, that's my point of view.


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.

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.

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.

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.


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.

 

[Jonas Raoni]

Richard Cornford escreveu:

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) :]

 

[Randy Webb]

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.