Use symbols instead of strings in opts access

[AlbinOS]

Hi everyone,

First I would like to thanks every contributor for their work on this gem.

I run into a little bit of trouble recently as I wanted to give a name while creating a container using :

container = Docker::Container.create(Cmd: ['ls'], Image: 'base', name: 'testing_stuff')

The parameter name was not taken into account. After some digging, I noticed that the parameter name was extracted from opts using string :

name = opts.delete('name')

As with newer ruby version, the hash syntax of {'x': 'y'} automatically transform the key to a symbol, is it not better to use symbol instead of string to extract value from opts ?

I know that I can use 'name' => 'testing_stuff' to force the usage of string as key but I don't really want to. First because I think using always symbols for key is a good pratice and secondly because I prefer the later syntax.

If you are OK with this, I'll submit a pull request using symbol instead of string while accessing opts and add something for retro-compatibility. Please let me know your thoughts about that.

Thanks and kind regards,
Albin.

[tlunter]

We've tried to resist moving everything to symbols because the API doesn't follow in line with how rubyists generally use symbols. It's not often that we use :Cmd as a symbol versus 'Cmd', and unfortunately docker's API isn't as uniform to let us use something like #capitalize and #underscore to and from the endpoints. For this reason, we've tended to leave everything as strings if we could.

I think in a few places, we've done something similar to opts.delete(:name) || opts.delete('name') since these params aren't passed to API in the same way. If you'd like to open a PR for that, I will accept it.

[AlbinOS]

Thanks for the explanation. As I'm new to this gem (and to ruby and docker in general), it's not always easy to understand choice that were made even if I know that there is always a good reason behind any choices.

I'll open a PR soon then, thanks again.