Keyword arguments
Closed this issue · 9 comments
I noticed that the tested Rubies (https://github.com/Absolventa/emarsys-rb/blob/master/.travis.yml) all support keyword arguments, but they don't seem to be used.
While implementing #23, I thought it would be very handy to use as the list of required parameters for Emarsys::Email.export_responses is really long and the order is difficult to remember.
What do you think?
I don't have any objections to this, but since i'm relatively new to the project, i'll let @carpodaster weigh in?
If we do go down this route, the whole codebase could probably do with a review with regards support for kwargs.
Hey @michaelsauter and @mungler – my first reaction was "let's not drop support for old Rubies" but my immediate follow-up reaction was: "hell yeah, let's drop support for old Rubies!" ;) 👍 for kwargs
@carpodaster I tend to agree... kwargs are the future. With respect to semver, switching to kwargs will be a non-backward compatible change, so where do we go with versioning? 1.0.0?
@mungler ah, good point. I would still only do a 0.x.0 increase since the lib is not yet 1.0, meaning that it's still considered unstable and APIs can change at any time. That's what I meant in my other comment with "it's all < 1.0 so nothing really counts".
I don't know if there are any key features missing wrapping the Emarsys API. If there aren't, one might as well consider a move to the Grand v1.0
@carpodaster yeah, its the one weakness in the semver argument, really. I agree, I think we're better to stick to 0.x.y to indicate instability, unless we're confident the API wont change. A review of the API coverage is likely in order before moving to 1.0.0 :)
@michaelsauter thoughts? :)
Great to hear you're open towards keyword arguments! I've found them to be very helpful. Also, they're not that new anymore (2.0.), even though I'd probably raise the min. Ruby version to 2.1 to be able to use required keyword arguments.
In regards to semver .... I don't think you're strictly following semver :) If you would, this should be 1.0 already I think - see the semver FAQ:
If your software is being used in production, it should probably already be 1.0.0. If you have a stable API on which users have come to depend, you should be 1.0.0. If you’re worrying a lot about backwards compatibility, you should probably already be 1.0.0.
However, I think it is totally OK to not strictly follow semver. I do think that people assign "1.0" some special meaning - it sort of communicates "this thing won't change much". As such, just incrementing the MINOR number seems fine by me if you're pre 1.0 and introduce a backwards-incompatible change. That seems to be a pretty common approach.
@michaelsauter @carpodaster I do agree, actually. I think for now i'll stick with updating the 'z' of x.y.z until we agree we're at 1.0.0
With regards kwargs, feel free to submit a PR for review 👍