FAQ
Hi everyone,

I have just wrote a simple lightweight OOP helper and want your thoughts
about it, the implementation "Class" is only 15 lines of code, but I have
included some tests, to show how it works. Any feedback is welcome. I am no
JavaScript expert, but if I have not done anything wrong should always the
generated class be 100% compatible with normal JavaScript prototype
inheritance and indeed be very fast. It allows a user write somewhat more
simple code.

See gist: https://gist.github.com/3990372

What are your thoughts? Both negative and positive. And please, one comment
is better than no one, so please comment if you read through the gist.

Thanks in advance!

--
Job Board: http://jobs.nodejs.org/
Posting guidelines: https://github.com/joyent/node/wiki/Mailing-List-Posting-Guidelines
You received this message because you are subscribed to the Google
Groups "nodejs" group.
To post to this group, send email to nodejs@googlegroups.com
To unsubscribe from this group, send email to
nodejs+unsubscribe@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/nodejs?hl=en?hl=en

Search Discussions

  • Isaac Schlueter at Nov 1, 2012 at 5:03 am
    I would say you don't need this.

    Just create a function with a capitalized first letter. That's your
    class. Instantiate with `new`. Assign stuff to the prototype. Use
    `util.inherits` (or the `inherits` module if you prefer) to do
    inheritance, if you need to.

    It's much better to write idiomatic JavaScript rather than twist
    JavaScript to look like some other language. Yes, of course you *can*
    do it, and you might learn something from it, but it's not actually a
    good idea to use such things in real life. I'd suggest writing a few
    more OOP helper wrapper doohickeys. In fact, continue writing them
    until you see through the matrix of OOP to the true nature of
    prototypes, and deeply grok that it's all just the same thing, so you
    may as well use the one that's the most optimized by the VM, and the
    most readily understandable to other users of the language.

    That is, if you seek enlightenment. If you just wanna get something
    done, use plain old boring JavaScript style OOP.

    On Wed, Oct 31, 2012 at 3:37 PM, Fredrik O wrote:
    Hi everyone,

    I have just wrote a simple lightweight OOP helper and want your thoughts
    about it, the implementation "Class" is only 15 lines of code, but I have
    included some tests, to show how it works. Any feedback is welcome. I am no
    JavaScript expert, but if I have not done anything wrong should always the
    generated class be 100% compatible with normal JavaScript prototype
    inheritance and indeed be very fast. It allows a user write somewhat more
    simple code.

    See gist: https://gist.github.com/3990372

    What are your thoughts? Both negative and positive. And please, one comment
    is better than no one, so please comment if you read through the gist.

    Thanks in advance!

    --
    Job Board: http://jobs.nodejs.org/
    Posting guidelines:
    https://github.com/joyent/node/wiki/Mailing-List-Posting-Guidelines
    You received this message because you are subscribed to the Google
    Groups "nodejs" group.
    To post to this group, send email to nodejs@googlegroups.com
    To unsubscribe from this group, send email to
    nodejs+unsubscribe@googlegroups.com
    For more options, visit this group at
    http://groups.google.com/group/nodejs?hl=en?hl=en
    --
    Job Board: http://jobs.nodejs.org/
    Posting guidelines: https://github.com/joyent/node/wiki/Mailing-List-Posting-Guidelines
    You received this message because you are subscribed to the Google
    Groups "nodejs" group.
    To post to this group, send email to nodejs@googlegroups.com
    To unsubscribe from this group, send email to
    nodejs+unsubscribe@googlegroups.com
    For more options, visit this group at
    http://groups.google.com/group/nodejs?hl=en?hl=en
  • Mark Hahn at Nov 1, 2012 at 5:05 am
    Or, just use coffeescript. It offers great class support with `super`,
    etc, while using standard prototypes.
    On Wed, Oct 31, 2012 at 10:03 PM, Isaac Schlueter wrote:

    I would say you don't need this.

    Just create a function with a capitalized first letter. That's your
    class. Instantiate with `new`. Assign stuff to the prototype. Use
    `util.inherits` (or the `inherits` module if you prefer) to do
    inheritance, if you need to.

    It's much better to write idiomatic JavaScript rather than twist
    JavaScript to look like some other language. Yes, of course you *can*
    do it, and you might learn something from it, but it's not actually a
    good idea to use such things in real life. I'd suggest writing a few
    more OOP helper wrapper doohickeys. In fact, continue writing them
    until you see through the matrix of OOP to the true nature of
    prototypes, and deeply grok that it's all just the same thing, so you
    may as well use the one that's the most optimized by the VM, and the
    most readily understandable to other users of the language.

    That is, if you seek enlightenment. If you just wanna get something
    done, use plain old boring JavaScript style OOP.

    On Wed, Oct 31, 2012 at 3:37 PM, Fredrik O wrote:
    Hi everyone,

    I have just wrote a simple lightweight OOP helper and want your thoughts
    about it, the implementation "Class" is only 15 lines of code, but I have
    included some tests, to show how it works. Any feedback is welcome. I am no
    JavaScript expert, but if I have not done anything wrong should always the
    generated class be 100% compatible with normal JavaScript prototype
    inheritance and indeed be very fast. It allows a user write somewhat more
    simple code.

    See gist: https://gist.github.com/3990372

    What are your thoughts? Both negative and positive. And please, one comment
    is better than no one, so please comment if you read through the gist.

    Thanks in advance!

    --
    Job Board: http://jobs.nodejs.org/
    Posting guidelines:
    https://github.com/joyent/node/wiki/Mailing-List-Posting-Guidelines
    You received this message because you are subscribed to the Google
    Groups "nodejs" group.
    To post to this group, send email to nodejs@googlegroups.com
    To unsubscribe from this group, send email to
    nodejs+unsubscribe@googlegroups.com
    For more options, visit this group at
    http://groups.google.com/group/nodejs?hl=en?hl=en
    --
    Job Board: http://jobs.nodejs.org/
    Posting guidelines:
    https://github.com/joyent/node/wiki/Mailing-List-Posting-Guidelines
    You received this message because you are subscribed to the Google
    Groups "nodejs" group.
    To post to this group, send email to nodejs@googlegroups.com
    To unsubscribe from this group, send email to
    nodejs+unsubscribe@googlegroups.com
    For more options, visit this group at
    http://groups.google.com/group/nodejs?hl=en?hl=en
    --
    Job Board: http://jobs.nodejs.org/
    Posting guidelines: https://github.com/joyent/node/wiki/Mailing-List-Posting-Guidelines
    You received this message because you are subscribed to the Google
    Groups "nodejs" group.
    To post to this group, send email to nodejs@googlegroups.com
    To unsubscribe from this group, send email to
    nodejs+unsubscribe@googlegroups.com
    For more options, visit this group at
    http://groups.google.com/group/nodejs?hl=en?hl=en
  • Isaac Schlueter at Nov 1, 2012 at 5:25 am
    Trololololol ;p
    On Wednesday, October 31, 2012, Mark Hahn wrote:

    Or, just use coffeescript. It offers great class support with `super`,
    etc, while using standard prototypes.

    On Wed, Oct 31, 2012 at 10:03 PM, Isaac Schlueter wrote:

    I would say you don't need this.

    Just create a function with a capitalized first letter. That's your
    class. Instantiate with `new`. Assign stuff to the prototype. Use
    `util.inherits` (or the `inherits` module if you prefer) to do
    inheritance, if you need to.

    It's much better to write idiomatic JavaScript rather than twist
    JavaScript to look like some other language. Yes, of course you *can*
    do it, and you might learn something from it, but it's not actually a
    good idea to use such things in real life. I'd suggest writing a few
    more OOP helper wrapper doohickeys. In fact, continue writing them
    until you see through the matrix of OOP to the true nature of
    prototypes, and deeply grok that it's all just the same thing, so you
    may as well use the one that's the most optimized by the VM, and the
    most readily understandable to other users of the language.

    That is, if you seek enlightenment. If you just wanna get something
    done, use plain old boring JavaScript style OOP.

    On Wed, Oct 31, 2012 at 3:37 PM, Fredrik O wrote:
    Hi everyone,

    I have just wrote a simple lightweight OOP helper and want your thoughts
    about it, the implementation "Class" is only 15 lines of code, but I have
    included some tests, to show how it works. Any feedback is welcome. I am no
    JavaScript expert, but if I have not done anything wrong should always the
    generated class be 100% compatible with normal JavaScript prototype
    inheritance and indeed be very fast. It allows a user write somewhat more
    simple code.

    See gist: https://gist.github.com/3990372

    What are your thoughts? Both negative and positive. And please, one comment
    is better than no one, so please comment if you read through the gist.

    Thanks in advance!

    --
    Job Board: http://jobs.nodejs.org/
    Posting guidelines:
    https://github.com/joyent/node/wiki/Mailing-List-Posting-Guidelines
    You received this message because you are subscribed to the Google
    Groups "nodejs" group.
    To post to this group, send email to nodejs@googlegroups.com
    To unsubscribe from this group, send email to
    nodejs+unsubscribe@googlegroups.com
    For more options, visit this group at
    http://groups.google.com/group/nodejs?hl=en?hl=en
    --
    Job Board: http://jobs.nodejs.org/
    Posting guidelines:
    https://github.com/joyent/node/wiki/Mailing-List-Posting-Guidelines
    You received this message because you are subscribed to the Google
    Groups "nodejs" group.
    To post to this group, send email to nodejs@googlegroups.com
    To unsubscribe from this group, send email to
    nodejs+unsubscribe@googlegroups.com
    For more options, visit this group at
    http://groups.google.com/group/nodejs?hl=en?hl=en


    --
    Job Board: http://jobs.nodejs.org/
    Posting guidelines:
    https://github.com/joyent/node/wiki/Mailing-List-Posting-Guidelines
    You received this message because you are subscribed to the Google
    Groups "nodejs" group.
    To post to this group, send email to nodejs@g
    --
    Job Board: http://jobs.nodejs.org/
    Posting guidelines: https://github.com/joyent/node/wiki/Mailing-List-Posting-Guidelines
    You received this message because you are subscribed to the Google
    Groups "nodejs" group.
    To post to this group, send email to nodejs@googlegroups.com
    To unsubscribe from this group, send email to
    nodejs+unsubscribe@googlegroups.com
    For more options, visit this group at
    http://groups.google.com/group/nodejs?hl=en?hl=en
  • Karl at Nov 1, 2012 at 7:19 am
    And is that a metric or an imperial doohickey? If it's imperial it will not
    wrap well everywhere, better to write a thingamabob...

    El jueves, 1 de noviembre de 2012 06:25:49 UTC+1, Isaac Schlueter escribió:
    Trololololol ;p
    On Wednesday, October 31, 2012, Mark Hahn wrote:

    Or, just use coffeescript. It offers great class support with `super`,
    etc, while using standard prototypes.

    On Wed, Oct 31, 2012 at 10:03 PM, Isaac Schlueter wrote:

    I would say you don't need this.

    Just create a function with a capitalized first letter. That's your
    class. Instantiate with `new`. Assign stuff to the prototype. Use
    `util.inherits` (or the `inherits` module if you prefer) to do
    inheritance, if you need to.

    It's much better to write idiomatic JavaScript rather than twist
    JavaScript to look like some other language. Yes, of course you *can*
    do it, and you might learn something from it, but it's not actually a
    good idea to use such things in real life. I'd suggest writing a few
    more OOP helper wrapper doohickeys. In fact, continue writing them
    until you see through the matrix of OOP to the true nature of
    prototypes, and deeply grok that it's all just the same thing, so you
    may as well use the one that's the most optimized by the VM, and the
    most readily understandable to other users of the language.

    That is, if you seek enlightenment. If you just wanna get something
    done, use plain old boring JavaScript style OOP.

    On Wed, Oct 31, 2012 at 3:37 PM, Fredrik O wrote:
    Hi everyone,

    I have just wrote a simple lightweight OOP helper and want your thoughts
    about it, the implementation "Class" is only 15 lines of code, but I have
    included some tests, to show how it works. Any feedback is welcome. I am no
    JavaScript expert, but if I have not done anything wrong should always the
    generated class be 100% compatible with normal JavaScript prototype
    inheritance and indeed be very fast. It allows a user write somewhat more
    simple code.

    See gist: https://gist.github.com/3990372

    What are your thoughts? Both negative and positive. And please, one comment
    is better than no one, so please comment if you read through the gist.

    Thanks in advance!

    --
    Job Board: http://jobs.nodejs.org/
    Posting guidelines:
    https://github.com/joyent/node/wiki/Mailing-List-Posting-Guidelines
    You received this message because you are subscribed to the Google
    Groups "nodejs" group.
    To post to this group, send email to nodejs@googlegroups.com
    To unsubscribe from this group, send email to
    nodejs+unsubscribe@googlegroups.com
    For more options, visit this group at
    http://groups.google.com/group/nodejs?hl=en?hl=en
    --
    Job Board: http://jobs.nodejs.org/
    Posting guidelines:
    https://github.com/joyent/node/wiki/Mailing-List-Posting-Guidelines
    You received this message because you are subscribed to the Google
    Groups "nodejs" group.
    To post to this group, send email to nodejs@googlegroups.com
    To unsubscribe from this group, send email to
    nodejs+unsubscribe@googlegroups.com
    For more options, visit this group at
    http://groups.google.com/group/nodejs?hl=en?hl=en


    --
    Job Board: http://jobs.nodejs.org/
    Posting guidelines:
    https://github.com/joyent/node/wiki/Mailing-List-Posting-Guidelines
    You received this message because you are subscribed to the Google
    Groups "nodejs" group.
    To post to this group, send email to nodejs@g
    --
    Job Board: http://jobs.nodejs.org/
    Posting guidelines: https://github.com/joyent/node/wiki/Mailing-List-Posting-Guidelines
    You received this message because you are subscribed to the Google
    Groups "nodejs" group.
    To post to this group, send email to nodejs@googlegroups.com
    To unsubscribe from this group, send email to
    nodejs+unsubscribe@googlegroups.com
    For more options, visit this group at
    http://groups.google.com/group/nodejs?hl=en?hl=en
  • Fredrik O at Nov 1, 2012 at 9:11 pm
    Thanks for answer, everyone :-)

    Isaacs:

    This is exactly what I am doing today, but I want to stop repeating myself,
    e.g "implement" the DRY principle, but stay 100% compatible with pure
    JavaScript prototype inheritance. So instead of manually create a function,
    assign a appropriate prototype to it and call "inherits" if I need to do
    some inheritance, do it in a automatic function which return a function
    which have exactly been initialized using this steps. Without it would I
    need to do all those things manually, no matter how. What is wrong with it?

    Mark:

    Thanks, but no thanks. I like the syntax of JavaScript more than
    CoffeScript, and just adding another language would increase the complexity
    of my software.

    Alexey:

    I have some read some about it, in others programming languages, but have
    forget about it in JavaScript. Definitely something I should look more
    into. Thanks for the tip :-)

    --
    Job Board: http://jobs.nodejs.org/
    Posting guidelines: https://github.com/joyent/node/wiki/Mailing-List-Posting-Guidelines
    You received this message because you are subscribed to the Google
    Groups "nodejs" group.
    To post to this group, send email to nodejs@googlegroups.com
    To unsubscribe from this group, send email to
    nodejs+unsubscribe@googlegroups.com
    For more options, visit this group at
    http://groups.google.com/group/nodejs?hl=en?hl=en
  • Alexey Petrushin at Nov 1, 2012 at 2:02 pm
    Take a look at functional mixins, it's native to JS, requires
    zero-framework and looks much simpler and powerful than prototype - based.

    https://speakerdeck.com/anguscroll/how-we-learned-to-stop-worrying-and-love-javascript
    On Thursday, November 1, 2012 2:37:33 AM UTC+4, Fredrik O wrote:

    Hi everyone,

    I have just wrote a simple lightweight OOP helper and want your thoughts
    about it, the implementation "Class" is only 15 lines of code, but I have
    included some tests, to show how it works. Any feedback is welcome. I am no
    JavaScript expert, but if I have not done anything wrong should always the
    generated class be 100% compatible with normal JavaScript prototype
    inheritance and indeed be very fast. It allows a user write somewhat more
    simple code.

    See gist: https://gist.github.com/3990372

    What are your thoughts? Both negative and positive. And please, one
    comment is better than no one, so please comment if you read through the
    gist.

    Thanks in advance!
    --
    Job Board: http://jobs.nodejs.org/
    Posting guidelines: https://github.com/joyent/node/wiki/Mailing-List-Posting-Guidelines
    You received this message because you are subscribed to the Google
    Groups "nodejs" group.
    To post to this group, send email to nodejs@googlegroups.com
    To unsubscribe from this group, send email to
    nodejs+unsubscribe@googlegroups.com
    For more options, visit this group at
    http://groups.google.com/group/nodejs?hl=en?hl=en
  • Alexey Petrushin at Nov 1, 2012 at 2:03 pm
    Actually, after discovering functional mixins I stopped use classes in
    CoffeeScript.
    On Thursday, November 1, 2012 6:02:49 PM UTC+4, Alexey Petrushin wrote:

    Take a look at functional mixins, it's native to JS, requires
    zero-framework and looks much simpler and powerful than prototype - based.


    https://speakerdeck.com/anguscroll/how-we-learned-to-stop-worrying-and-love-javascript
    On Thursday, November 1, 2012 2:37:33 AM UTC+4, Fredrik O wrote:

    Hi everyone,

    I have just wrote a simple lightweight OOP helper and want your thoughts
    about it, the implementation "Class" is only 15 lines of code, but I have
    included some tests, to show how it works. Any feedback is welcome. I am no
    JavaScript expert, but if I have not done anything wrong should always the
    generated class be 100% compatible with normal JavaScript prototype
    inheritance and indeed be very fast. It allows a user write somewhat more
    simple code.

    See gist: https://gist.github.com/3990372

    What are your thoughts? Both negative and positive. And please, one
    comment is better than no one, so please comment if you read through the
    gist.

    Thanks in advance!
    --
    Job Board: http://jobs.nodejs.org/
    Posting guidelines: https://github.com/joyent/node/wiki/Mailing-List-Posting-Guidelines
    You received this message because you are subscribed to the Google
    Groups "nodejs" group.
    To post to this group, send email to nodejs@googlegroups.com
    To unsubscribe from this group, send email to
    nodejs+unsubscribe@googlegroups.com
    For more options, visit this group at
    http://groups.google.com/group/nodejs?hl=en?hl=en
  • José F. Romaniello at Nov 7, 2012 at 2:32 am
    I really like this functional mixins thing, another good read is this one

    http://killdream.github.com/blog/2011/10/understanding-javascript-oop/

    --
    Job Board: http://jobs.nodejs.org/
    Posting guidelines: https://github.com/joyent/node/wiki/Mailing-List-Posting-Guidelines
    You received this message because you are subscribed to the Google
    Groups "nodejs" group.
    To post to this group, send email to nodejs@googlegroups.com
    To unsubscribe from this group, send email to
    nodejs+unsubscribe@googlegroups.com
    For more options, visit this group at
    http://groups.google.com/group/nodejs?hl=en?hl=en
  • Alexey Petrushin at Nov 7, 2012 at 1:14 pm
    If i have to establish is-a relation, i'd rather do this via simple
    property than prototypes.

    Exactly, I keept the sample small and ignore that part, if You need it You
    can use this

    Model = function(){}

    Validatable = function(klass){
    // do all needed extensions ...

    klass.prototype.isValidatable = true
    }

    Validatable(Model)

    model = new Model()
    if(model.isValidatable) ...

    --
    Job Board: http://jobs.nodejs.org/
    Posting guidelines: https://github.com/joyent/node/wiki/Mailing-List-Posting-Guidelines
    You received this message because you are subscribed to the Google
    Groups "nodejs" group.
    To post to this group, send email to nodejs@googlegroups.com
    To unsubscribe from this group, send email to
    nodejs+unsubscribe@googlegroups.com
    For more options, visit this group at
    http://groups.google.com/group/nodejs?hl=en?hl=en
  • Alexey Petrushin at Dec 10, 2012 at 4:13 pm
    I wrote short article about Functional Mixins with simple example, maybe it
    will be useful http://petrush.in/blog/2012/functional-mixins
    On Wednesday, November 7, 2012 6:32:04 AM UTC+4, José F. Romaniello wrote:

    I really like this functional mixins thing, another good read is this one

    http://killdream.github.com/blog/2011/10/understanding-javascript-oop/
    --
    Job Board: http://jobs.nodejs.org/
    Posting guidelines: https://github.com/joyent/node/wiki/Mailing-List-Posting-Guidelines
    You received this message because you are subscribed to the Google
    Groups "nodejs" group.
    To post to this group, send email to nodejs@googlegroups.com
    To unsubscribe from this group, send email to
    nodejs+unsubscribe@googlegroups.com
    For more options, visit this group at
    http://groups.google.com/group/nodejs?hl=en?hl=en
  • Azer Koçulu at Dec 11, 2012 at 12:42 am
    I re-wrote your example using a new library that I'm working on;

    https://gist.github.com/4254699

    Here is another example: https://gist.github.com/4136102

    And this is the library: http://github.com/azer/ak47

    On Mon, Dec 10, 2012 at 8:05 AM, Alexey Petrushin wrote:

    I wrote short article about Functional Mixins with simple example, maybe
    it will be useful http://petrush.in/blog/2012/functional-mixins

    On Wednesday, November 7, 2012 6:32:04 AM UTC+4, José F. Romaniello wrote:

    I really like this functional mixins thing, another good read is this one

    http://killdream.github.com/**blog/2011/10/understanding-**
    javascript-oop/<http://killdream.github.com/blog/2011/10/understanding-javascript-oop/>
    --
    Job Board: http://jobs.nodejs.org/
    Posting guidelines:
    https://github.com/joyent/node/wiki/Mailing-List-Posting-Guidelines
    You received this message because you are subscribed to the Google
    Groups "nodejs" group.
    To post to this group, send email to nodejs@googlegroups.com
    To unsubscribe from this group, send email to
    nodejs+unsubscribe@googlegroups.com
    For more options, visit this group at
    http://groups.google.com/group/nodejs?hl=en?hl=en
    --
    Job Board: http://jobs.nodejs.org/
    Posting guidelines: https://github.com/joyent/node/wiki/Mailing-List-Posting-Guidelines
    You received this message because you are subscribed to the Google
    Groups "nodejs" group.
    To post to this group, send email to nodejs@googlegroups.com
    To unsubscribe from this group, send email to
    nodejs+unsubscribe@googlegroups.com
    For more options, visit this group at
    http://groups.google.com/group/nodejs?hl=en?hl=en
  • Jake Verbaten at Dec 11, 2012 at 4:53 am
    Why is this so hard?

    Why do we need unnecessary OOP abstractions.

    Use functions, it's really really simple. https://gist.github.com/4255961

    ```js
    function Base(text) {
    return function () {
    return text
    }
    }

    function Derived(source, prefix) {
    var text = Base(source)

    return function () {
    return prefix + text() + prefix
    }
    }

    function Derived2(source, prefix, color) {
    var text = Derived(source, prefix)

    return function () {
    return color + text()
    }
    }

    var d = Derived('foo', '!'),
    d2 = Derived2('bar', '!', 'red'),

    assert = require('assert');

    assert.equal( d(), '!foo!' );
    assert.equal( d2(), 'red!bar!' );
    ```

    On Mon, Dec 10, 2012 at 4:41 PM, Azer Koçulu wrote:

    I re-wrote your example using a new library that I'm working on;

    https://gist.github.com/4254699

    Here is another example: https://gist.github.com/4136102

    And this is the library: http://github.com/azer/ak47


    On Mon, Dec 10, 2012 at 8:05 AM, Alexey Petrushin <
    alexey.petrushin@gmail.com> wrote:
    I wrote short article about Functional Mixins with simple example, maybe
    it will be useful http://petrush.in/blog/2012/functional-mixins

    On Wednesday, November 7, 2012 6:32:04 AM UTC+4, José F. Romaniello wrote:

    I really like this functional mixins thing, another good read is this one

    http://killdream.github.com/**blog/2011/10/understanding-**
    javascript-oop/<http://killdream.github.com/blog/2011/10/understanding-javascript-oop/>
    --
    Job Board: http://jobs.nodejs.org/
    Posting guidelines:
    https://github.com/joyent/node/wiki/Mailing-List-Posting-Guidelines
    You received this message because you are subscribed to the Google
    Groups "nodejs" group.
    To post to this group, send email to nodejs@googlegroups.com
    To unsubscribe from this group, send email to
    nodejs+unsubscribe@googlegroups.com
    For more options, visit this group at
    http://groups.google.com/group/nodejs?hl=en?hl=en
    --
    Job Board: http://jobs.nodejs.org/
    Posting guidelines:
    https://github.com/joyent/node/wiki/Mailing-List-Posting-Guidelines
    You received this message because you are subscribed to the Google
    Groups "nodejs" group.
    To post to this group, send email to nodejs@googlegroups.com
    To unsubscribe from this group, send email to
    nodejs+unsubscribe@googlegroups.com
    For more options, visit this group at
    http://groups.google.com/group/nodejs?hl=en?hl=en
    --
    Job Board: http://jobs.nodejs.org/
    Posting guidelines: https://github.com/joyent/node/wiki/Mailing-List-Posting-Guidelines
    You received this message because you are subscribed to the Google
    Groups "nodejs" group.
    To post to this group, send email to nodejs@googlegroups.com
    To unsubscribe from this group, send email to
    nodejs+unsubscribe@googlegroups.com
    For more options, visit this group at
    http://groups.google.com/group/nodejs?hl=en?hl=en
  • Luke Arduini at Dec 13, 2012 at 6:24 am
    I have yet to hear a particularly convincing argument for this type of OOP in javascript. As Raynos and Isaac explained, the idiomatic js style way without some additional special wrapper or helper is trivial to do.

    "I like it more" is a fine reason to do it yourself. I think it's a waste of time but it's not my time.

    Please for the love of science however don't encourage js newcomers to write their code like this.

    --
    Job Board: http://jobs.nodejs.org/
    Posting guidelines: https://github.com/joyent/node/wiki/Mailing-List-Posting-Guidelines
    You received this message because you are subscribed to the Google
    Groups "nodejs" group.
    To post to this group, send email to nodejs@googlegroups.com
    To unsubscribe from this group, send email to
    nodejs+unsubscribe@googlegroups.com
    For more options, visit this group at
    http://groups.google.com/group/nodejs?hl=en?hl=en
  • Brian Link at Nov 1, 2012 at 11:52 pm
    I like the look of those functional mix-ins. Thanks for the link.
    On Wednesday, October 31, 2012 3:37:33 PM UTC-7, Fredrik O wrote:

    Hi everyone,

    I have just wrote a simple lightweight OOP helper and want your thoughts
    about it, the implementation "Class" is only 15 lines of code, but I have
    included some tests, to show how it works. Any feedback is welcome. I am no
    JavaScript expert, but if I have not done anything wrong should always the
    generated class be 100% compatible with normal JavaScript prototype
    inheritance and indeed be very fast. It allows a user write somewhat more
    simple code.

    See gist: https://gist.github.com/3990372

    What are your thoughts? Both negative and positive. And please, one
    comment is better than no one, so please comment if you read through the
    gist.

    Thanks in advance!
    --
    Job Board: http://jobs.nodejs.org/
    Posting guidelines: https://github.com/joyent/node/wiki/Mailing-List-Posting-Guidelines
    You received this message because you are subscribed to the Google
    Groups "nodejs" group.
    To post to this group, send email to nodejs@googlegroups.com
    To unsubscribe from this group, send email to
    nodejs+unsubscribe@googlegroups.com
    For more options, visit this group at
    http://groups.google.com/group/nodejs?hl=en?hl=en
  • Tjholowaychuk at Nov 2, 2012 at 4:08 am
    I'm with isaac, personally I actually prefer re-declaring the
    "Foo.prototype.<whatever> =" each method it re-establishes context.
    Lots
    of coffeescript is bad this way since you get half-way down the file,
    you see some indented code and you have no clue what it's part of.
    Same
    goes for JavaScript using object-literals. This doesn't mean it has to
    be ugly, just dont write ugly code but I strongly agree there's no
    reason to
    use these classical OO thingies
    On Nov 1, 4:44 pm, Brian Link wrote:
    I like the look of those functional mix-ins.  Thanks for the link.






    On Wednesday, October 31, 2012 3:37:33 PM UTC-7, Fredrik O wrote:

    Hi everyone,
    I have just wrote a simple lightweight OOP helper and want your thoughts
    about it, the implementation "Class" is only 15 lines of code, but I have
    included some tests, to show how it works. Any feedback is welcome. I am no
    JavaScript expert, but if I have not done anything wrong should always the
    generated class be 100% compatible with normal JavaScript prototype
    inheritance and indeed be very fast. It allows a user write somewhat more
    simple code.
    See gist:  https://gist.github.com/3990372
    What are your thoughts? Both negative and positive. And please, one
    comment is better than no one, so please comment if you read through the
    gist.
    Thanks in advance!
    --
    Job Board: http://jobs.nodejs.org/
    Posting guidelines: https://github.com/joyent/node/wiki/Mailing-List-Posting-Guidelines
    You received this message because you are subscribed to the Google
    Groups "nodejs" group.
    To post to this group, send email to nodejs@googlegroups.com
    To unsubscribe from this group, send email to
    nodejs+unsubscribe@googlegroups.com
    For more options, visit this group at
    http://groups.google.com/group/nodejs?hl=en?hl=en
  • Wil Moore at Nov 2, 2012 at 8:07 am
    I agree with Isaac,

    Build classical function helpers as a learning experience, which which will
    show you that you don't need them.

    Read and write a lot of idiomatic JavaScript and you'll quickly get over
    (and actually start to like) the syntax of "Constructor.prototype.*". I
    personally fought this for much longer than necessary. Once you get over
    it, hundred-line object literals (including the popular "module" pattern)
    will start to look extremely obtuse and superfluous.

    Either way, JavaScript is really fun so go write cool things and enjoy it :)

    --
    Job Board: http://jobs.nodejs.org/
    Posting guidelines: https://github.com/joyent/node/wiki/Mailing-List-Posting-Guidelines
    You received this message because you are subscribed to the Google
    Groups "nodejs" group.
    To post to this group, send email to nodejs@googlegroups.com
    To unsubscribe from this group, send email to
    nodejs+unsubscribe@googlegroups.com
    For more options, visit this group at
    http://groups.google.com/group/nodejs?hl=en?hl=en
  • Fredrik O at Nov 2, 2012 at 3:46 pm
    Thanks for answer, everyone, it is pleasant :-)

    To just clear my point. I understand why raw JavaScript inheritance often
    is preferred, no need to know what "Class" does for example. Simply
    speaking can every single JavaScript programmer see what is going on. But
    now to my point.

    Say I am writing many small modules. Those modules should only export some
    function who gives some type of functionality. The user of those modules
    only care about the functionality and how it behaves, not how it is
    actually implemented. Say now it takes somewhat shorter time when I use a
    helper function than it would without it, why should I not use then?

    The "dependency" is included in the source, so every developer can fast and
    easily check it up. The generated function will have the same performance
    as the handwritten function probably and it will increase the readability
    of the source code somewhat. The function helper itself does not use any
    advanced JavaScript, all serious developers should understand it and no
    fancy stuff is added. So why is it not preferred to use a helper function
    in those situations? I cannot really get it when those advantages is
    applied.


    Den fredagen den 2:e november 2012 kl. 09:07:47 UTC+1 skrev Wil Moore:
    I agree with Isaac,

    Build classical function helpers as a learning experience, which which
    will show you that you don't need them.

    Read and write a lot of idiomatic JavaScript and you'll quickly get over
    (and actually start to like) the syntax of "Constructor.prototype.*". I
    personally fought this for much longer than necessary. Once you get over
    it, hundred-line object literals (including the popular "module" pattern)
    will start to look extremely obtuse and superfluous.

    Either way, JavaScript is really fun so go write cool things and enjoy it
    :)
    --
    Job Board: http://jobs.nodejs.org/
    Posting guidelines: https://github.com/joyent/node/wiki/Mailing-List-Posting-Guidelines
    You received this message because you are subscribed to the Google
    Groups "nodejs" group.
    To post to this group, send email to nodejs@googlegroups.com
    To unsubscribe from this group, send email to
    nodejs+unsubscribe@googlegroups.com
    For more options, visit this group at
    http://groups.google.com/group/nodejs?hl=en?hl=en
  • Greelgorke at Nov 2, 2012 at 4:16 pm
    1. do not use Class word :)
    2. it's ok to use helpers, DRY is key
    3. your helper doesn't look very helpful for me
    3.1 usage of your helper doesn't seem significant shorter than the pure
    way to write this things down, looks even more verbose to me, without
    serving readability (TJ's point)
    3.2 everywhere Hardcoded reference to the "super"-Contsructor function ->
    changing the inheritance chain is more complicated at development time,
    even harder or impossible at runtime.
    4. it's not lightweight OOP but lightweight inheritance. OO is more than
    inheritance (in fact it doesn't even need inheritance)

    my opinion from the first sight

    greets


    Am Freitag, 2. November 2012 16:46:50 UTC+1 schrieb Fredrik O:
    Thanks for answer, everyone, it is pleasant :-)

    To just clear my point. I understand why raw JavaScript inheritance often
    is preferred, no need to know what "Class" does for example. Simply
    speaking can every single JavaScript programmer see what is going on. But
    now to my point.

    Say I am writing many small modules. Those modules should only export some
    function who gives some type of functionality. The user of those modules
    only care about the functionality and how it behaves, not how it is
    actually implemented. Say now it takes somewhat shorter time when I use a
    helper function than it would without it, why should I not use then?

    The "dependency" is included in the source, so every developer can fast
    and easily check it up. The generated function will have the same
    performance as the handwritten function probably and it will increase the
    readability of the source code somewhat. The function helper itself does
    not use any advanced JavaScript, all serious developers should understand
    it and no fancy stuff is added. So why is it not preferred to use a helper
    function in those situations? I cannot really get it when those advantages
    is applied.


    Den fredagen den 2:e november 2012 kl. 09:07:47 UTC+1 skrev Wil Moore:
    I agree with Isaac,

    Build classical function helpers as a learning experience, which which
    will show you that you don't need them.

    Read and write a lot of idiomatic JavaScript and you'll quickly get over
    (and actually start to like) the syntax of "Constructor.prototype.*". I
    personally fought this for much longer than necessary. Once you get over
    it, hundred-line object literals (including the popular "module" pattern)
    will start to look extremely obtuse and superfluous.

    Either way, JavaScript is really fun so go write cool things and enjoy it
    :)
    --
    Job Board: http://jobs.nodejs.org/
    Posting guidelines: https://github.com/joyent/node/wiki/Mailing-List-Posting-Guidelines
    You received this message because you are subscribed to the Google
    Groups "nodejs" group.
    To post to this group, send email to nodejs@googlegroups.com
    To unsubscribe from this group, send email to
    nodejs+unsubscribe@googlegroups.com
    For more options, visit this group at
    http://groups.google.com/group/nodejs?hl=en?hl=en
  • Fredrik O at Nov 2, 2012 at 5:33 pm
    Thanks for answer, greelgorke.

    1. It is just a name of a variable.
    2. I agree.
    3. It only does what every developer must type down anyway to implement
    "classes" in JavaScript.
    3.1 It don´t need to be significant shorter, but it is indeed shorter and
    more readable if you ask me. The purpose was never to do any fancy stuff
    like many others "Class" helpers, it was never the idea, but to automate
    those things you must do anyway. The returned object should always be 100%
    compatible with raw JavaScript "classes".
    3.2 Please show a minimal example or give a link which will describe it
    more.
    4. Wrong, OOP is about classes/objects and this is exactly what the helper
    function is about, by creating a minimal "class". A "class object" in the
    OOP world is anyway just a bunch of methods and a set of features, which I
    prefer to see separate.

    Den fredagen den 2:e november 2012 kl. 17:16:48 UTC+1 skrev greelgorke:
    1. do not use Class word :)
    2. it's ok to use helpers, DRY is key
    3. your helper doesn't look very helpful for me
    3.1 usage of your helper doesn't seem significant shorter than the pure
    way to write this things down, looks even more verbose to me, without
    serving readability (TJ's point)
    3.2 everywhere Hardcoded reference to the "super"-Contsructor function ->
    changing the inheritance chain is more complicated at development time,
    even harder or impossible at runtime.
    4. it's not lightweight OOP but lightweight inheritance. OO is more than
    inheritance (in fact it doesn't even need inheritance)

    my opinion from the first sight

    greets


    Am Freitag, 2. November 2012 16:46:50 UTC+1 schrieb Fredrik O:
    Thanks for answer, everyone, it is pleasant :-)

    To just clear my point. I understand why raw JavaScript inheritance often
    is preferred, no need to know what "Class" does for example. Simply
    speaking can every single JavaScript programmer see what is going on. But
    now to my point.

    Say I am writing many small modules. Those modules should only export
    some function who gives some type of functionality. The user of those
    modules only care about the functionality and how it behaves, not how it is
    actually implemented. Say now it takes somewhat shorter time when I use a
    helper function than it would without it, why should I not use then?

    The "dependency" is included in the source, so every developer can fast
    and easily check it up. The generated function will have the same
    performance as the handwritten function probably and it will increase the
    readability of the source code somewhat. The function helper itself does
    not use any advanced JavaScript, all serious developers should
    understand it and no fancy stuff is added. So why is it not preferred to
    use a helper function in those situations? I cannot really get it when
    those advantages is applied.


    Den fredagen den 2:e november 2012 kl. 09:07:47 UTC+1 skrev Wil Moore:
    I agree with Isaac,

    Build classical function helpers as a learning experience, which which
    will show you that you don't need them.

    Read and write a lot of idiomatic JavaScript and you'll quickly get over
    (and actually start to like) the syntax of "Constructor.prototype.*". I
    personally fought this for much longer than necessary. Once you get over
    it, hundred-line object literals (including the popular "module" pattern)
    will start to look extremely obtuse and superfluous.

    Either way, JavaScript is really fun so go write cool things and enjoy
    it :)
    --
    Job Board: http://jobs.nodejs.org/
    Posting guidelines: https://github.com/joyent/node/wiki/Mailing-List-Posting-Guidelines
    You received this message because you are subscribed to the Google
    Groups "nodejs" group.
    To post to this group, send email to nodejs@googlegroups.com
    To unsubscribe from this group, send email to
    nodejs+unsubscribe@googlegroups.com
    For more options, visit this group at
    http://groups.google.com/group/nodejs?hl=en?hl=en
  • Dominick Pham at Nov 3, 2012 at 1:43 pm
    I think greelgorke's comment about not using Class as a variable is
    completely valid. 'class' is a reserved keyword, 'Class' probably won't
    ever be, but it's too close to a reserved keyword. In fact, I had to double
    check to make sure I wasn't crazy because I thought Class might have been
    reserved as well. I'm not a typist, I make mistakes when trying to type too
    fast, especially the kind where I miss the shift key. You should be kind to
    people like me.
    On Friday, November 2, 2012 1:33:55 PM UTC-4, Fredrik O wrote:

    Thanks for answer, greelgorke.

    1. It is just a name of a variable.
    2. I agree.
    3. It only does what every developer must type down anyway to implement
    "classes" in JavaScript.
    3.1 It don´t need to be significant shorter, but it is indeed shorter and
    more readable if you ask me. The purpose was never to do any fancy stuff
    like many others "Class" helpers, it was never the idea, but to automate
    those things you must do anyway. The returned object should always be 100%
    compatible with raw JavaScript "classes".
    3.2 Please show a minimal example or give a link which will describe it
    more.
    4. Wrong, OOP is about classes/objects and this is exactly what the helper
    function is about, by creating a minimal "class". A "class object" in the
    OOP world is anyway just a bunch of methods and a set of features, which I
    prefer to see separate.

    Den fredagen den 2:e november 2012 kl. 17:16:48 UTC+1 skrev greelgorke:
    1. do not use Class word :)
    2. it's ok to use helpers, DRY is key
    3. your helper doesn't look very helpful for me
    3.1 usage of your helper doesn't seem significant shorter than the pure
    way to write this things down, looks even more verbose to me, without
    serving readability (TJ's point)
    3.2 everywhere Hardcoded reference to the "super"-Contsructor function
    -> changing the inheritance chain is more complicated at development time,
    even harder or impossible at runtime.
    4. it's not lightweight OOP but lightweight inheritance. OO is more than
    inheritance (in fact it doesn't even need inheritance)

    my opinion from the first sight

    greets


    Am Freitag, 2. November 2012 16:46:50 UTC+1 schrieb Fredrik O:
    Thanks for answer, everyone, it is pleasant :-)

    To just clear my point. I understand why raw JavaScript inheritance
    often is preferred, no need to know what "Class" does for example. Simply
    speaking can every single JavaScript programmer see what is going on. But
    now to my point.

    Say I am writing many small modules. Those modules should only export
    some function who gives some type of functionality. The user of those
    modules only care about the functionality and how it behaves, not how it is
    actually implemented. Say now it takes somewhat shorter time when I use a
    helper function than it would without it, why should I not use then?

    The "dependency" is included in the source, so every developer can fast
    and easily check it up. The generated function will have the same
    performance as the handwritten function probably and it will increase the
    readability of the source code somewhat. The function helper itself
    does not use any advanced JavaScript, all serious developers should
    understand it and no fancy stuff is added. So why is it not preferred to
    use a helper function in those situations? I cannot really get it when
    those advantages is applied.


    Den fredagen den 2:e november 2012 kl. 09:07:47 UTC+1 skrev Wil Moore:
    I agree with Isaac,

    Build classical function helpers as a learning experience, which which
    will show you that you don't need them.

    Read and write a lot of idiomatic JavaScript and you'll quickly get
    over (and actually start to like) the syntax of "Constructor.prototype.*".
    I personally fought this for much longer than necessary. Once you get over
    it, hundred-line object literals (including the popular "module" pattern)
    will start to look extremely obtuse and superfluous.

    Either way, JavaScript is really fun so go write cool things and enjoy
    it :)
    --
    Job Board: http://jobs.nodejs.org/
    Posting guidelines: https://github.com/joyent/node/wiki/Mailing-List-Posting-Guidelines
    You received this message because you are subscribed to the Google
    Groups "nodejs" group.
    To post to this group, send email to nodejs@googlegroups.com
    To unsubscribe from this group, send email to
    nodejs+unsubscribe@googlegroups.com
    For more options, visit this group at
    http://groups.google.com/group/nodejs?hl=en?hl=en
  • Fredrik O at Nov 3, 2012 at 2:35 pm
    Thanks for answer, Dominick.

    I know the word "class" is a reserved word. I only used it in the gist to
    make it more clear what it does. But the JavaScript library "joose" use it
    and I have never read anything negative about it. But in the end, it is
    just a name and the user is free to name it whatever she/he wants.

    I only want to question way it is so wrong to use a helper function to
    return a function which we otherwise must explicitly create. We could to
    example in the gist remove the options.baseClass and put it in the method
    object and even rename it, if it feels more comfortable:

    var Derived = lib({
    __inherits: Base, //inherits from Base
    constructor: function() {
    // constructor logic goes here
    },
    someMethod: function() {
    // someMethod logic goes here
    }
    });

    In which way I am not kind?

    Den lördagen den 3:e november 2012 kl. 14:42:58 UTC+1 skrev Dominick Pham:
    I think greelgorke's comment about not using Class as a variable is
    completely valid. 'class' is a reserved keyword, 'Class' probably won't
    ever be, but it's too close to a reserved keyword. In fact, I had to double
    check to make sure I wasn't crazy because I thought Class might have been
    reserved as well. I'm not a typist, I make mistakes when trying to type too
    fast, especially the kind where I miss the shift key. You should be kind to
    people like me.
    On Friday, November 2, 2012 1:33:55 PM UTC-4, Fredrik O wrote:

    Thanks for answer, greelgorke.

    1. It is just a name of a variable.
    2. I agree.
    3. It only does what every developer must type down anyway to implement
    "classes" in JavaScript.
    3.1 It don´t need to be significant shorter, but it is indeed shorter and
    more readable if you ask me. The purpose was never to do any fancy stuff
    like many others "Class" helpers, it was never the idea, but to automate
    those things you must do anyway. The returned object should always be 100%
    compatible with raw JavaScript "classes".
    3.2 Please show a minimal example or give a link which will describe it
    more.
    4. Wrong, OOP is about classes/objects and this is exactly what the
    helper function is about, by creating a minimal "class". A "class object"
    in the OOP world is anyway just a bunch of methods and a set of features,
    which I prefer to see separate.

    Den fredagen den 2:e november 2012 kl. 17:16:48 UTC+1 skrev greelgorke:
    1. do not use Class word :)
    2. it's ok to use helpers, DRY is key
    3. your helper doesn't look very helpful for me
    3.1 usage of your helper doesn't seem significant shorter than the pure
    way to write this things down, looks even more verbose to me, without
    serving readability (TJ's point)
    3.2 everywhere Hardcoded reference to the "super"-Contsructor function
    -> changing the inheritance chain is more complicated at development time,
    even harder or impossible at runtime.
    4. it's not lightweight OOP but lightweight inheritance. OO is more than
    inheritance (in fact it doesn't even need inheritance)

    my opinion from the first sight

    greets


    Am Freitag, 2. November 2012 16:46:50 UTC+1 schrieb Fredrik O:
    Thanks for answer, everyone, it is pleasant :-)

    To just clear my point. I understand why raw JavaScript inheritance
    often is preferred, no need to know what "Class" does for example. Simply
    speaking can every single JavaScript programmer see what is going on. But
    now to my point.

    Say I am writing many small modules. Those modules should only export
    some function who gives some type of functionality. The user of those
    modules only care about the functionality and how it behaves, not how it is
    actually implemented. Say now it takes somewhat shorter time when I use a
    helper function than it would without it, why should I not use then?

    The "dependency" is included in the source, so every developer can fast
    and easily check it up. The generated function will have the same
    performance as the handwritten function probably and it will increase the
    readability of the source code somewhat. The function helper itself
    does not use any advanced JavaScript, all serious developers should
    understand it and no fancy stuff is added. So why is it not preferred to
    use a helper function in those situations? I cannot really get it when
    those advantages is applied.


    Den fredagen den 2:e november 2012 kl. 09:07:47 UTC+1 skrev Wil Moore:
    I agree with Isaac,

    Build classical function helpers as a learning experience, which which
    will show you that you don't need them.

    Read and write a lot of idiomatic JavaScript and you'll quickly get
    over (and actually start to like) the syntax of "Constructor.prototype.*".
    I personally fought this for much longer than necessary. Once you get over
    it, hundred-line object literals (including the popular "module" pattern)
    will start to look extremely obtuse and superfluous.

    Either way, JavaScript is really fun so go write cool things and enjoy
    it :)
    --
    Job Board: http://jobs.nodejs.org/
    Posting guidelines: https://github.com/joyent/node/wiki/Mailing-List-Posting-Guidelines
    You received this message because you are subscribed to the Google
    Groups "nodejs" group.
    To post to this group, send email to nodejs@googlegroups.com
    To unsubscribe from this group, send email to
    nodejs+unsubscribe@googlegroups.com
    For more options, visit this group at
    http://groups.google.com/group/nodejs?hl=en?hl=en
  • Greelgorke at Nov 5, 2012 at 9:02 am
    1. Yes, it is, but this word is overburden with a bunch of semantics and
    introduces the classical OO mindset immediately. But, it's your helper,
    name it like you wish and deal the with the consequences :)
    3. I guess "helpful" is a matter of flavor and familiarity. i don't see the
    need to type down "classes" in js, may be thats the point.
    3.1 a helper in a sense of DRY have to reduce amount of code. now instead
    of typing down the prototype, constructor etc, you have to pass objects,
    that's just anouther side of the same verbosity and it changes the
    semantics here a bit ("i use classical mindset now").
    3.2 your gist: to change the prototype of the Derived2 class you have to
    change lines
    47: call to "base" constructor
    51: call to getText from "base" proto, simulating super.getText
    57: Change property baseClass

    to change prototype at runtime you have to do even more, like replacing the
    getText property with a new function with the call to the new prototype.
    etc.

    4. This is really a topic with potential to produce a next world war. there
    are so many definitions of OO and most of them are near by a dogma. OO is
    about Objects, objects encapsulate and hide internal data/state and offer
    public API to manipulate this data. Allan Key said in 2003:
    "*OOP to me means only messaging, local retention and protection and
    hiding of state-process, and extreme LateBinding<http://c2.com/cgi/wiki?LateBinding> of
    all things.*"
    No word of classes anymore. Classes are state of the art to define Types in
    OO, but its not the only way to do that. Inheritance is a preferred way to
    share and reuse Code in OO, but it's not the only way, "Favor Composition
    over Inheritance" is one of OO-Design Principles, because it's introduces
    looser coupling than the coupling offered by classical inheritance.
    @Alexey: it's an easy way, becaue in most OO languages classical
    Inheritance is supported by the runtime. it offers all the clutter for
    dynamic lookup of methods/functions. But you could handle it also perfectly
    easy by mixing, borrowing, decorating/wrapping, curring etc. all it misses
    is the runtime support for such constructs. fortunately there are libs
    which can help.
    In fact, if you really think about it, classical inheritance is nothing
    more than composition with tight coupling and automatic delegate
    resolution. JS prototypal inheritance allows loose coupling, and thats it
    what it make so powerful.

    Greet :)


    Am Freitag, 2. November 2012 18:33:55 UTC+1 schrieb Fredrik O:
    Thanks for answer, greelgorke.

    1. It is just a name of a variable.
    2. I agree.
    3. It only does what every developer must type down anyway to implement
    "classes" in JavaScript.
    3.1 It don´t need to be significant shorter, but it is indeed shorter and
    more readable if you ask me. The purpose was never to do any fancy stuff
    like many others "Class" helpers, it was never the idea, but to automate
    those things you must do anyway. The returned object should always be 100%
    compatible with raw JavaScript "classes".
    3.2 Please show a minimal example or give a link which will describe it
    more.
    4. Wrong, OOP is about classes/objects and this is exactly what the helper
    function is about, by creating a minimal "class". A "class object" in the
    OOP world is anyway just a bunch of methods and a set of features, which I
    prefer to see separate.
    Den fredagen den 2:e november 2012 kl. 17:16:48 UTC+1 skrev greelgorke:
    1. do not use Class word :)
    2. it's ok to use helpers, DRY is key
    3. your helper doesn't look very helpful for me
    3.1 usage of your helper doesn't seem significant shorter than the pure
    way to write this things down, looks even more verbose to me, without
    serving readability (TJ's point)
    3.2 everywhere Hardcoded reference to the "super"-Contsructor function
    -> changing the inheritance chain is more complicated at development time,
    even harder or impossible at runtime.
    4. it's not lightweight OOP but lightweight inheritance. OO is more than
    inheritance (in fact it doesn't even need inheritance)

    my opinion from the first sight

    greets


    Am Freitag, 2. November 2012 16:46:50 UTC+1 schrieb Fredrik O:
    Thanks for answer, everyone, it is pleasant :-)

    To just clear my point. I understand why raw JavaScript inheritance
    often is preferred, no need to know what "Class" does for example. Simply
    speaking can every single JavaScript programmer see what is going on. But
    now to my point.

    Say I am writing many small modules. Those modules should only export
    some function who gives some type of functionality. The user of those
    modules only care about the functionality and how it behaves, not how it is
    actually implemented. Say now it takes somewhat shorter time when I use a
    helper function than it would without it, why should I not use then?

    The "dependency" is included in the source, so every developer can fast
    and easily check it up. The generated function will have the same
    performance as the handwritten function probably and it will increase the
    readability of the source code somewhat. The function helper itself
    does not use any advanced JavaScript, all serious developers should
    understand it and no fancy stuff is added. So why is it not preferred to
    use a helper function in those situations? I cannot really get it when
    those advantages is applied.


    Den fredagen den 2:e november 2012 kl. 09:07:47 UTC+1 skrev Wil Moore:
    I agree with Isaac,

    Build classical function helpers as a learning experience, which which
    will show you that you don't need them.

    Read and write a lot of idiomatic JavaScript and you'll quickly get
    over (and actually start to like) the syntax of "Constructor.prototype.*".
    I personally fought this for much longer than necessary. Once you get over
    it, hundred-line object literals (including the popular "module" pattern)
    will start to look extremely obtuse and superfluous.

    Either way, JavaScript is really fun so go write cool things and enjoy
    it :)
    --
    Job Board: http://jobs.nodejs.org/
    Posting guidelines: https://github.com/joyent/node/wiki/Mailing-List-Posting-Guidelines
    You received this message because you are subscribed to the Google
    Groups "nodejs" group.
    To post to this group, send email to nodejs@googlegroups.com
    To unsubscribe from this group, send email to
    nodejs+unsubscribe@googlegroups.com
    For more options, visit this group at
    http://groups.google.com/group/nodejs?hl=en?hl=en
  • Fredrik O at Nov 5, 2012 at 7:15 pm
    Den måndagen den 5:e november 2012 kl. 10:01:58 UTC+1 skrev greelgorke:
    3. I guess "helpful" is a matter of flavor and familiarity. i don't see
    the need to type down "classes" in js, may be thats the point.
    3.1 a helper in a sense of DRY have to reduce amount of code. now instead
    of typing down the prototype, constructor etc, you have to pass objects,
    that's just anouther side of the same verbosity and it changes the
    semantics here a bit ("i use classical mindset now").
    It reduces the amount of code you must type down:

    var Name = helper({
    method1: function() {
    },
    method2: function() {
    },
    //..
    });

    vs

    function Name() {
    }
    Name.prototype.method1 = function() {
    };
    Name.prototype.method2 = function() {
    };
    //...
    Without the helper, you must repetitive times write: "Name.prototype". You
    can of course assign it in the function using this, but it is bad practice
    and has poor performance. And as soon you start to use any helper variable
    and function, do you use code you argue against.

    3.2 your gist: to change the prototype of the Derived2 class you have to
    change lines
    47: call to "base" constructor
    51: call to getText from "base" proto, simulating super.getText
    57: Change property baseClass

    to change prototype at runtime you have to do even more, like replacing
    the getText property with a new function with the call to the new
    prototype. etc.
    And in which way can you skip this in normal prototype inheritance?

    4. This is really a topic with potential to produce a next world war. there
    are so many definitions of OO and most of them are near by a dogma. OO is
    about Objects, objects encapsulate and hide internal data/state and offer
    public API to manipulate this data. Allan Key said in 2003:
    "*OOP to me means only messaging, local retention and protection and
    hiding of state-process, and extreme LateBinding<http://c2.com/cgi/wiki?LateBinding> of
    all things.*"
    No word of classes anymore. Classes are state of the art to define Types
    in OO, but its not the only way to do that. Inheritance is a preferred way
    to share and reuse Code in OO, but it's not the only way, "Favor
    Composition over Inheritance" is one of OO-Design Principles, because it's
    introduces looser coupling than the coupling offered by classical
    inheritance.
    I am not a big fan of inheritance nor OO, but sure can it be great, same as
    multiple inheritance.

    --
    Job Board: http://jobs.nodejs.org/
    Posting guidelines: https://github.com/joyent/node/wiki/Mailing-List-Posting-Guidelines
    You received this message because you are subscribed to the Google
    Groups "nodejs" group.
    To post to this group, send email to nodejs@googlegroups.com
    To unsubscribe from this group, send email to
    nodejs+unsubscribe@googlegroups.com
    For more options, visit this group at
    http://groups.google.com/group/nodejs?hl=en?hl=en
  • Jake Verbaten at Nov 6, 2012 at 4:02 am
    function Name() {}

    extend(Name.prototype, {
    ...
    })

    Tada. No more typing.

    On Mon, Nov 5, 2012 at 11:07 AM, Fredrik O wrote:

    Den måndagen den 5:e november 2012 kl. 10:01:58 UTC+1 skrev greelgorke:
    3. I guess "helpful" is a matter of flavor and familiarity. i don't see
    the need to type down "classes" in js, may be thats the point.
    3.1 a helper in a sense of DRY have to reduce amount of code. now instead
    of typing down the prototype, constructor etc, you have to pass objects,
    that's just anouther side of the same verbosity and it changes the
    semantics here a bit ("i use classical mindset now").
    It reduces the amount of code you must type down:

    var Name = helper({
    method1: function() {
    },
    method2: function() {
    },
    //..
    });

    vs

    function Name() {
    }
    Name.prototype.method1 = function() {
    };
    Name.prototype.method2 = function() {
    };
    //...
    Without the helper, you must repetitive times write: "Name.prototype".
    You can of course assign it in the function using this, but it is bad
    practice and has poor performance. And as soon you start to use any helper
    variable and function, do you use code you argue against.

    3.2 your gist: to change the prototype of the Derived2 class you have to
    change lines
    47: call to "base" constructor
    51: call to getText from "base" proto, simulating super.getText
    57: Change property baseClass

    to change prototype at runtime you have to do even more, like replacing
    the getText property with a new function with the call to the new
    prototype. etc.
    And in which way can you skip this in normal prototype inheritance?

    4. This is really a topic with potential to produce a next world war.
    there are so many definitions of OO and most of them are near by a dogma.
    OO is about Objects, objects encapsulate and hide internal data/state and
    offer public API to manipulate this data. Allan Key said in 2003:
    "*OOP to me means only messaging, local retention and protection and
    hiding of state-process, and extreme LateBinding<http://c2.com/cgi/wiki?LateBinding> of
    all things.*"
    No word of classes anymore. Classes are state of the art to define Types
    in OO, but its not the only way to do that. Inheritance is a preferred way
    to share and reuse Code in OO, but it's not the only way, "Favor
    Composition over Inheritance" is one of OO-Design Principles, because it's
    introduces looser coupling than the coupling offered by classical
    inheritance.
    I am not a big fan of inheritance nor OO, but sure can it be great, same
    as multiple inheritance.

    --
    Job Board: http://jobs.nodejs.org/
    Posting guidelines:
    https://github.com/joyent/node/wiki/Mailing-List-Posting-Guidelines
    You received this message because you are subscribed to the Google
    Groups "nodejs" group.
    To post to this group, send email to nodejs@googlegroups.com
    To unsubscribe from this group, send email to
    nodejs+unsubscribe@googlegroups.com
    For more options, visit this group at
    http://groups.google.com/group/nodejs?hl=en?hl=en
    --
    Job Board: http://jobs.nodejs.org/
    Posting guidelines: https://github.com/joyent/node/wiki/Mailing-List-Posting-Guidelines
    You received this message because you are subscribed to the Google
    Groups "nodejs" group.
    To post to this group, send email to nodejs@googlegroups.com
    To unsubscribe from this group, send email to
    nodejs+unsubscribe@googlegroups.com
    For more options, visit this group at
    http://groups.google.com/group/nodejs?hl=en?hl=en
  • Tjholowaychuk at Nov 6, 2012 at 4:22 am
    "without the helper, you must repetitive times write:
    "Name.prototype""

    still looks better, and the additional context is worth it IMO, plus
    editors are good
    at dealing with repetitive tasks, at least half the code I "write" is
    not typed, I think the
    same goes lots of devs
    On Nov 5, 8:02 pm, Jake Verbaten wrote:
    function Name() {}

    extend(Name.prototype, {
    ...

    })

    Tada. No more typing.






    On Mon, Nov 5, 2012 at 11:07 AM, Fredrik O wrote:
    Den måndagen den 5:e november 2012 kl. 10:01:58 UTC+1 skrev greelgorke:
    3. I guess "helpful" is a matter of flavor and familiarity. i don't see
    the need to type down "classes" in js, may be thats the point.
    3.1 a helper in a sense of DRY have to reduce amount of code. now instead
    of typing down the prototype, constructor etc, you have to pass objects,
    that's just anouther side of the same verbosity and it changes the
    semantics here a bit ("i use classical mindset now").
    It reduces the amount of code you must type down:
    var Name = helper({
    method1: function() {
    },
    method2: function() {
    },
    //..
    });
    vs
    function Name() {
    }
    Name.prototype.method1 = function() {
    };
    Name.prototype.method2 = function() {
    };
    //...
    Without the helper, you must repetitive times write: "Name.prototype".
    You can of course assign it in the function using this, but it is bad
    practice and has poor performance. And as soon you start to use any helper
    variable and function, do you use code you argue against.
    3.2 your gist: to change the prototype of the Derived2 class you have to
    change lines
    47: call to "base" constructor
    51: call to getText from "base" proto, simulating super.getText
    57: Change property baseClass
    to change prototype at runtime you have to do even more, like replacing
    the getText property with a new function with the call to the new
    prototype. etc.
    And in which way can you skip this in normal prototype inheritance?
    4. This is really a topic with potential to produce a next world war.
    there are so many definitions of OO and most of them are near by a dogma.
    OO is about Objects, objects encapsulate and hide internal data/state and
    offer public API to manipulate this data. Allan Key said in 2003:
    "*OOP to me means only messaging, local retention and protection and
    hiding of state-process, and extreme LateBinding<http://c2.com/cgi/wiki?LateBinding> of
    all things.*"
    No word of classes anymore. Classes are state of the art to define Types
    in OO, but its not the only way to do that. Inheritance is a preferred way
    to share and reuse Code in OO, but it's not the only way, "Favor
    Composition over Inheritance" is one of OO-Design Principles, because it's
    introduces looser coupling than the coupling offered by classical
    inheritance.
    I am not a big fan of inheritance nor OO, but sure can it be great, same
    as multiple inheritance.
    --
    Job Board:http://jobs.nodejs.org/
    Posting guidelines:
    https://github.com/joyent/node/wiki/Mailing-List-Posting-Guidelines
    You received this message because you are subscribed to the Google
    Groups "nodejs" group.
    To post to this group, send email to nodejs@googlegroups.com
    To unsubscribe from this group, send email to
    nodejs+unsubscribe@googlegroups.com
    For more options, visit this group at
    http://groups.google.com/group/nodejs?hl=en?hl=en
    --
    Job Board: http://jobs.nodejs.org/
    Posting guidelines: https://github.com/joyent/node/wiki/Mailing-List-Posting-Guidelines
    You received this message because you are subscribed to the Google
    Groups "nodejs" group.
    To post to this group, send email to nodejs@googlegroups.com
    To unsubscribe from this group, send email to
    nodejs+unsubscribe@googlegroups.com
    For more options, visit this group at
    http://groups.google.com/group/nodejs?hl=en?hl=en
  • Greelgorke at Nov 6, 2012 at 9:07 am
    "And in which way can you skip this in normal prototype inheritance?"

    using this.constructor.prototype.getText in the instance methods (also the
    non-standard shorthand this.__proto__ in code, that can be
    vendor-specific). in this case you can just assign another object as
    prototype and the code works, even at runtime. Of cause you could do this
    in your gist too, but you didn't. and TJ is right. Editors are good at the
    job to reduce typing and insert code patterns without changing the
    semantics. :) your tool, the helper, change it, not in it's implementation,
    but in it's usage, thats the main point. It hides the nature. JS knows and
    uses different extension patterns and your tool introduces (at usage point)
    the wrong semantic. as i said, inheritance is not the only way to reuse
    code and its valid even more for JS, where mixins and method borrowing are
    common technics. so as user i see your Class helper and do not know at this
    point, how it handles code re-usage. thats it.


    Am Montag, 5. November 2012 20:07:30 UTC+1 schrieb Fredrik O:
    Den måndagen den 5:e november 2012 kl. 10:01:58 UTC+1 skrev greelgorke:
    3. I guess "helpful" is a matter of flavor and familiarity. i don't see
    the need to type down "classes" in js, may be thats the point.
    3.1 a helper in a sense of DRY have to reduce amount of code. now instead
    of typing down the prototype, constructor etc, you have to pass objects,
    that's just anouther side of the same verbosity and it changes the
    semantics here a bit ("i use classical mindset now").
    It reduces the amount of code you must type down:

    var Name = helper({
    method1: function() {
    },
    method2: function() {
    },
    //..
    });

    vs

    function Name() {
    }
    Name.prototype.method1 = function() {
    };
    Name.prototype.method2 = function() {
    };
    //...
    Without the helper, you must repetitive times write: "Name.prototype".
    You can of course assign it in the function using this, but it is bad
    practice and has poor performance. And as soon you start to use any helper
    variable and function, do you use code you argue against.

    3.2 your gist: to change the prototype of the Derived2 class you have to
    change lines
    47: call to "base" constructor
    51: call to getText from "base" proto, simulating super.getText
    57: Change property baseClass

    to change prototype at runtime you have to do even more, like replacing
    the getText property with a new function with the call to the new
    prototype. etc.


    4. This is really a topic with potential to produce a next world war.
    there are so many definitions of OO and most of them are near by a dogma.
    OO is about Objects, objects encapsulate and hide internal data/state and
    offer public API to manipulate this data. Allan Key said in 2003:
    "*OOP to me means only messaging, local retention and protection and
    hiding of state-process, and extreme LateBinding<http://c2.com/cgi/wiki?LateBinding> of
    all things.*"
    No word of classes anymore. Classes are state of the art to define Types
    in OO, but its not the only way to do that. Inheritance is a preferred way
    to share and reuse Code in OO, but it's not the only way, "Favor
    Composition over Inheritance" is one of OO-Design Principles, because it's
    introduces looser coupling than the coupling offered by classical
    inheritance.
    I am not a big fan of inheritance nor OO, but sure can it be great, same
    as multiple inheritance.
    --
    Job Board: http://jobs.nodejs.org/
    Posting guidelines: https://github.com/joyent/node/wiki/Mailing-List-Posting-Guidelines
    You received this message because you are subscribed to the Google
    Groups "nodejs" group.
    To post to this group, send email to nodejs@googlegroups.com
    To unsubscribe from this group, send email to
    nodejs+unsubscribe@googlegroups.com
    For more options, visit this group at
    http://groups.google.com/group/nodejs?hl=en?hl=en
  • Alexey Petrushin at Nov 6, 2012 at 9:28 am
    And in which way can you skip this in normal prototype inheritance?
    Not sure what do You mean, with functional mixins You can skip long
    prototype chains, there are always only one prototype in the chain. Methods
    assembled with applying set of function/mixins to it.

    // Declaring mixins.
    Persistence = fn(klass){
    // Sort-of class-level / singleton method.
    klass.findByName = fn(){}

    // Object - level method.
    klass.prototype.save = fn(){}
    }

    // Model
    Model = fn(){}

    // Injecting mixins.
    Persistence(Model)
    Validations(Model)

    So, there's no need for long prototype chains.

    It actually more advanced than prototypical because allows multiple
    inheritance and inheriting both class-level and obj-level methods.

    --
    Job Board: http://jobs.nodejs.org/
    Posting guidelines: https://github.com/joyent/node/wiki/Mailing-List-Posting-Guidelines
    You received this message because you are subscribed to the Google
    Groups "nodejs" group.
    To post to this group, send email to nodejs@googlegroups.com
    To unsubscribe from this group, send email to
    nodejs+unsubscribe@googlegroups.com
    For more options, visit this group at
    http://groups.google.com/group/nodejs?hl=en?hl=en
  • Alexey Petrushin at Nov 6, 2012 at 9:30 am
    Forgot about superclassing, here it is

    // Declaring mixins.
    Persistence = fn(klass){
    proto = klass.prototype

    proto.saveWithoutFeatureX = proto.save
    proto.save = fn(){}
    }
    On Tuesday, November 6, 2012 1:28:29 PM UTC+4, Alexey Petrushin wrote:

    And in which way can you skip this in normal prototype inheritance?
    Not sure what do You mean, with functional mixins You can skip long
    prototype chains, there are always only one prototype in the chain. Methods
    assembled with applying set of function/mixins to it.

    // Declaring mixins.
    Persistence = fn(klass){
    // Sort-of class-level / singleton method.
    klass.findByName = fn(){}

    // Object - level method.
    klass.prototype.save = fn(){}
    }

    // Model
    Model = fn(){}

    // Injecting mixins.
    Persistence(Model)
    Validations(Model)

    So, there's no need for long prototype chains.

    It actually more advanced than prototypical because allows multiple
    inheritance and inheriting both class-level and obj-level methods.
    --
    Job Board: http://jobs.nodejs.org/
    Posting guidelines: https://github.com/joyent/node/wiki/Mailing-List-Posting-Guidelines
    You received this message because you are subscribed to the Google
    Groups "nodejs" group.
    To post to this group, send email to nodejs@googlegroups.com
    To unsubscribe from this group, send email to
    nodejs+unsubscribe@googlegroups.com
    For more options, visit this group at
    http://groups.google.com/group/nodejs?hl=en?hl=en
  • Fredrik O at Nov 6, 2012 at 6:32 pm
    Thanks for answer, everyone. It is decent of you to take time to answer me.

    Raynos:

    First of was you not allowed to use helpers, but because you did will i
    show you a shorter alternative:

    var Name = myHelper({
    //...
    });

    Tada. No more typing and it does exactly the same thing as your example.


    tjholowaychuk:

    I know editors can remove must of those typing, but as soon as your brain
    sees it, will it
    process it and therefore take energy. It is the inconvenient truth of all
    humans. The advertising industry uses it
    all the time. Because of this, even if you a perfect editor those will fix
    everything for you will it always be preferable to
    have less code, as long as the code does not add any complexity, as it does
    not if you ask me.

    greelgorke:

    Same answer applies to you as tjholowaychuk, so you can read what I wrote
    to her/him as well. Your proposal "this.constructor.prototype.getText"
    does not work by the way, so it should be graceful if you can show a
    minimal code example. And if it exist would it be OK to use it in the
    helper method as well, because it should be 100% compatible with pure
    JavaScript inheritance.

    Alexey Petrushin:

    You are using mixins, nothing wrong with it, sometimes is it preferred to
    actually inherit from another object/function to gain the "is-a" relation.
    With mixins can you only gain the relation "has-a". It is not the same
    thing as the relation "is-a". The "instanceof" operator will not work only
    because you add some methods to a prototype, as it must if it is a "is-a"
    relation. You can however emulate it pretty good do I believe with correct
    instanceof behaviour.


    To all:

    The largest disadvantages the helper class has it is uses the arguments
    parameter to forward all calls. It will prevent huge optimizations if V8 is
    not smart enough.

    --
    Job Board: http://jobs.nodejs.org/
    Posting guidelines: https://github.com/joyent/node/wiki/Mailing-List-Posting-Guidelines
    You received this message because you are subscribed to the Google
    Groups "nodejs" group.
    To post to this group, send email to nodejs@googlegroups.com
    To unsubscribe from this group, send email to
    nodejs+unsubscribe@googlegroups.com
    For more options, visit this group at
    http://groups.google.com/group/nodejs?hl=en?hl=en
  • Greelgorke at Nov 6, 2012 at 9:35 pm
    @Point of reading: well, you might wander, but i developed a superability.
    i's named textscanning and is applyable to common patterns. advertisement
    industry try to break patterns to get you aware of the ad. thats the
    difference. if i see a prototypal based pattern, i just scan over it and
    look over the Constructor.prototype sentence as long it's always the same.
    BUT at the end its more a matter of taste than anything else.

    @Example: I was too fast with my saying, i admit that. take a look at this:

    function Base(){}
    Base.prototype.t = function(){return 'BASE'}

    function Sub(){}
    Sub.prototype = new Base()

    s = new Sub()
    s.t() //'BASE'

    Sub.prototype.t = function(){return 'SUB'}
    s.t() //'SUB'
    Sub.prototype.t = function(){return 'SUB'+
    Sub.prototype.constructor.prototype.t()}
    s.t() //'SUBBASE'

    function Base2(){}
    Base2.prototype.t = function(){return 'BASE2'}
    Sub.prototype = new Base2()
    s.t() // 'SUBBASE2'


    at the end, both variants has their limitations. limitation in this example
    is the long property chain lookup to get the implementation of the
    prototype. in v8 you can use this.__proto__ instead of
    Sub.prototype.constructor.prototype, but __proto__ is non-standard. another
    disadvantage of this approach is, that the instances created before
    reassignment of Sub.prototype still link to old prototype-object. so if we
    continue the above example:

    Sub.prototype.t = function(){return 'SUBSUB'}
    s.t() //still returns SUBBASE2 not SUBSUB

    for me, personaly, this is another issue thad drives me away from
    inheritance as code re-usage strategy. To many indirections and pitfalls.
    code sharing via simple prototype is ok, since it's prefered by v8 for
    optimisations. but i wouldn't reuse/extend objects with it if i don't have
    to.

    @is-a/has-a: it's the point for inheritance. it's is rarely really needed
    to establish is-a relation. It's about Identity or about protection of a
    library as a replacement for interface types? both are not really safe
    viable with instanceof, because constructor property is public and
    assignable. If i have to establish is-a relation, i'd rather do this via
    simple property than prototypes. in fact usage of instanceof is considered
    as smell and should be avoided anyway.

    greet

    Am Dienstag, 6. November 2012 19:32:08 UTC+1 schrieb Fredrik O:
    Thanks for answer, everyone. It is decent of you to take time to answer me.

    Raynos:

    First of was you not allowed to use helpers, but because you did will i
    show you a shorter alternative:

    var Name = myHelper({
    //...
    });

    Tada. No more typing and it does exactly the same thing as your example.


    tjholowaychuk:

    I know editors can remove must of those typing, but as soon as your brain
    sees it, will it
    process it and therefore take energy. It is the inconvenient truth of all
    humans. The advertising industry uses it
    all the time. Because of this, even if you a perfect editor those will fix
    everything for you will it always be preferable to
    have less code, as long as the code does not add any complexity, as it
    does not if you ask me.

    greelgorke:

    Same answer applies to you as tjholowaychuk, so you can read what I wrote
    to her/him as well. Your proposal "this.constructor.prototype.getText"
    does not work by the way, so it should be graceful if you can show a
    minimal code example. And if it exist would it be OK to use it in the
    helper method as well, because it should be 100% compatible with pure
    JavaScript inheritance.

    Alexey Petrushin:

    You are using mixins, nothing wrong with it, sometimes is it preferred to
    actually inherit from another object/function to gain the "is-a" relation.
    With mixins can you only gain the relation "has-a". It is not the same
    thing as the relation "is-a". The "instanceof" operator will not work only
    because you add some methods to a prototype, as it must if it is a "is-a"
    relation. You can however emulate it pretty good do I believe with correct
    instanceof behaviour.


    To all:

    The largest disadvantages the helper class has it is uses the arguments
    parameter to forward all calls. It will prevent huge optimizations if V8 is
    not smart enough.
    --
    Job Board: http://jobs.nodejs.org/
    Posting guidelines: https://github.com/joyent/node/wiki/Mailing-List-Posting-Guidelines
    You received this message because you are subscribed to the Google
    Groups "nodejs" group.
    To post to this group, send email to nodejs@googlegroups.com
    To unsubscribe from this group, send email to
    nodejs+unsubscribe@googlegroups.com
    For more options, visit this group at
    http://groups.google.com/group/nodejs?hl=en?hl=en
  • Tjholowaychuk at Nov 8, 2012 at 4:53 am
    Fredrick: less code does not make the code easier to digest, not even
    close, the vast majority of coffeescript is much smaller, but
    incredibly difficult to disambiguate in your head. Same with re-
    declaring prototypes, sure it's "noise" but it establishes context.
    Much like c++'s magical method invocation is ambiguous with function
    calls, that's just garbage IMO, I'll never enjoy languages that
    promote that sort of thing
    On Nov 6, 10:32 am, Fredrik O wrote:
    Thanks for answer, everyone. It is decent of you to take time to answer me.

    Raynos:

    First of was you not allowed to use helpers, but because you did will i
    show you a shorter alternative:

    var Name = myHelper({
    //...

    });

    Tada. No more typing and it does exactly the same thing as your example.

    tjholowaychuk:

    I know editors can remove must of those typing, but as soon as your brain
    sees it, will it
    process it and therefore take energy. It is the inconvenient truth of all
    humans. The advertising industry uses it
    all the time. Because of this, even if you a perfect editor those will fix
    everything for you will it always be preferable to
    have less code, as long as the code does not add any complexity, as it does
    not if you ask me.

    greelgorke:

    Same answer applies to you as tjholowaychuk, so you can read what I wrote
    to her/him as well. Your proposal  "this.constructor.prototype.getText"
    does not work by the way,  so it should be graceful if you can show a
    minimal code example. And if it exist would it be OK to use it in the
    helper method as well, because it should be 100% compatible with pure
    JavaScript inheritance.

    Alexey Petrushin:

    You are using mixins, nothing wrong with it, sometimes is it preferred to
    actually inherit from another object/function to gain the "is-a" relation.
    With mixins can you only gain the relation "has-a". It is not the same
    thing as the relation "is-a". The "instanceof" operator will not work only
    because you add some methods to a prototype, as it must if it is a "is-a"
    relation. You can however emulate it pretty good do I believe with correct
    instanceof behaviour.

    To all:

    The largest disadvantages the helper class has it is uses the arguments
    parameter to forward all calls. It will prevent huge optimizations if V8 is
    not smart enough.
    --
    Job Board: http://jobs.nodejs.org/
    Posting guidelines: https://github.com/joyent/node/wiki/Mailing-List-Posting-Guidelines
    You received this message because you are subscribed to the Google
    Groups "nodejs" group.
    To post to this group, send email to nodejs@googlegroups.com
    To unsubscribe from this group, send email to
    nodejs+unsubscribe@googlegroups.com
    For more options, visit this group at
    http://groups.google.com/group/nodejs?hl=en?hl=en
  • Fredrik O at Nov 8, 2012 at 3:58 pm
    Most of you misses the point, it is sadly. Why it is preferred to have
    shorter code (as long it does not add any complexity) is it because it will
    make it easier to understand what is happening. That is the largest
    difference between a low level programming language and a high level
    programming language. It is the same thing when anyone type 1+1. It is
    indeed an abstraction and how it is implemented underneath can we just
    ignore.

    In my opinion it is indeed better to group methods close to each other. My
    helper does not add any direct complexity and no "context" is lost, as long
    we know what we helper does as we do. However it has some advantages:

    - It forces the user to write code which can easily be highly optimized by
    the JavaScript engine. All class methods will be defined in the prototype
    and all variables be bound to the object context. No need to be a good Java
    Script programmer.

    - It can take multiple other compile options, so we can example add cache
    options, so the helper automatically set up a cache for some methods,
    specially deterministic methods. Multiple inheritance can probably also be
    properly implemented, so the instanceof operator will work as it can be
    expected, which in that case would be better to use than most mixins.

    You most remember that if you create a mixin and when assign 10 different
    prototypes a set of methods (using a mixin) will the JavaScript engine have
    very hard to optimize it. What you do is actually indeed multiple
    inheritance, but you are not telling the JavaScript engine about it. If you
    would, would it probably give better performance, both in speed and memory
    consumption.

    You does also a terrible mistake, even if an object has a set of methods,
    does it not mean it implements those methods in that way you may believe.
    The only properly way to actually check this is to use the instanceof
    operator. It would be most safe and probably the fastest way to check this.

    tjholowaychuk:

    I assume when you taking about C++ ambiguous invocation you mean operator
    overloading? A line like: "a = b + c" may invoke several functions. In that
    case can I tell you it is a huge benefit to the language and is there to
    make it easier to human to read, as long it is properly overloaded.

    --
    Job Board: http://jobs.nodejs.org/
    Posting guidelines: https://github.com/joyent/node/wiki/Mailing-List-Posting-Guidelines
    You received this message because you are subscribed to the Google
    Groups "nodejs" group.
    To post to this group, send email to nodejs@googlegroups.com
    To unsubscribe from this group, send email to
    nodejs+unsubscribe@googlegroups.com
    For more options, visit this group at
    http://groups.google.com/group/nodejs?hl=en?hl=en
  • Tjholowaychuk at Nov 9, 2012 at 4:16 am
    No I mean how "foo()" within a class method may be another method
    call, global function etc, extremely lame "feature"
    On Nov 8, 7:58 am, Fredrik O wrote:
    Most of you misses the point, it is sadly. Why it is preferred to have
    shorter code (as long it does not add any complexity) is it because it will
    make it easier to understand what is happening. That is the largest
    difference between a low level programming language and a high level
    programming language. It is the same thing when anyone type 1+1. It is
    indeed an abstraction and how it is implemented underneath can we just
    ignore.

    In my opinion it is indeed better to group methods close to each other. My
    helper does not add any direct complexity and no "context" is lost, as long
    we know what we helper does as we do. However it has some advantages:

    - It forces the user to write code which can easily be highly optimized by
    the JavaScript engine. All class methods will be defined in the prototype
    and all variables be bound to the object context. No need to be a good Java
    Script programmer.

    - It can take multiple other compile options, so we can example add cache
    options, so the helper automatically set up a cache for some methods,
    specially deterministic methods. Multiple inheritance can probably also be
    properly implemented, so the instanceof operator will work as it can be
    expected, which in that case would be better to use than most mixins.

    You most remember that if you create a mixin and when assign 10 different
    prototypes a set of methods (using a mixin) will the JavaScript engine have
    very hard to optimize it. What you do is actually indeed multiple
    inheritance, but you are not telling the JavaScript engine about it. If you
    would, would it probably give better performance, both in speed and memory
    consumption.

    You does also a terrible mistake, even if an object has a set of methods,
    does it not mean it implements those methods in that way you may believe.
    The only properly way to actually check this is to use the instanceof
    operator. It would be most safe and probably the fastest way to check this.

    tjholowaychuk:

    I assume when you taking about C++ ambiguous invocation you mean operator
    overloading? A line like: "a = b + c" may invoke several functions. In that
    case can I tell you it is a huge benefit to the language and is there to
    make it easier to human to read, as long it is properly overloaded.
    --
    Job Board: http://jobs.nodejs.org/
    Posting guidelines: https://github.com/joyent/node/wiki/Mailing-List-Posting-Guidelines
    You received this message because you are subscribed to the Google
    Groups "nodejs" group.
    To post to this group, send email to nodejs@googlegroups.com
    To unsubscribe from this group, send email to
    nodejs+unsubscribe@googlegroups.com
    For more options, visit this group at
    http://groups.google.com/group/nodejs?hl=en?hl=en
  • Fredrik O at Nov 9, 2012 at 1:11 pm
    Well, it can very easily be fixed. All good programmers would type "this->
    foo()" if any ambiguously may exist. And no, I disagree, it is not an
    "extreme" lame feature, but of course can it cause some problems if the
    programmer is not writing good readable code. It has some benefits however.


    Den fredagen den 9:e november 2012 kl. 05:16:37 UTC+1 skrev tjholowaychuk:
    No I mean how "foo()" within a class method may be another method
    call, global function etc, extremely lame "feature"
    --
    Job Board: http://jobs.nodejs.org/
    Posting guidelines: https://github.com/joyent/node/wiki/Mailing-List-Posting-Guidelines
    You received this message because you are subscribed to the Google
    Groups "nodejs" group.
    To post to this group, send email to nodejs@googlegroups.com
    To unsubscribe from this group, send email to
    nodejs+unsubscribe@googlegroups.com
    For more options, visit this group at
    http://groups.google.com/group/nodejs?hl=en?hl=en
  • Greelgorke at Nov 9, 2012 at 1:21 pm
    Just to, short, points:
    1. you can easily trick the instanceOf operator, because the constructor
    Property is not write-protected by default.
    2. "No need to be a good Java Script programmer." this sentence is just
    wrong. you should know your tools, in any environment. Thats my opinion.
    Disclaimer: this does not mean that i'm against helpers :)

    Am Donnerstag, 8. November 2012 16:58:09 UTC+1 schrieb Fredrik O:
    Most of you misses the point, it is sadly. Why it is preferred to have
    shorter code (as long it does not add any complexity) is it because it will
    make it easier to understand what is happening. That is the largest
    difference between a low level programming language and a high level
    programming language. It is the same thing when anyone type 1+1. It is
    indeed an abstraction and how it is implemented underneath can we just
    ignore.

    In my opinion it is indeed better to group methods close to each other. My
    helper does not add any direct complexity and no "context" is lost, as long
    we know what we helper does as we do. However it has some advantages:

    - It forces the user to write code which can easily be highly optimized by
    the JavaScript engine. All class methods will be defined in the prototype
    and all variables be bound to the object context. No need to be a good Java
    Script programmer.

    - It can take multiple other compile options, so we can example add cache
    options, so the helper automatically set up a cache for some methods,
    specially deterministic methods. Multiple inheritance can probably also be
    properly implemented, so the instanceof operator will work as it can be
    expected, which in that case would be better to use than most mixins.

    You most remember that if you create a mixin and when assign 10 different
    prototypes a set of methods (using a mixin) will the JavaScript engine have
    very hard to optimize it. What you do is actually indeed multiple
    inheritance, but you are not telling the JavaScript engine about it. If you
    would, would it probably give better performance, both in speed and memory
    consumption.

    You does also a terrible mistake, even if an object has a set of methods,
    does it not mean it implements those methods in that way you may believe.
    The only properly way to actually check this is to use the instanceof
    operator. It would be most safe and probably the fastest way to check this.

    tjholowaychuk:

    I assume when you taking about C++ ambiguous invocation you mean operator
    overloading? A line like: "a = b + c" may invoke several functions. In that
    case can I tell you it is a huge benefit to the language and is there to
    make it easier to human to read, as long it is properly overloaded.
    --
    Job Board: http://jobs.nodejs.org/
    Posting guidelines: https://github.com/joyent/node/wiki/Mailing-List-Posting-Guidelines
    You received this message because you are subscribed to the Google
    Groups "nodejs" group.
    To post to this group, send email to nodejs@googlegroups.com
    To unsubscribe from this group, send email to
    nodejs+unsubscribe@googlegroups.com
    For more options, visit this group at
    http://groups.google.com/group/nodejs?hl=en?hl=en
  • Fredrik O at Nov 9, 2012 at 1:44 pm
    1. You can do many tricks as a programmer in any programming language,
    write ugly code, use anti patterns and so on, but that doesn´t mean you
    should.

    2. When I wrote "good" I mean good as an expert. In that context would I
    say it is correct. You should of course know the programming language you
    use, but you should not need to be an expert at it. Besides, some
    programming language can it be very hard to be an expert in, even if the
    definition of "expert" is subjective.

    Den fredagen den 9:e november 2012 kl. 14:21:51 UTC+1 skrev greelgorke:
    Just to, short, points:
    1. you can easily trick the instanceOf operator, because the constructor
    Property is not write-protected by default.
    2. "No need to be a good Java Script programmer." this sentence is just
    wrong. you should know your tools, in any environment. Thats my opinion.
    Disclaimer: this does not mean that i'm against helpers :)
    --
    Job Board: http://jobs.nodejs.org/
    Posting guidelines: https://github.com/joyent/node/wiki/Mailing-List-Posting-Guidelines
    You received this message because you are subscribed to the Google
    Groups "nodejs" group.
    To post to this group, send email to nodejs@googlegroups.com
    To unsubscribe from this group, send email to
    nodejs+unsubscribe@googlegroups.com
    For more options, visit this group at
    http://groups.google.com/group/nodejs?hl=en?hl=en
  • Greelgorke at Nov 9, 2012 at 8:12 pm
    ok, i see it's a fruitless, because very opinionated, discussion. :) use
    your helper, if you wish, i would use mine, if i need some. Thats ok. i'm
    fine with it. most importante thing is that we all happy with our tools.
    thats it.

    Am Freitag, 9. November 2012 14:44:35 UTC+1 schrieb Fredrik O:
    1. You can do many tricks as a programmer in any programming language,
    write ugly code, use anti patterns and so on, but that doesn´t mean you
    should.

    2. When I wrote "good" I mean good as an expert. In that context would I
    say it is correct. You should of course know the programming language you
    use, but you should not need to be an expert at it. Besides, some
    programming language can it be very hard to be an expert in, even if the
    definition of "expert" is subjective.

    Den fredagen den 9:e november 2012 kl. 14:21:51 UTC+1 skrev greelgorke:
    Just to, short, points:
    1. you can easily trick the instanceOf operator, because the constructor
    Property is not write-protected by default.
    2. "No need to be a good Java Script programmer." this sentence is just
    wrong. you should know your tools, in any environment. Thats my opinion.
    Disclaimer: this does not mean that i'm against helpers :)
    --
    Job Board: http://jobs.nodejs.org/
    Posting guidelines: https://github.com/joyent/node/wiki/Mailing-List-Posting-Guidelines
    You received this message because you are subscribed to the Google
    Groups "nodejs" group.
    To post to this group, send email to nodejs@googlegroups.com
    To unsubscribe from this group, send email to
    nodejs+unsubscribe@googlegroups.com
    For more options, visit this group at
    http://groups.google.com/group/nodejs?hl=en?hl=en
  • Bruno Jouhier at Nov 9, 2012 at 10:05 pm
    Hi Frederik,

    I wrote a helper very similar to yours (with a little plus: a concise
    syntax for property getters and setters) early in our project.

    I just did a grep and we now have more than 250 classes in more than 200
    modules defined with this helper. The helper keeps our code lean,
    consistent, well organized and pleasant to read. And, unlike some of the
    fancier helpers, it does not impact performance. Looking back, this is a
    total winner.

    If this can make you feel better....

    Bruno

    --
    Job Board: http://jobs.nodejs.org/
    Posting guidelines: https://github.com/joyent/node/wiki/Mailing-List-Posting-Guidelines
    You received this message because you are subscribed to the Google
    Groups "nodejs" group.
    To post to this group, send email to nodejs@googlegroups.com
    To unsubscribe from this group, send email to
    nodejs+unsubscribe@googlegroups.com
    For more options, visit this group at
    http://groups.google.com/group/nodejs?hl=en?hl=en
  • Greelgorke at Nov 12, 2012 at 2:02 pm
    @Fredrik: enlightenment and understanding are my targets too. That's why i
    love to talk about such topics as well. And my position, when it comes to a
    daily job, is:

    i would use your helper if i would contribute to your projects, and hell,
    yes i would contribute to your projects, if i had time and interest on the
    topics there. but i also would ask you, why do you use such a helper and
    try to trigger your thinking about it as well :).

    the worst thing is not that people use class-emulating helpers and libs,
    the worst thing is when they do it to avoid the confrontation with the
    language and it's internals. ignorance is the enemy, not tools. you said,
    one has not to be an expert, but a knowledge about fundamental concepts of
    the language is crucial. But many some developers just see "Class" and
    shutdown exploration mode in their brains, asume a paradigm, that isn't
    there, and wonder then, why JS is so lame.

    Am Montag, 12. November 2012 13:47:26 UTC+1 schrieb Fredrik O:
    Hi Bruno,

    It was nice to hear, thanks for sharing that information.

    greelgorke:

    I seek enlightenment and understanding in general. I wanted to get people
    thoughts and why they have those thoughts, by using as much as possible
    real arguments/fact, even if it may be hard within a subject like this.
    Thanks for your contribution (and everybody else for that sake) to this
    thread anyway :-)

    Den fredagen den 9:e november 2012 kl. 23:05:47 UTC+1 skrev Bruno Jouhier:
    Hi Frederik,

    I wrote a helper very similar to yours (with a little plus: a concise
    syntax for property getters and setters) early in our project.

    I just did a grep and we now have more than 250 classes in more than 200
    modules defined with this helper. The helper keeps our code lean,
    consistent, well organized and pleasant to read. And, unlike some of the
    fancier helpers, it does not impact performance. Looking back, this is a
    total winner.

    If this can make you feel better....

    Bruno
    --
    Job Board: http://jobs.nodejs.org/
    Posting guidelines: https://github.com/joyent/node/wiki/Mailing-List-Posting-Guidelines
    You received this message because you are subscribed to the Google
    Groups "nodejs" group.
    To post to this group, send email to nodejs@googlegroups.com
    To unsubscribe from this group, send email to
    nodejs+unsubscribe@googlegroups.com
    For more options, visit this group at
    http://groups.google.com/group/nodejs?hl=en?hl=en
  • Fredrik O at Nov 12, 2012 at 3:58 pm
    I cannot talk about others, every human has responsibility over their own
    knowledge and understanding. But I can talk for myself and I don´t stop
    thinking only because someone use the class word. I trying to see features
    and behaviour, and this behaviour is specially bound to the word "class"
    and "OOP". I choice to use the helper because:

    - It makes the code more simple to read, if you ask me.
    - It will generate a optimized class function which will be very fast and
    have low memory usage.
    - It can implement optional options which allows cache long deterministic
    methods calls.
    - It can implement helpers, like parent "class" with a little cost
    (compiler option)
    - Better encapsulation
    - If you speed up the "Class" function generated, will you speed up every
    instance of it.
    - Automatic generate methods, like default constructors, setters, getters,
    and mix-in behaviour.
    - Add "destructor" and therefore allow some light RAII, which is in my
    opinion the right solution to solve resource leaks.
    - It is 100% compatible with every hard coded class function, I can use it
    together with any existing "class" function.

    By using your arguments would it be equal to say it is stupid to abstract
    away things to be able to look at something on a more higher level.
    Functions was made for this task together with code reuse. You would´t
    normally write the same code twice but create a function for it, but when
    the same thing for "class generation" is it suddenly a "confrontation with
    the language", even I use the most powerful feature of the language? I
    simply don´t agree.

    Den måndagen den 12:e november 2012 kl. 15:01:58 UTC+1 skrev greelgorke:
    i would use your helper if i would contribute to your projects, and hell,
    yes i would contribute to your projects, if i had time and interest on the
    topics there. but i also would ask you, why do you use such a helper and
    try to trigger your thinking about it as well :).
    the worst thing is not that people use class-emulating helpers and libs,
    the worst thing is when they do it to avoid the confrontation with the
    language and it's internals. ignorance is the enemy, not tools. you said,
    one has not to be an expert, but a knowledge about fundamental concepts of
    the language is crucial. But many some developers just see "Class" and
    shutdown exploration mode in their brains, asume a paradigm, that isn't
    there, and wonder then, why JS is so lame.
    --
    Job Board: http://jobs.nodejs.org/
    Posting guidelines: https://github.com/joyent/node/wiki/Mailing-List-Posting-Guidelines
    You received this message because you are subscribed to the Google
    Groups "nodejs" group.
    To post to this group, send email to nodejs@googlegroups.com
    To unsubscribe from this group, send email to
    nodejs+unsubscribe@googlegroups.com
    For more options, visit this group at
    http://groups.google.com/group/nodejs?hl=en?hl=en
  • Alexey Petrushin at Nov 2, 2012 at 9:45 pm
    OO is more than inheritance (in fact it doesn't even need inheritance)
    Depends on what do You mean by 'inheritance' - important part of OO is
    ability to easily create new objects by modifying and extending existing.

    If You mean by inheritance - classical OOP class inheritance - then Yes
    it's not necessary, You can do the same with prototypes or metaprogramming
    or some other.

    But OO needs inheritance in terms of - easy way to create new objects by
    modifying and extending existing - there should be a way to do it.

    --
    Job Board: http://jobs.nodejs.org/
    Posting guidelines: https://github.com/joyent/node/wiki/Mailing-List-Posting-Guidelines
    You received this message because you are subscribed to the Google
    Groups "nodejs" group.
    To post to this group, send email to nodejs@googlegroups.com
    To unsubscribe from this group, send email to
    nodejs+unsubscribe@googlegroups.com
    For more options, visit this group at
    http://groups.google.com/group/nodejs?hl=en?hl=en

Related Discussions

Discussion Navigation
viewthread | post
Discussion Overview
groupnodejs @
categoriesnodejs
postedOct 31, '12 at 10:37p
activeDec 13, '12 at 6:24a
posts42
users15
websitenodejs.org
irc#node.js

People

Translate

site design / logo © 2022 Grokbase