Keyword arguments support? - #15
Conversation
|
Helllooooo! :) So thanks for this, frankly I never thought about kwargs as I have yet to use them :) The way you did it is the only way I can imagine doing it right now. About the optional object, that's pretty important so it has to stay. If the problem is that the object is last we could experiment with reversing the order. Of course that would be breaking, but hey it's Thanks Piotr! :) |
|
Hello my dear @chastell ! In the last versions the data AfterDo has access to has grown extensively. After I cut out 0.5.0 I'd be ready to investigate an overhaul of the API where one just picks and matches with keyword arguments which values you want to get. I'm also completely ok with dropping support for 1.9 or even early 2.x versions. AfterDo has been rather stable and who doesn't have these versions can stay and stick to versions 0.5 and below (most still depend on 0.3 it seems). If you wanna pitch in there, I'd be happy too - or maybe I get another reason to visit you and we pair on the new versions? Anyhow, hugs! |
Is there a chance for after_do to have keyword arguments support?
I was hoping for something like
but I think the invisible
objectargument at the end makes it blow up (you can’t have non-kwargs after kwargs).The best I could do is to fake them via a
Hashaccess (as in this PR), which might be the best that can be done while preserving the optionalobject.Note that this PR probably won’t even build outside of MRI 2.1 and 2.2 – once the decision whether/how to support kwargs is made I can try wiring the specs so that kwarg-related ones are only ran on kwarg-capable Rubies.