From: Trans Date: 2008-03-02T23:08:40+09:00 Subject: Re: Monkeypatching is Destroying Ruby On Feb 29, 10:23 pm, James Britt wrote: > If there is a combination of tools you would like to use, but they > collide in some way, it is quite possible that deliberate file-loading > order, combined with re-opening/selective re-definition of the offending > classes, would allow you to carry on. Before I once again ditch the effort, I just want to point out that I have tried to make Facets more flexible in this regard, but there always issues. For instance, David Black recommend wrapping extensions in modules so they could be used per object via #extend. This would also make rdoc'ing a little easier, adn allow other extension to get "in front" of Facets depending on load order. All good ideas, but it has the following issues: 1) Extending a whole class would require an extra "class X; include E; end" call, or a secondary file for every extension file that would do it for you. For backward compatibility I would have to do the latter, which means a large set of new files to maintain. 2) You can't add aliases for core/standard methods via a module. It requires some #included tricks to do so and that doesn't RDoc. 3) Modules can't include extension modules b/c of the Double Module Inclusion Problem. That means extensions to Enumerable, for instance, won't be any better off then they are now. This adds an asymmetry to the system, not to mention the RDocs. 4) To offer the same granularity to extending objects that Facets now offers to extending class/modules would require the creation of many modules. Is it worth the extra memory overhead? It's too bad that Ruby isn't more flexible about what we can do with classes. If it were possible to include a class, I wouldn't have to mess with any of this. Anyone could load an extension into a protective module space and reuse it to their hearts content. The other option is to use a special #extension method. Eg. extension :Array, :foomethod do ... I've seen other play with this idea, and it has some merits. But it has some issues as well. 1) You can't get suitable RDocs from it at all. I know we shouldn't program for the sake of docs, but in real life good docs are very important. 2) It can produce a lot of blocks, so like the module idea the corresponding memory footprint question arises. Perhaps by combining the two approaches in some way it would be possible to largely mitigate their short comings. But in either case the memory footprint question remains. Is it worth a few hundred modules and/or blocks for this level of control? Of course the bottom line question though is: Would people really use it? Or, in reality, is it just easier to fix library conflicts manually as they occasionally come up? T.