Just going to leave this here

Code: (javascript) [Select]

from.Array(threads)
	.where(function(t) { return t.id == threadID })
	.besides(function(t) { t.isValid = false; })
	.remove();

// you could also do `from.Object(obj)` to query keys, or just plain `from()` to determine
// the enumeration mode from the type of the argument.

That reads back very nicely I think: "From Array 'threads', where an item's id matches the thread id, besides setting 'isValid' to false, remove it."

I'm experimenting with simplifying things some more for my experimental "from" script.  One thing I notice that link does is to call the points recursively.  While this is in line with the chain metaphor, it ends up duplicating effort because every single point (except endpoints) needs to have a call to this.next.exec().  My idea was to instead have points return true to continue, and false to drop the current value, filtering it out.

Endpoints would work similarly - return true to continue with the next value, or false to short-circuit.  I think this is overall a better separation of concerns.

I actually had this exact implementation in Link, but for some reason I got rid of it... Not sure why though... I think the performance was better to not return a value?

Also what does coalesce do?  It says it merges modified results back into the array, but I'm not sure what that means in practical terms.  Link already has update()...

It is similar, yes. But with update you can specify a value. Coalesce uses the current computed value in the Link list and sticks it back into the array at the index value, but it's still experimental because some operations might change the index value.

Okay, so in other words:

Code: (javascript) [Select]

var nums = Link.range(5);
Link(nums)
    .map(function(n) { return n * n; })
    .coalesce();

// 'nums' is now -> [ 1, 4, 9, 16, 25 ]

That's pretty convenient, basically transforming the entire array in one step.  Or you could add where clauses to only remap certain items... hm... I'll have to try to find a use for this now

Link.js idea: make an option for it to go backwards... Could be interesting...

Just saw this bit.  That would indeed be interesting to see.  Among other things, it would allow last to be able to short-circuit the same way first can.  When going forwards you always have to run the entire sequence to find the last match(es), if you start from the end you can just stop after you have X items and then reverse them.

Hm, it occurs to me that one can take advantage of lazy evaluation to implement random chances for battle engines:

Code: (javascript) [Select]

const link   = require('link');
const random = require('random');

// insta-kill attack
link(battlers)
    .where(function(b) { return b.isEnemyOf(attacker) })
    .where(function(b) { return b.level % 5 == 0; })    // level is multiple of 5
    .where(function() { return random.chance(0.35); })  // 35% hit rate
    .each(function(b) { b.die(); });

Feature request: Partial application, or in other words reusing a partial query with different operators.  Link can already kind of do this, but only with endpoints.  In C#, you can do stuff like this:

Code: (csharp) [Select]

// get all items for the first party member:
itemQuery = items.Where(v => v.owner == partyChars[0]);

// get items to show on the current page
itemsOnPage = itemQuery
    .Skip(pageSize * pageIndex)
    .Take(10)  // 10 items per page
    .ToArray();

The above doesn't work in Link because adding points just keeps adding to the same query.  LINQ (and soon, Sphere v2 from()) returns a new enumerable for each point, which allows this to work.

Let me just say that Link and from() are so much more fun to use now that minisphere supports arrow functions.

I found the first actual use case for from() over objects:
https://github.com/fatcerberus/spectacles-i/blob/master/src/party.js#L47-L50

Party management.