3 ms·

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

by Jebdm 18y ago

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?

jmtulloss 18y ago
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.
- Jebdm 18y ago
  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/ http://www.prototypejs.org/ ? Not that there's anything wrong with playing around with stuff of course.
  - jmtulloss 18y ago
    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.
- dantheman 18y ago
  if you want something like a singleton why do you just: var singleton = function (args) { /*object constructor stuff*/ }(arg-values)
  - jmtulloss 18y ago
    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-oriented-javascript/ http://justin.harmonize.fm/index.php/2008/12/a-better-object...

by Jebdm 18y ago

jmtulloss 18y ago

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.

Jebdm 18y ago
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/ http://www.prototypejs.org/ ? Not that there's anything wrong with playing around with stuff of course.
- jmtulloss 18y ago
  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.
dantheman 18y ago
if you want something like a singleton why do you just: var singleton = function (args) { /*object constructor stuff*/ }(arg-values)
- jmtulloss 18y ago
  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-oriented-javascript/ http://justin.harmonize.fm/index.php/2008/12/a-better-object...