Add fuse.Class.mixins.comparable mixin for equals() and like() methods
Reported by John-David Dalton | June 1st, 2010 @ 10:10 AM
Add fuse.Class.mixins.comparable mixin for equals() and like() methods.
Do you guys like isEqual/isLike or equals/like ?
fuse.Class.mixins.comparable = { };
(function(mixin) {
mixin.like = function like(value) {
return String(this) === String(value);
};
mixin.equals = function equals(value) {
return toString.call(this) === toString.call(value) && this.like(value);
};
fuse.Object.equals = function equals(object1, object2) {
return mixin.equals.call(object1, object2);
};
fuse.Object.like = function like(object1, object2) {
return mixin.like.call(object1, object2);
};
var like = nil, equals = nil;
})(fuse.Class.mixins.comparable);
// usage
fuse.String.addMixins(fuse.Class.mixins.comparable);
fuse.String("1").like(1); // true
fuse.String("1").equals(1); // false
fuse.String("Oh hai").equals(fuse.String("Oh hai")); // true
Comments and changes to this ticket
-
Kit Goncharov June 1st, 2010 @ 10:24 AM
- State changed from new to open
- Assigned user changed from John-David Dalton to Kit Goncharov
I was just thinking about implementing something like this. :) I can go ahead and get started, if that's okay with everyone.
With re:to naming: although 'like' and 'equals' are shorter, I like 'isLike'/'isEqual' for API consistency, as both methods return booleans.
-
T.J. Crowder June 1st, 2010 @ 10:32 AM
FWIW, not being au fait with much of Fuse's API, I prefer
equals
andlike
. I've never been a fan of theisXyz
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 themixin.like
property). You need to do this:mixin.like = like; function like(value) { return String(this) == String(value); }
-
John-David Dalton June 1st, 2010 @ 10:35 AM
@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. -
T.J. Crowder June 1st, 2010 @ 10:41 AM
@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.)
-
John-David Dalton June 1st, 2010 @ 10:42 AM
While our API does use the
is
prefix for methods that return aboolean
it also allows verbs/adverbs without a prefix likeupdate(), 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. -
Kit Goncharov June 1st, 2010 @ 10:43 AM
@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. -
John-David Dalton June 1st, 2010 @ 10:43 AM
@T.J. Crowder no it just clears the declarations created by JScript it doesn't clear the expressions.
-
T.J. Crowder June 1st, 2010 @ 10:56 AM
@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.
-
John-David Dalton June 1st, 2010 @ 10:57 AM
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.
-
Joe Gornick June 1st, 2010 @ 11:38 AM
+1 for
equals
andlike
.Yes the
is*
syntax is more consistent with other methods likeisString
, however, it works there because it's a known type we are comparing against.equals
andlike
will definitely be used a lot and fall into thedown
,up
,next
, etc... style of method names. Plus, all other languages/API use theequals
form. -
T.J. Crowder June 1st, 2010 @ 11:50 AM
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
withNSObject
, but Apple's efforts notwithstanding, that's not nearly as popular as Java and C#. (Also, nit-picking, it should beisEqualTo
if it's going to be in that form.) -
Joe Gornick June 1st, 2010 @ 11:55 AM
@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.
-
Nick Stakenburg June 1st, 2010 @ 12:38 PM
isEqualTo
might work better withisLike
, but I preferlike/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);
-
John-David Dalton June 1st, 2010 @ 02:31 PM
@Nick Thanks for the suggestion. Modified the example accordingly.
-
John-David Dalton June 1st, 2010 @ 02:53 PM
- Title changed from Add fuse.Comparable mixin for equals() and like() methods to Add fuse.Class.mixins.comparable mixin for equals() and like() methods
-
Kit Goncharov June 9th, 2010 @ 03:48 PM
- Assigned user cleared.
-
Joe Gornick September 18th, 2010 @ 01:36 PM
- State changed from open to new
- Assigned user set to John-David Dalton
- Milestone order changed from 0 to 0
-
Joe Gornick September 19th, 2010 @ 05:54 PM
- Assigned user changed from John-David Dalton to Joe Gornick
-
Joe Gornick September 29th, 2010 @ 09:30 AM
- Milestone cleared.
- Milestone order changed from 1 to 0
Please Sign in or create a free account to add a new ticket.
With your very own profile, you can contribute to projects, track your activity, watch tickets, receive and update tickets through your email and much more.
Create your profile
Help contribute to this project by taking a few moments to create your personal profile. Create your profile ยป
JavaScript frameworks share similar features and functionality such as DOM manipulation, event registration, and CSS selector engines. FuseJS attempts to incorporate the strengths of these frameworks into one stable, efficient, and optimized core JavaScript framework.