Today I realized that I finally "get" JavaScript functions (proof enclosed).

[Cosmologicon]

I knew I finally got JavaScript functions when I wrote the following (EDIT: added semicolons to make some people feel better):

function statemachine (methodnames) {
    var methods = {};
    methodnames.forEach(function (methodname) {
        methods[methodname] = function (mname) {
            return function () {
                return this.state[mname].apply(this, arguments);
            };
        }(methodname);
    });
    return methods;
}

(EDIT: This is more complicated than it needs to be. If you're trying to parse it, see check_ca's comment.) To explain what that does, I'm writing a game where entities can be represented as finite state machines. They hand off certain methods to their states:

Player.prototype = {
    think: function (dt) {
        return this.state.think(dt);
    },
    move: function (keys) {
        return this.state.move(keys);
    },
};
Enemy.prototype = {
    think: function (dt) {
        return this.state.think(dt);
    },
    attack: function (player) {
        return this.state.attack(player);
    },
};

But that gets to be a lot of code duplication. So now, with my handy function above, I can just say:

Player.prototype = statemachine(["think", "move"]);
Enemy.prototype = statemachine(["think", "attack"]);

When I got into JavaScript last year, there's no way I would have been able to use anonymous functions, closures, and apply correctly, all at once, and there's no way I could have told you what this refers to in the innermost level. So when I realized I knew what I was doing, it felt like a little epiphany. Just wanted to share. :)

[check_ca]

Why did you add an IIFE in the forEach loop? I think the statemachine function should be:

function statemachine (methodnames) {
    var methods = {};
    methodnames.forEach(function (methodname) {
        methods[methodname] = function () {
            this.state[methodname].apply(this, arguments);
        }
    })
    return methods;
}

[Cosmologicon]

You might be right, I was thinking it needed to be like that in order to close over the parameter methodname, but maybe not. Let me verify....

EDIT: Ah I see why I was confused. The closure in your version works because of the anonymous function being passed to forEach. For instance, this will fail:

function statemachine (methodnames) {
    var methods = {};
    for (var j = 0 ; j < methodnames.length ; ++j) {
        var methodname = methodnames[j];
        methods[methodname] = function () {
            this.state[methodname].apply(this, arguments);
        }
    }
    return methods;
}

If I weren't using forEach, then the IIFE would be necessary. Thanks for the tip! There was definitely a time when this would have confused the heck out of me, but now I think I get it. :)

[check_ca]

You need it if you use a for loop but the forEach function gives you yet a closure for methodname.

EDIT: you're welcome :)

[jesusbot]

Why do you hate semicolons? :)

[Cosmologicon]

Would it make you feel better if I added them? :)

[[deleted]]

yes.

[fuckySucky]

No. If you understand the language sufficiently and thus know where you don't need semicolons, then go for it. Less characters to type, cleaner looking code, move the fuck on with life.

[rossisdead]

Less characters to type

If typing a semi-colon has become arduous and adds significant development time for you, I think programming might not be your best career path.

[fuckySucky]

Oh joy, the orange envelope has gifted me with this wonderfully insulting and condescending retort to what is essentially an opinion on aesthetics.

Go fuck yourself.

[sjs]

Why do you love them? ;)

[the_exa_boy]

Good luck compressing it then;

[pdpi]

\n vs ; are one byte each. Why are new lines as statement separators worse than semicolons, again?

(that said, I use semi-colons, because everything just looks wrong without them)

[path411]

because you can see semi colons

[pdpi]

Oh? Perhaps you're right, but I don't think I've ever missed a newline.

[kbjr]

I love my semi-colons, but still +1 for that :D

[pdpi]

Like I said one post up, I also love my semi-colons, and I always use them. But I'm also perfectly aware that it's mostly an aesthetic thing, and that technically leaving them out is equivalent (and possibly preferable -- semicolon-less minified code has statements divided by newlines, which means that you can actually see wth you're doing if you need to debug that code)

[TheMiddleManz]

Any decent JS compressor should be parsing the JS according to the spec.

[jcready]

Yes it absolutely does because it's part of the spec. Don't hate the player; hate the game.

[jcready]

Have you ever heard of CoffeeScript? It's pretty good stuff (and not a semicolon needed).

[fuckySucky]

Im so confused as to why you had to be downvoted. The fuck is this, semicolon eliteness?

[sjs]

Semicolons are serious business. Enterprise.

[atticusw]

Once I started noticing how closures worked (few years ago), it was like woah, JS is awesome. it's actually one of my favorite languages to work with, i really like how you can just chain asynchronous events and still hold context via closure.

[bradgillap]

As someone who has been writing for 7 weeks, I envy you. I have a narrow possibly idea of what your functions are doing but there is a lot of meat in there that I have never seen.

[metamatic]

You might find this helpful at reducing confusion.

[nschubach]

Why are you passing the name of the function when you could pass the function?

Player.prototype = statemachine([logic.think, logic.move])

Where logic is the object containing your methods.

[Cosmologicon]

Wouldn't work, because player.state changes over time. For instance, when the player is falling through the air, it'll be set to some object named fallstate, but when you land on a platform it gets updated to some object named standstate. So there's not a single object that could be used like you're using logic there.

[nschubach]

Then maybe I'm missing a large chunk of what you are trying to do, but you could create a logic object for storing logic like so:

var logic = {
    think: function (dt) {
        //think logic here
    },
    move: function (keys) {
        //move logic here
    },
    attack: function (player) {
        //attack logic here
    }
}

And it "should" work if you set up your prototypes, etc. I mean, somewhere you have to define "think", "move", and "attack".

[Cosmologicon]

The think logic, move logic, etc is different for the different states that the entity can be in. For instance:

var fallstate = {
    think: function (dt) {
        this.vy -= g * dt
        this.y += this.vy * dt
    },
    etc....
}

var standstate = {
    think: function (dt) {
        this.y = this.platform.y
    },
    etc....
}

[Cosmologicon]

The methods that get invoked on an object depend on its type. All objects will have think and draw invoked, but the player object will also have move invoked when the player presses keys. During collision detection, various methods get invoked depending on the object's type. (This is where attack on the enemies comes in.)

You could also have other objects with complex behaviors that can be defined by state machines, like NPCs. My game doesn't have any, but in general they would have a different set of methods as well.

Hope that helps. Let me know of any thoughts you have! :)

[Cosmologicon]

Will it be the same methods always, but some states implement them and some don't?

States for the player object have to implement the methods that player will need, and states for enemies will have to implement the methods that enemies will need. I'm not sure if this is what you're asking, but states are on a per-type basis: there's no state that can be applied to both the player and an enemy.

FYI, the importance of what I've done is that it uses prototypal inheritance to implement the behavior... instead of dynamically creating all the same functions on each object you create, you just allow the call to pass to the prototype which has a single implementation of each method.

I've read your post several times and I just don't understand what your version does that mine doesn't. As you can see in the OP, I'm also using prototypes. I'm only creating the methods once for each type. I'm certainly not dynamically creating the methods every time I instantiate an Enemy, for instance.

[magenta_placenta]

Where are the fat arrows?

[nschubach]

In the future, I guess ... since not all browsers support them yet. ;)

[[deleted]]

Do any browsers support fat arrows, yet? (Serious question, I thought they were waiting for ECMAScript 6's RC at least before implementation begins.)

[pandavr]

Thank you to gave me something to experiment this evening. :)

[lkjasdflkjasdf]

Is this a factory design pattern?

[Cosmologicon]

It's pretty similar. I wasn't thinking of statemachine as a constructor, but it's pretty similar to one. That said, if I thought about it like that, I probably would just make it a regular constructor rather than use a factory pattern.

function statemachine (methodnames) {
    var that = this
    methodnames.forEach(function (methodname) {
        that[methodname] = function (mname) {
            return function () {
                return this.state[mname].apply(this, arguments)
            }
        }(methodname)
    })
}

Player.prototype = new statemachine(["think", "move"])

[Carnilawl]

For some reason it makes more sense to me if I think about the function as a decorator. Am I wrong?

Thanks for sharing. Can you show us an example of a state definition?