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 [email protected] To unsubscribe from this group, send email to [email protected] For more options, visit this group at http://groups.google.com/group/nodejs?hl=en?hl=en
