Ok, I released v0.2.12 that adds .has(prop_name, array_or_value), which does basically an eager filter on the inner contents of an array of an object.

it also adds array options to filterBy(prop, values) and contains(values). There is no containsAny, instead Link(stuff).contains([...]) will assume to do an or-like contains any on the data. I don't see much use of an and-only contains, but if I were to do that I could just use a predicate instead.

I don't know, containsAny seems clearer.  I know I'm just nitpicking at this point, but if I see a bare .contains() being passed an array, I would intuitively expect it to check whether it contains all the values--all of them--not only some of them.  I suppose using .some() makes things clearer, but...

Anyway, with 0.2.12, this would do what I want, correct?:

Code: (javascript) [Select]

BattleUnit.prototype.liftStatusTags = function(tags)
{
	var me = this;
	var statusIDs = Link(this.statuses)
		.where(function(status) { return Link(status.statusDef.tags).some(tags); })
		.pluck('statusID')
		.each(function(statusID)
	{
		me.liftStatus(statusID);
	}
};

Edit: Just tested it, it doesn't appear to be working--the query is returning no results even when there are matching statuses in effect.  Am I doing something wrong (the query looks fine at any rate), or is Link bugged?

That should work... My tests for contains seem to pass. I should do proper unit tests, but I figure if my manual tests pass it should work in many circumstances.

Ok... I tested this minial version in both Chrome and Sphere and you'll be shocked. It doesn't work in Sphere.

Code: (javascript) [Select]

var statuses = [
	{ id: 0, statDef: { tags: ["heal", "death", "burn"] } },
	{ id: 1, statDef: { tags: ["heal", "spark"] } },
	{ id: 2, statDef: { tags: ["drain", "turn"] } }
];

Link(statuses).where(function(status) { return Link(status.statDef.tags).some(["burn", "drain"]); }).each(function(status) {
	console.log(status.id); // I get 0 and 2 in chrome; nothing in Sphere
});

However if the array has 1 item in it, it works in both chrome and Sphere. I don't know exactly how to solve this since there are no runtime errors. :/

Edit:
Nevermind, it works in both. I forgot to update the version. I honestly don't know why it doesn't work for you. Try running the code above, it should work no different.

Yeah, it was stupidity on my part.  I found out I had a bad item definition which was causing liftStatusTags to be passed undefined instead of the array it's supposed to get.  I feel embarrassed now.

Also I love how your little example alludes to a status tagged both 'heal' and 'death'.  Consider its other tag is 'burn', I can't even imagine what kind of unholy status ailment that's supposed to represent.

Hey, what value exactly do methods like .first() return in case no matching item is found?  It must be something other than null or undefined, because my engine is choking when an AI battler attempts to target a unit by name that doesn't exist, despite a null check on the search result.

Also I love how your little example alludes to a status tagged both 'heal' and 'death'.  Consider its other tag is 'burn', I can't even imagine what kind of unholy status ailment that's supposed to represent.

In Morrowind and Oblivion - when you could make spells - I did all kinds of strange masochistic stuff like spells that burn and heal at the same time.

Hey, what value exactly do methods like .first() return in case no matching item is found?  It must be something other than null or undefined, because my engine is choking when an AI battler attempts to target a unit by name that doesn't exist, despite a null check on the search result.

First() returns undefined if nothing can be returned; a single item if only a single item was found, and an array if more than one item was found. I've seen it implemented in this way for libraries like Lazy.js, but in practice I honestly can't say how well that works. I hope it isn't returnning an empty array!

Looks like first was returning undefined after all--it's just that I was testing against null via strict equality (===), which obviously doesn't match undefined, and so it passed through the undefined as the target of the attack.  This caused the engine to choke when executing the attack since it was trying to run methods on undefined (which, um... doesn't have any, as it turns out).  Oops!

Thanks for the heads-up on the possibility of returning an array, though.  That would have been a nasty bug to run into down the line--the way I implemented attack targeting in Specs, I'd have single-target attacks hitting multiple units and not know what caused it!

I notice you have lines like this in your code:

Code: (javascript) [Select]

		liftStatusTags: function(actor, targets, effect) {
			for (var i = 0; i < targets.length; ++i) {
				targets[i].liftStatusTags(effect.tags);
			}
		},

I think I shall add the ability to pass parameters to .invoke:

Code: (javascript) [Select]

		liftStatusTags: function(actor, targets, effect) {
			Link(targets).invoke("liftStatusTags", effect.tags);
		},

So, what do you think? Again, bear in mind won't be as fast due to some overhead.

I was actually about to suggest that the next time I was around a computer - there was one situation earlier where I wished for the ability to pass arguments to invoke, I even checked the Link code to see if it was already possible!  Sadly it was not...

Ok, it's updated

Just out of curiosity, how much performance overhead does a bare Link().each have over a for loop?  I often refrain from using Link if there is no filtering needed, but Link.each is definitely more elegant than the ugly C-derived for syntax, so I'm wondering if the tradeoff is worth it.

I had a long post here, but I kept growing it... And it was a lot of talk. Here's what I'm saying more elegantly:

Link.each is slower than a raw for loop by a small degree, more-so under SSFML.

Creation of Link contexts has no real effect on speed. ~.0001%

Embedding functions has no real effect on speed. ~.0001% (I'm guessing SpiderMonkey caches those functions for you).

Use Link on complex queries, and Link.each to run loops in non-critical sections of your code. Under the chrome browser, well heck, none of this matters because everything is so much faster.

So then TurboSphere would be the same deal as Chrome speed-wise?  Since both use V8...

So then TurboSphere would be the same deal as Chrome speed-wise?  Since both use V8...

Yeah, it should perform very well under TS, technically.

I imagine if you used a slower engine-supplied construct it could slow it down.

Otherwise, it should be very similar.