Hacker News Reader

Comment by Jebdm | Hacker News Reader

It seems like a neat idea; it's not the normal Javascript way of operating, but sometimes classes do make more sense. I don't really get why you did Singletons, though. Why not just use a normal object?

View on HN

I've run into a number of situations where it's necessary to initialize and maintain some state in the instance. This is easier done when you have a constructor.

Admittedly, others might not run into these situations, but it's happened to me frequently enough to include it.

I guess it doesn't hurt to have it, especially if you're writing a lot of singletons, but it just seems strange to me to do it explicitly since singletons are extremely easy to implement in prototype-based languages.

  singleton = Object()
  singleton.x = 0
  singleton.foo = function(){
      return x + 1
  }

Edit: Also, why not http://www.prototypejs.org/ ? Not that there's anything wrong with playing around with stuff of course.

I agree, that's what I do now. Adding them is purely for consistency in syntax (sugar, if you will). Using this library, there is a syntactic consistency between declaring types and singletons that you don't have normally.

I use prototype on a day to day basis and I'm not a huge fan. Mootools has captured my attention as being a better alternative, and some of the code was taken from mootools. This is just classes though, not a full JS library.

if you want something like a singleton why do you just:

  var singleton = function (args) {
  
  /*object constructor stuff*/
  
  }(arg-values)

That's another way to do it. The problem is that this way and other ways are not similar, making it hard to go from one form to the other. It's also not the same as declaring a class.

I talk a bit more about what I'm trying to fix earlier: http://justin.harmonize.fm/index.php/2008/12/a-better-object...

Reply on news.ycombinator.com