Open license2e opened 8 years ago
Hi, your observation is correct regarding the parameters of call
vs. apply
. I noticed this myself when I first started using this package... But, this proposal, and the accompanying PR are a breaking change to this package, correct?
So all dependent packages that use the .call
method to invoke Meteor methods (a sizable fraction, I would estimate) will break with the next update and need to change?
As I said above, I agree that the incongruity here is unfortunate, but this package has a fairly long list of dependents. As such, I would argue that this ship has sailed, so to speak, and we should just live with it, at least until some more pressing breaking changes are warranted, necessitating a full 1.0 semver major release. IMO, this is a nicety, but not worth all of the fuss it seems likely to cause.
@vsivsi I see your point, but that would just be an easy fix:
.call*
would just call .send*
).call*
functionsIn my experience, when developers are upgrading code, as long as you dont just change the API completely without a fair warning, they are ok with it.
I can add all the backward compatibility to my PR..
In JS
function.call
expects parameters to be passed in directly instead of an array of parameters...Also,
Meteor.call
accepts direct parameters whileMeteor.apply
accepts an arrayThe proposal:
Change from:
DDPClient.prototype.call
andDDPClient.prototype.callWithRandomSeed
to:DDPClient.prototype.send
andDDPClient.prototype.sendWithRandomSeed