Compare to proto.js

[fresheneesz]

Hi,

I just discovered your library, and it seems incredibly similar to one I made recently: https://github.com/fresheneesz/proto . Its so similar, I want to see if I should drop mine and just use yours. I'm a little hesitant though, because I think mine is simpler and a little more flexible.

I actually spent a little bit of time porting your unit tests into mine, and modified my version slightly to bring it up to speed in a couple areas that pjs did better in (e.g. I added passing the superclass to the class creation function, and inheriting constructors from classic-object functions). Mine also properly inherits from the various Error types (though you still have to name them manually) and allows init constructors to return undefined (via proto.undefined).

Why expose the 'Bare' property? If you want an object to be initializable bare, why not build that ability into your constructor in the first place? I also don't get the point of extend - why have another way to do the same thing?

It kinda pains me to have both of these libraries out there competing. Maybe we can come to an agreement on merging them?

[jneen]

Not bad! The code is a bit hard to read on github - did you indent using a mix of hard tabs and spaces?

Initializing bare objects is useful for interfacing with other class libraries, which is why I exposed .Bare. Ruby does the same with Object#allocate which is used internally.

I may look into special-casing various builtins like Error as you have, although I usually discourage people from using errors in JS for anything other than fatal problems, since the catching mechanism is severely limited.

I'm not sure I understand the point of initializing an object and then returning something different? In pjs, calling the class (with or without new) will always return an instance, which I think is far simpler. If you just wanted side effects, you don't need a class, that's just a function :)

Anyways, nice library - I'm eager to see what you do with it :).

[fresheneesz]

Ah, I probably did, my bad. Its fixed now btw ; )

What do you encourage people to do about errors? If you're talking about issues around catching exceptions in asynchronous code, you could look at another one of my libraries (based on Q promises): https://github.com/fresheneesz/asyncFuture - it enables try-catch-style exception bubbling for asynchronous code (among other things). Sorry none of these have good docs, I've only very recently begun putting a lot of my stuff on github.

proto also allows calling classes with or without new. The idea behind allowing a constructor to return a non-object is about avoiding that extra function you mentioned. If, for example, you have a database object you want to get by id, it sometimes makes more sense to return something like undefined rather than returning a special object or throwing an exception.

I think after crossing code with yours, I'm pretty done with it. I just need to make pretty docs : )

[jneen]

Yeah, in CPS errors are easy - it just takes a separate escape route. In my code, doing database I/O in a constructor would be considered a smell - I usually treat my objects as lightweight structs with methods, in a more functional style.

Good luck, I wish you the best :).