On Tue, Oct 09, 2007 at 01:10:07PM +0900, Jay Levitt wrote: [...] > What if class definitions were viewed through a magic prism, where only > those classes looking from the right perspective saw the new extensions? > Mind you, I have no idea how to partition the codespace in any sane manner > - even from a design spec point-of-view. Should ActiveRecord see Og's > extensions? Probably not; but ActionView and ActionPack might want to > share. And what happens if Og passes a Hash to ActiveRecord that happens > to include an Og-provided Time#today in it? > > I dunno. On the surface it seems that there must be some nicer way to add > better locality of reference to core extensions, but I can't imagine how it > would be implemented, how it should work, or if it would even be a good > idea. Just some good old Sunday night musings. > > Do other languages do anything like that? I know of no language that does anything like it. That said, there are good reasons to want something like it. Actually, I have often wanted a construct like this: class SomeClass module ExtraStuff def my_extra_method #... end end def some_method(arg) arg.let_extended(ExtraStuff) do |ext_arg| ext_arg.my_extra_method #... end end end If it isn't obvious, I want the equivalent of arg.extend(ExtraStuff) but only within the scope of the block. Whatever my ExtraStuff module does, I only want it mixed into an object for a brief scope. The simple solution is: #... def some_method(arg) ext_arg = arg.dup ext_arg.extend(ExtraStuff) ext_arg.my_extra_method #... end #... But that doesn't read quite as cleanly, and I would prefer a core language construct that could do it efficiently (i.e. without an object copy). Furthermore, the semantics are different in that if my_extra_method changes the state of the object, the state of the object passed into the method will actually changed when using the hypothetical core language construct, but not when using an extended copy of that object. There's been discussion before about unincluding modules, but it's always been considered too complicated to implement (I think). For this construct, however, it should be as simple as copying the object's eigenclass, including the module (or modules, since the let_extended method should really take an arbitrary number of modules) in the duplicate eigenclass, and setting the object's eigenclass pointer to the duplicate for the scope of the block. I speak of this with only a vague knowledge of how MRI deals with eigenclasses, much less how any other implementation (e.g. JRuby or Rubinius) does, so it may be messier than that. Does anyone find this interesting enough to push for an RCR? I've never done one, but if I get some positive feedback then I'll look into it. > Jay Levitt | --Greg