4 ms·
A look at Ruby 2.0
- phasevar 14y agoFinally... Real keyword arguments.
- deleted 14y ago[deleted]
- deleted 14y ago[deleted]
- amalag 14y agoI think it is too messy since people already have the hash workarounds. I don't think the two are mixing well together. I am preferring the hash based now since you can name the arguments.
- tragomaskhalos 14y agoMeh, 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 ...
- xal 14y agoI'm excited about ruby not having to allocate a hash for every bloody method call ever.
- fourspace 14y agoCan someone provide a practical use case for prepending modules? I can't for the life of me think of one.
- albertoavila 14y agoI was involved on a project which were actually two very similar applications. 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.
- cheald 14y agoWell, 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.
- netcraft 14y agoforgive 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?
- cheald 14y agoWell, any time you have conflicting libraries, you have a potential monkeypatching conflict, but depending on the case, you might want to implement a method, but only if it hasn't been implemented yet. For example, consider that we have our application, and it uses the "foo" library (which provides a "bar") method, but it might also use the "baz" library (which provides an optimized "bar") if baz is installed. Currently, you have to attempt to load baz before you load foo, and then not load foo's implementation of bar, if baz loaded successfully. In the future, you could just prepend foo, and so if baz was already loaded, it doesn't overwrite its optimized implementation. If baz wasn't loaded, then when it does load, it would overwrite the prepended implementation properly. This just frees you up from having to worry so much about load order. It's not a huge feature, but it's a nice little quality-of-life change.
- jayferd 14y agoUh... 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.