a method to make js have the ability to inherit

Discussion in 'Javascript' started by zzw8206262001@yahoo.com.cn, Nov 20, 2006.

  1. Guest

    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();
     
    , Nov 20, 2006
    #1
    1. Advertising

  2. wrote:
    > 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, Nov 20, 2006
    #2
    1. Advertising

  3. Richard Cornford wrote:
    <snip>
    > 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.
     
    Richard Cornford, Nov 20, 2006
    #3
  4. In article <>,
    writes
    >Hi,I find a way to make javescript more like c++ or pyhon


    Why ?

    John
    --
    John Harris
     
    John G Harris, Nov 20, 2006
    #4
  5. Jonas Raoni Guest

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


    --
    Jonas Raoni Soares Silva
    http://www.jsfromhell.com
     
    Jonas Raoni, Nov 21, 2006
    #5
  6. Jonas Raoni wrote:
    > 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():"


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

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


    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.
     
    Richard Cornford, Nov 21, 2006
    #6
  7. Jonas Raoni Guest

    Richard Cornford escreveu:
    > Jonas Raoni wrote:
    >> On the example there's another small mistake: "new Father():"

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


    ":" instead of ";" :)

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


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

    >> Father.prototype = {
    >> constructor: Father
    >> };

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

    >> 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, something like this:

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

    Just other ways to avoid overwriting the constructor.


    --
    Jonas Raoni Soares Silva
    http://www.jsfromhell.com
     
    Jonas Raoni, Nov 22, 2006
    #7
  8. Jonas Raoni Guest

    Jonas Raoni escreveu:
    > Richard Cornford escreveu:
    >> Jonas Raoni wrote:

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


    --
    Jonas Raoni Soares Silva
    http://www.jsfromhell.com
     
    Jonas Raoni, Nov 22, 2006
    #8
  9. Jonas Raoni wrote:
    > Richard Cornford escreveu:
    >> Jonas Raoni wrote:
    >>> On the example there's another small mistake: "new Father():"

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

    >
    > ":" instead of ";" :)


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

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

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

    >>> Father.prototype = {
    >>> constructor: Father
    >>> };

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


    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.

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

    > 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.
     
    Richard Cornford, Nov 26, 2006
    #9
  10. Jonas Raoni Guest

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

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

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

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


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


    --
    Jonas Raoni Soares Silva
    http://www.jsfromhell.com
     
    Jonas Raoni, Nov 26, 2006
    #10
  11. 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, Nov 26, 2006
    #11
  12. Jonas Raoni Guest

    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, Nov 27, 2006
    #12
  13. 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, Nov 27, 2006
    #13
  14. Jonas Raoni Guest

    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, Nov 29, 2006
    #14
  15. Randy Webb Guest

    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, Nov 29, 2006
    #15
  16. Jonas Raoni Guest

    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, Nov 29, 2006
    #16
  17. 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.
     
    Richard Cornford, Nov 30, 2006
    #17
  18. 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, Nov 30, 2006
    #18
  19. Jonas Raoni Guest

    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, Nov 30, 2006
    #19
  20. Randy Webb Guest

    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/
     
    Randy Webb, Nov 30, 2006
    #20
    1. Advertising

Want to reply to this thread or ask your own question?

It takes just 2 minutes to sign up (and it's free!). Just click the sign up button to choose a username and then you can ask your own questions on the forum.
Similar Threads
  1. =?Utf-8?B?U2NhcmVjcm93?=

    Do asp.net have ability to access client CDRW/DVDRW?

    =?Utf-8?B?U2NhcmVjcm93?=, Jan 28, 2004, in forum: ASP .Net
    Replies:
    2
    Views:
    328
    Hermit Dave
    Jan 28, 2004
  2. Les Caudle
    Replies:
    0
    Views:
    670
    Les Caudle
    Mar 7, 2004
  3. Eric Caron

    Lost ability to debug projects

    Eric Caron, Jun 17, 2005, in forum: ASP .Net
    Replies:
    0
    Views:
    352
    Eric Caron
    Jun 17, 2005
  4. Bob Maxie
    Replies:
    5
    Views:
    446
    Bob Maxie
    Sep 24, 2005
  5. cownew
    Replies:
    0
    Views:
    709
    cownew
    May 14, 2006
Loading...

Share This Page