Is .map specialcased or do user functions accepting callbacks work the same way? Because you could do the Scott-Mogensen thing of #ifTrue:ifFalse: if so, dualizing the control-flow decision making, offering a menu of choices/continuations.

▲

kentonv 4 days ago | parent [-]

.map() is totally special-cased.

For any other function accepting a callback, the function on the server will receive an RPC stub, which, when called, makes an RPC back to the caller, calling the original version of the function.

This is usually what you want, and the semantics are entirely normal.

But for .map(), this would defeat the purpose, as it'd require an additional network round-trip to call the callback.

▲

qcnguy 4 days ago | parent | next [-]

What about filter? Seems useful also.

▲

kentonv 4 days ago | parent [-]

I don't think you could make filter() work with the same approach, because it seems like you'd actually have to do computation on the result.

map() works for cases where you don't need to compute anything in the callback, you just want to pipeline the elements into another RPC, which is actually a common case with map().

If you want to filter server-side, you could still accomplish it by having the server explicitly expose a method that takes an array as input, and performs the desired filter. The server would have to know in advance exactly what filter predicates are needed.

▲

svieira 4 days ago | parent | next [-]

But you might want to compose various methods on the server in order to filter, just like you might want to compose various methods on the server in order to transform. Why is `collection.map(server.lookupByInternalizedId)` a special case that doesn't require `server.lookupCollectionByInternalizedId(collection)`, but `collection.filter(server.isOperationSensibleForATuesday)` is a bridge too far and for that you need `server.areOperationsSensibleForATuesday(collection)`?

	▲	kentonv 4 days ago \| parent [-]
		I agree that, in the abstract, it's inconsistent. But in the concrete: * Looking up some additional data for each array element is a particularly common thing to want to do. * We can support it nicely without having to create a library of operations baked into the protocol. I really don't want to extend the protocol with a library of operations that you're allowed to perform. It seems like that library would just keep growing and add a lot of bloat and possibly security concerns. (But note that apps can actually do so themselves. See: https://news.ycombinator.com/item?id=45339577 )

▲

5Qn8mNbc2FNCiVV 2 days ago | parent | prev [-]

Couldn't this be done in some way when validation exists, that the same validation is used to create a "better" placeholder value that may be able to be used with specific conditional functions? (eq(), includes(), etc.)

▲

svieira 4 days ago | parent | prev [-]

Doesn't this apply for _all_ the combinators on `Array.prototype` though? Why special-case `.map` only?

	▲	kentonv 4 days ago \| parent [-]
		See cousin comment: https://news.ycombinator.com/item?id=45338969