These are chat archives for ramda/ramda
99+new messages in this channel. Could only assume an operator order discussion had taken place .:D
If you think of them as unary predicates, one answer is obvious. But if you think of them as binary, the opposite one seems more likely.
What are you thoughts on:
if you have both arguments to supply to gt, you are not going to be point free. If you are not point free you therefore have the ability to use the native operator directly.
therefore, gt is only really useful in the unary form, therefore it's predicate nature should be prioritized
Could only assume an operator order discussion had taken place .
but I don't think there is a nice way to migrate to this in a backwards-compatible manner
If your main concern is backwards compatibility, I guess that means you agree that
gt's api should change, even if it (hypothetically) can't?
That is at least progress! :)
As @gabejohnson pointed out, the current
lt has exactly the same functionality as my proposed changes.
A user who is upgrading to a minor version would only need to substitute R.gt for R.lt and they would be back in business.
So unlike most API changes, the migration is trivial. And Ramda making breaking changes in the past is not without precedent. I can think of many examples.
Usually the breaking changes are due to improved user experience, e.g.
I personally don't have
gt in any of my codebases because the current API just introduces confusion for coworkers.
I wonder how much impact such a migration would really have?
BTW the docs desperately need full text search, and extra disambiguation content.
Good point @barneycarroll
return the opposite of what they originally intended.
Except that many people are encountering that behaviour as it stands, because the current behaviour is surprising. So you have surprise either way.
R.gt(R.__, 42)in production.
ltas a migration, even when they've flipped or used a placeholder.
R.mergenow just delegates to
Object.assignwhere it exists so the same semantics will apply, namely the values will be copied for all enumerable properties rather than the property descriptors.
const Q = () => Q;
updatedwould be an array of pairs consisting of the id (from the array_server) and the updated obj. and
newsjust an array of new objects. My current solution doesn't fully achieves this :(