From: Yehuda Katz Date: 2008-10-07T05:49:47+09:00 Subject: [ruby-core:19151] Re: [Feature #615] "with" operator ------=_Part_45352_11528012.1223326295003 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline Not really. This is effectively a rehash of the #uninclude/#unextend proposal from a few months ago that was summarily ignored despite being brought up in an implementer's meeting. Maybe with _why pushing it now we'll see it get its due consideration. Selector namespaces are much more complex because they need to be applied at parse-time but evaluated at runtime. Something like: class String def merb:camelize return self if self !~ /_/ && self =~ /[A-Z]+.*/ split('_').map{|e| e.capitalize}.join end end using(:merb) do class Merb::Awesome def some_awesome_method "hello".camelize end end end would be expected to call "hello".merb:camelize, even if the call to some_awesome_method was made outside of a using(:merb) block. On the other hand, uninclude could be extremely useful (despite the fact that it seems, at the moment, to require invalidating the global method cache). -- Yehuda On Mon, Oct 6, 2008 at 1:20 PM, Austin Ziegler wrote: > On Mon, Oct 6, 2008 at 3:34 PM, Trans wrote: > > On Oct 6, 2:11 pm, _why wrote: > >> While investigating Guy Decoux's old messages, I've recently > >> discovered a way to do exactly this. It involves inserting a mixin > >> into the inheritance chain and then enabling and disabling it as > >> needed. > >> > >> > > > > Jimmy Crickets! That code is so straight forward. Er... Why isn't this > > core Ruby? > > What I'm wondering is if this might be a way to do selector namespaces > that everyone has been asking for... > > -austin > -- > Austin Ziegler * halostatue@gmail.com * http://www.halostatue.ca/ > * austin@halostatue.ca * http://www.halostatue.ca/feed/ > * austin@zieglers.ca > > -- Yehuda Katz Developer | Engine Yard (ph) 718.877.1325 ------=_Part_45352_11528012.1223326295003 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline
Not really. This is effectively a rehash of the #uninclude/#unextend proposal from a few months ago that was summarily ignored despite being brought up in an implementer's meeting. Maybe with _why pushing it now we'll see it get its due consideration.

Selector namespaces are much more complex because they need to be applied at parse-time but evaluated at runtime.

Something like:

class String
  def merb:camelize
    return self if self !~ /_/ && self =~ /[A-Z]+.*/
    split('_').map{|e| e.capitalize}.join    
  end
end

using(:merb) do
  class Merb::Awesome
    def some_awesome_method
      "hello".camelize
    end
  end
end

would be expected to call "hello".merb:camelize, even if the call to some_awesome_method was made outside of a using(:merb) block. On the other hand, uninclude could be extremely useful (despite the fact that it seems, at the moment, to require invalidating the global method cache).

-- Yehuda
On Mon, Oct 6, 2008 at 1:20 PM, Austin Ziegler <halostatue@gmail.com> wrote:
On Mon, Oct 6, 2008 at 3:34 PM, Trans <transfire@gmail.com> wrote:
> On Oct 6, 2:11 pm, _why <w...@ruby-lang.org> wrote:
>> While investigating Guy Decoux's old messages, I've recently
>> discovered a way to do exactly this.  It involves inserting a mixin
>> into the inheritance chain and then enabling and disabling it as
>> needed.
>>
>> <http://hackety.org/2008/10/06/mixingOurWayOutOfInstanceEval.html>
>
> Jimmy Crickets! That code is so straight forward. Er... Why isn't this
> core Ruby?

What I'm wondering is if this might be a way to do selector namespaces
that everyone has been asking for...

-austin
--
Austin Ziegler * halostatue@gmail.com * http://www.halostatue.ca/
              * austin@halostatue.ca * http://www.halostatue.ca/feed/
              * austin@zieglers.ca




--
Yehuda Katz
Developer | Engine Yard
(ph) 718.877.1325
------=_Part_45352_11528012.1223326295003--