A look at Ruby 2.0

What we did was create one gem for each specific special behavior of the app, were we declared some methods as extension points which the base app should call, in that scenario prepending methods would be useful, we could declare dummy empty methods to be overwritten later on by a module.

What we needed to do because of the lack of prepending modules was that each module implementation should implement all of the extensions points even when it was not needed, so, some times we had some dummy empty methods on one of the specific modules, i would have preferred to have those dummy methods on the main project itself.

Re: A look at Ruby 2.0

#7

Post by cheald » Mon, Jan 14, 2013, 9:44 PM UTC

fourspace wrote: post #5

Can someone provide a practical use case for prepending modules? I can't for the life of me think of one.

Well, the obvious case is a "safe monkeypatch", where you want to add some functionality to a class, but only if it hasn't already been added (maybe by some third module).

I think this could more easily allow for the use of multiple support libraries (like ActiveSupport) without having to worry about them clobbering each other.

Re: A look at Ruby 2.0

#8

Post by netcraft » Mon, Jan 14, 2013, 10:09 PM UTC

cheald wrote: post #7

fourspace wrote: post #5

Can someone provide a practical use case for prepending modules? I can't for the life of me think of one.

Well, the obvious case is a "safe monkeypatch", where you want to add some functionality to a class, but only if it hasn't already been added (maybe by some third module). I think this could more easily allow for the use of multiple support libraries (like ActiveSupport) without having to worry about them clobbering each other.

forgive my ignorance, and I'm not familiar with ruby or ActiveSupport, but how does that solve the problem? Wouldn't different module's be expecting the method to be implemented in a certain way, and this would would have the method implemented, but not the version they expect?

Re: A look at Ruby 2.0

#9

Post by jneen » Mon, Jan 14, 2013, 10:18 PM UTC

Uh... You shouldn't have to install libyaml from a tarball just because you don't have homebrew. The equivalent of

    sudo apt-get install libyaml libyaml-dev

or for you hat-wearing folks

    sudo yum install libyaml libyaml-devel

should work just fine.

Re: A look at Ruby 2.0

#10

Post by tragomaskhalos » Mon, Jan 14, 2013, 10:31 PM UTC

phasevar wrote: post #2

Finally... Real keyword arguments.

Meh, can't get excited about them. The hash mechanism, plus the ability to leave out the hash braces, works perfectly well enough for me. All popular languages are doomed to accrete nonessential features until they sink under their own weight ...