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