I already got lost looking at the dollar signs in JS code, honestly who does that!? Back in the old days it was used strictly for generated code, nowadays it's entirely associated with Jquery. I'n guessing you come from a very PHP oriented background.

No, I use the dollar signs to indicate private members as a stopgap to prevent accidental overwriting of internal state from outside code (as you say, nobody else does this so the chance of such an accident are very slim!).  Since all object members are public in JS, I needed to do something, and I hate the look of underscores in code, they break up lines and ruin the flow when reading.  I actually only recently discovered that you could use dollar signs in JS identifiers and as you can see, I latched onto it.

What are your thoughts on closures?

Code: (javascript) [Select]

function MyObject()
{
    var privateVar = 5;
    
    this.doWork = function() {
        Abort(privateVar);
    }
}

Can I ask for a small feature request? I would like to see the ability to show/hide it's visibility. This is useful if you still want it to render but be able to turn it off briefly for an in-battle cutscene or whatever (just so you don't have to manage the render method externally). Many components are built with that in mind.

Good idea on the show/hide feature, I'll have to implement that for 1.6.  Thanks!

As for your question, I used to do the closure thing, can't remember why I stopped.  I know there was a good reason... oh, I remember now!  With a closure like that, you can't do this:

Code: (javascript) [Select]

function MyObject()
{
    var privateVar = 5;
    
    this.doWork = function(otherObj)
    {
        Abort(otherObj.privateVar); // what do you mean it's 'undefined'?!
    }
};

...which means now you have to expose privateVar as a full property and you're back to square one!

Unless otherObj is not a type of MyObject you shouldn't be able to do that anyways. Plus, for that I'd suggest then you define a getter (but not a setter... setters are what should be avoided for private data).

Code: (javascript) [Select]

function MyObject()
{
    var privateVar = 5;
    
    // I think this method is deprecated, but I don't know how else to do this with a closure:
    this.__defineGetter__("var", function() { return privateVar; });
    
    this.doWork = function(otherObj) {
        Abort(otherObj.var);
    }
};

But yeah I can see that if the other object is of type MyObject, you should be able to access private variables (get and set). This is useful for clone functions. If you wanted to go full-bore class interface I'd suggest you use one of the many out there, I know MooTools has one.

I generally prefer to stick with only what tools the language gives me unless a strong case can be made otherwise (I'm a big advocate of KISS). If the cost of doing so is some odd coding conventions here and there, so be it. . Besides, JavaScript's dynamic-ness and duck typing is the thing I love about it. Slapping an inheritance framework on top of it kind of defeats the purpose!

But yeah, that's the use case I was getting at: one object accessing the properties of another of the same type.  I did the getter/setter thing for a while, but eventually had to stop because it's specific to SpiderMonkey (and is even deprecated there!), and TurboSphere uses V8.  The transition is going to be hard enough as it is I'm sure, no sense making it any harder than it has to be.

I did the getter/setter thing for a while, but eventually had to stop because it's specific to SpiderMonkey (and is even deprecated there!), and TurboSphere uses V8.

V8 supports __defineGetter__ and __defineSetter__. Everything except Internet Explorer's JS engine does, actually. It's still ugly though.
Preferably you could check for Object.defineProperty and use that, falling back to __defineGetter__ otherwise. That's an actual language feature introduced in ES5, and thus is much more future-proof (and more powerful) than __defineGetter__.

EDIT: Also, I agree with Radnen, drop the dollar signs, it's not idiomatic JavaScript. Either just let go of your C# background and feel the power of monkey-punching, or use the more accepted underscore.

EDIT: Also, I agree with Radnen, drop the dollar signs, it's not idiomatic JavaScript. Either just let go of your C# background and feel the power of monkey-punching, or use the more accepted underscore.

I agree the dollar signs are pretty ugly, but... monkey-punching?!  Not sure I've ever heard that expression before... what does it mean?

Edit: Also, that would be a C++ background, but... close enough.

Damn, only saw just now: apparently the script to embed GitHub Gists adds a class of 'highlight' to one of the container tables in the generated HTML, so the entire text becomes bold because the forum theme sets that class bold. Fixable with some custom CSS, so give me a small bit of time to make that happen.

I agree the dollar signs are pretty ugly, but... monkey-punching?!  Not sure I've ever heard that expression before... what does it mean?

It's simply replacing methods of an object at runtime. In this case you'd be allowing your private methods to be replaced at runtime. It sounds scary to static language people, but it is surprisingly useful. It is especially common in Ruby circles; Googling "ruby monkey patching" will get a lot of information.
(BTW, I need to brag a little bit about how Common Lisp gets this really right: you don't have to monkey patch, you can just define methods that get run before, after, or around a class's methods. This solves 90% of the uses of monkey patching in a much cleaner way. I'm really not sure why other languages haven't caught onto this yet. Seems to me like C# should pick it up. (They seem to throw in a lot of miscellaneous but useful features.))

IIRC, the name came from "duck punching," like "duck typing." If it doesn't quack like a duck, punch it until it does. It is also known as "monkey patching," and some people like me get confused and just refer to it as "monkey punching."

IIRC, the name came from "duck punching," like "duck typing." If it doesn't quack like a duck, punch it until it does. It is also known as "monkey patching," and some people like me get confused and just refer to it as "monkey punching."

Okay, the duck punching was hilarious. . I needed that laugh, thanks!

For what it's worth, I love the dynamic-ness of JS, a lot more enjoyable to code in than a static language. You need to mock up a quick prototype to try out an experiment in-line, you can, without line upon line of boilerplate creating a new class, types, etc.  Then if it works, you convert the experimental object into a full constructor and go on your way.

New version: 1.6.  This implements the show/hide functionality requested by Radnen.

Just updated kh2Bar, now the bar shouldn't completely empty until HP is exactly zero.

New version: 2.0. See the OP for details, lots of new features in this one!

The combo functionality seems useful. Does it display the damage taken (like in red) and just not subtract it until the combo is done? Because that is neat.

Yes, that's exactly how it works. I noticed when playing KH2 that the delay between when the damage is displayed and when it fades out was variable, but took a whole to realize that the fadeout coincided with the end of a combo (i.e. when you stopped juggling the enemy). Once I realized it I said "hey, that's a great idea!" and implemented it in kh2Bar.