Feature #615: "with" operator

irb(main):001:0> x = "Sample"
=> "Sample"
irb(main):002:0> x.instance_eval do
irb(main):003:1*   puts self.class
irb(main):004:1>   puts reverse
irb(main):005:1> end
String 
elpmaS

Hi,

At Mon, 6 Oct 2008 06:24:46 +0900,
Lavir the Whiolet wrote in [ruby-core:19132]:
> "with" operator is required. It must work like an ordinary
> method which gets one arguemnt and a block. All expressions
> in the block are not required to point the argument
> explicitly; all method calls are related to the argument by
> default.

No.  I'd implemented and tested it once but found it's just
problematic rather than useful.  For instance, how do you
consider about instance variables?

-- 
Nobu Nakada

On Oct 5, 2008, at 15:35 , Dave Thomas wrote:

> Issue #615 has been updated by Dave Thomas.
>
>
> irb(main):001:0> x = "Sample"
> => "Sample"
> irb(main):002:0> x.instance_eval do
> irb(main):003:1*   puts self.class
> irb(main):004:1>   puts reverse
> irb(main):005:1> end
> String
> elpmaS

to take the idea one step further to the OP's request:

def with o, &block
   o.instance_eval(&block)
end

x = "Sample"
with x do
   puts self.class # needs self because class is part of the syntax
   puts reverse
end

To me, this seems simultaneously trivial and unhelpful. I wouldn't  
want to see it part of the language itself.

On Oct 6, 2:11 pm, _why <[e-mail]> 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?

T.

On Mon, Oct 6, 2008 at 3:34 PM, Trans <[e-mail]> wrote:
> On Oct 6, 2:11 pm, _why <[e-mail]> 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 * [e-mail] * http://www.halostatue.ca/
               * [e-mail] * http://www.halostatue.ca/feed/
               * [e-mail]

At 11:56 08/10/07, _why wrote:
>On Tue, Oct 07, 2008 at 05:47:23AM +0900, David A. Black wrote:
>> I've only looked at it briefly, and maybe I'm not getting it, but it
>> strikes me as kind of odd to have a situation where bare method calls
>> go to one object and instance variables belong to another. The merit
>> of instance_eval is that, though it changes context, it doesn't
>> introduce a new kind of context.
>
>Mixing in a module for the duration of a block isn't a new kind of
>context, though.  You keep the current scope and get some additional
>methods.  I mean would you think that `require` is odd because it can
>introduce a lot of methods without spelling them all out?

Well, I think it's sligthly more than that: All these methods are
essentially executed not with the current self, but with another,
hidden, self. For those cases where that's what you want, it's just
great, but it's still a bit of a strange feeling.

Regards,    Martin.


#-#-#  Martin J. Du"rst, Assoc. Professor, Aoyama Gakuin University
#-#-#  http://www.sw.it.aoyama.ac.jp       mailto:[e-mail]     

On Oct 6, 4:20 pm, "Austin Ziegler" <[e-mail]> wrote:
> On Mon, Oct 6, 2008 at 3:34 PM, Trans <[e-mail]> wrote:
> > On Oct 6, 2:11 pm, _why <[e-mail]> 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...

The idea of selector namespaces being that an extension applies
according to where (eg. the nesting) that an *invocation* of a method
takes place? That being the case, 'mixin/unmix' could be used, but
wouldn't the constant extending and unextending of objects be a huge
performance drain? Every method would effectively have to be prepended
with a procedure to check to see if the current nesting has changed
since the last invocation, and if so change the selected extensions
accordingly. Maybe the overhead isn't as great as I fret, but
certainly this could be happening thousands of times a second.

The only effective way I see for implementing selector namespaces is
via some sort of routing. Instead of tying a module into the class
hierarchy with direct reference pointers via a Proxy, it would need to
go through a Router that directed it to the appropriate extension
module according to the current nesting.

For example, instead of swapping the Proxy in and out, ocillating
between say:

  AClass --> ASuperClass

then

  AClass --> Proxy --> ASuperClass
              |
              '--> ModuleA

then

  AClass --> Proxy --> ASuperClass
              |
              '--> ModuleB

Rather we need:

  AClass --> Router --> ASuperClass
              |  |
              |  '--> ModuleA
              |
              '--> ModuleB

However, though I never quite understood why, but whatever causes the
well known Module Inclusion Problem, will likely be an issue with
something like this too.

T.

• Assignee set to matz (Yukihiro Matsumoto)

• Status changed from Open to Assigned

• Project changed from ruby-trunk to 14
• Category deleted (core)
• Target version deleted (3.0)

• Project changed from 14 to ruby-trunk

• Status changed from Assigned to Rejected

I'm rejecting this feature ticket because no progress has been made for a long time. See [ruby-core:42391]. -- Yusuke Endoh <[e-mail]>