[nodejs] Simple LightWeight OOP. 100% compatibility with JavaScript. Feedback please!

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.

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

Trololololol ;p

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

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

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

Actually, after discovering functional mixins I stopped use classes in
CoffeeScript.

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

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

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

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

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

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!' );
```

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.

I like the look of those functional mix-ins. Thanks for the link.

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

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

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:

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

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.

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:

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:

Den måndagen den 5:e november 2012 kl. 10:01:58 UTC+1 skrev greelgorke:
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
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
I am not a big fan of inheritance nor OO, but sure can it be great, same as
multiple inheritance.

function Name() {}

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

Tada. No more typing.

"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

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

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.

Forgot about superclassing, here it is

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

proto.saveWithoutFeatureX = proto.save
proto.save = fn(){}
}

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.

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

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

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.

No I mean how "foo()" within a class method may be another method
call, global function etc, extremely lame "feature"

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:

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:

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:

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:

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

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

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:

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.