Ruby-esque aliases for public Client interface

[florish]

While this gem was quite easy to use (thanks!), I noticed I had some difficulties implementing it, due to unexpected naming conventions used. Coding conventions are arbitrary of course, but here are a couple of examples and more common Ruby way to write them:

Mollie::API::Client

• getApiKey would be api_key (no "get" prefix, and snake_case)
• setApiKey(value) would be api_key=(value) (= can be part of a method name in Ruby)

A couple more examples

• _getRestClient can just be called rest_client or _rest_client
• performHttpCall would be perform_http_call

Some of the attribute setters/getter could also be rewritten to simply use attr_accessor and attr_writer.

All in all nothing major, but for me as a Ruby programmer, having api_key and api_key= would be a nice addition.

Before going into too much detail, first a question: would you consider adding (or letting me add) Ruby-like aliases to some of the current Mollie::API::Client public interface methods? Or are you aiming to keep method names aligned with the other supported languages?

I'd of course add this in a backward compatible manner, first by simply creating aliases to the current method implementations.

[jrnk]

+1 on this (if it helps)

Reading the first example and seeing getPaymentUrl as a method led me to this issue

[RickWong]

Hi @florish & @jrnk,

The idea was to keep the names aligned with the other supported language. However,

...in a backward compatible manner, first by simply creating aliases to the current method implementations.

That sounds reasonable too. And we're actually rethinking the naming constraint. It's a tough one. Do you think moving to Ruby naming conventions would make the API client easier to learn?

[jrnk]

If you stick to the conventions for a supported language it should make it easier/more straightforward to implement. I'm not sure how keeping method names aligned across languages helps the developers implementing it for (most of the time) one language.

I can see how it helps the developers writing the libraries though ;)

[florish]

@RickWong From your point of view as developer, I can see the benefits of keeping the same method names for all supported languages. But as @jrnk points out, the price you pay is some confusion for developers implementing the API client in languages where the predominant code style differs from the one you chose based on your own preferences.

In addition to implementing the API, following Ruby conventions would also make it easier for me (and possibly other Ruby developers) to open a PR and actively contribute to the code.

Back to the original issue: I'll just fork the repo, add a couple of method aliases and open a PR referencing this issue. Feel free to comment and accept or reject!

[willemstuursma]

Thanks @florish for the PR.