Add fuse.Class.mixins.comparable mixin for equals() and like() methods

FWIW, not being au fait with much of Fuse's API, I prefer equals and like. I've never been a fan of the isXyz naming style. If it's consistent with the rest of Fuse's naming, though, I'd go with consistency.

On implementation, you don't want to do this:

mixin.like = function like(value) {
    return String(this) == String(value);
};

That will create two completely separate function objects on IE, because it parses it as a function declaration (creating a named like function), then again later as a function expression (creating an anonymous function bound to the mixin.like property). You need to do this:

mixin.like = like;
function like(value) {
    return String(this) == String(value);
}

@T.J. Crowder the named expressions are cleaned up via the var like = null, equals = null;. I keep to that pattern so that I can easily parse out the named expressions and cleanup when devs choose to download a minified version.

@JDD: What purpose does all of that serve, then? The functions that end up getting bound to the property are anonymous, why bother with the names at all if you're okay with using anonymous functions on the mixin? (Which, as you know, I don't advocate. Names are good.)

While our API does use the is prefix for methods that return a boolean it also allows verbs/adverbs without a prefix like update(), up(), down(), next(), previous(). I think the boolean return might trump that though. I like the shorter API but for consistency I am leaning toward isLike and isEqual.

@JDD: Oops. :P I should probably revert my cleanups, then...I misunderstood you earlier when we were talking about possibly removing that pattern. For my cleanups, I've been following TJ's pattern:

//Previously...
plugin.some = function some(...)
...
var some = nil, ...

//My cleanup
function some(...)
...
plugin.some = some;

On-topic: James Coglan also has an interesting Comparable implementation in JS.Class: http://jsclass.jcoglan.com/comparable.html. It's extremely Ruby-like, but it shouldn't be too difficult to port to a more JavaScript-esque solution.

@T.J. Crowder no it just clears the declarations created by JScript it doesn't clear the expressions.

@JDD: I realize it's not touching the expression. But I've learned something here, I thought that IE skipped the name when processing the expression, but a quick test with VS2005 and MDE6 suggests that no, it actually does register the name on the expression as well as the declaration. That's interesting. Still don't think I'd do it (the custom minifier could handle either of them perfectly well, it's just how you write it), but it's interesting. Thanks for the IM about kangax's testing, too.

Sam Leb also has a version http://github.com/samleb/prototype-fruits/blob/master/src/comparable.js but I think both James' and Sam's are a bit too complex for now. We can add the other methods at a later time if they are needed.

+1 for equals and like.

Yes the is* syntax is more consistent with other methods like isString, however, it works there because it's a known type we are comparing against.

equals and like will definitely be used a lot and fall into the down, up, next, etc... style of method names. Plus, all other languages/API use the equals form.

Plus, all other languages/API use the equals form

For me, this is the persuasive argument. It may not be "all," but it's really close. :-) Java and C# both use it. Objective-C apparently uses isEqual with NSObject, but Apple's efforts notwithstanding, that's not nearly as popular as Java and C#. (Also, nit-picking, it should be isEqualTo if it's going to be in that form.)

@T.J. Crowder good point, I should of prefaced "all" with Java and C#/.NET which are usually the two API's I like to compare against because of their popularity.

isEqualTo might work better with isLike, but I prefer like/equals, nice and short. I don't think you really need the 'is' prefix like you need it in names like isEmpty, where without 'is' the name could mean more then one thing.

You can write the ? this.like(value) : false; as && this.like(value);

@Nick Thanks for the suggestion. Modified the example accordingly.