5 ms·
Ruby is a language, not an implementation. DCI in ruby seems just fine, but all implementations are not friendly to the dynamic mixin hell hole.
by eduardordm 14y ago
Ruby is a language, not an implementation. DCI in ruby seems just fine, but all implementations are not friendly to the dynamic mixin hell hole.
- latortuga 14y agoCompletely agreed, the title is a red herring and serves to dissuade people from giving DCI a try. "It's too slow" is not an argument against DCI, it's an argument for fixing a slow implementation of #extend or using a different method.
- bascule 14y agoWhy not do DCI with delegation instead of mixins?
- davnola 14y agoBecause in general, delegation tends to lead to object schizophrenia. Specifically, SimpleDelegator will leak the original delegatee object when a delegated method returns `self`. s = "foo" d = SimpleDelegator.new s s2 = d << "bar" s2.object_id == s # true I think SimpleDelegator is really neat but totally dangerous. Doesn't this ring alarm bells with you? # delegate.rb L117 # # Returns true if two objects are considered of equal value. # def ==(obj) return true if obj.equal?(self) self.__getobj__ == obj end
- bascule 14y agoWhile this is true, it currently has pathological performance on all major Ruby implementations.
- eduardordm 14y agoI just wonder if fixing this (by adding extend calls to cache) will end up making unicorn eat way too much memory.
- mst 14y agoThe perl equivalent (run-time role application) normally caches the extended class by default and re-uses it. Provided you don't have a pathological number of combinations, that seems to work out pretty well.
- mrgoldenbrown 14y agoWhen you say "it" you mean using extend, not DCI in general, right?
- bascule 14y agoYes, hence why I was constantly calling it "DCI" in quotes