# Nested defs, what if **URL:** \ **Category:** ruby-talk\ **Created:** [2 December 2004 14:44 UTC](https://rubytalk.org/t/nested-defs-what-if/15095 "2004-12-02T14:44:08Z")\ **Posts on this page:** 17\ **Page:** 1
**Author:** ![Hugh\_Sasse](https://avatars.discourse-cdn.com/v4/letter/h/d6d6ee/32.png) [@Hugh\_Sasse](https://rubytalk.org/u/Hugh_Sasse)\ **Post date:** [2 December 2004 14:44 UTC](https://rubytalk.org/t/nested-defs-what-if/15095/1 "2004-12-02T14:44:08Z")
This is too half-baked to be an RCR, but here goes... At the moment we cannot write class Thingy    def somefunc      def newfunc        ...      end    end end OK, fair enough, somefunc is an instance method, so what would newfunc get defined as? It could not be an instance method because it might depend on variables having values which differ in another instance. So, my half-baked idea: let the above code be a shorthand for class Thingy    def somefunc      class \<\< self        def newfunc          ...        end      end    end end This would have the [questionable] advantage that it would hide that relatively obscure class \<\< self syntax used in constructing singletons, and it would be better tnan passing a string to instance eval because it would get syntax highlighted by the editor. It is not legal now, so old code would not break. So, now I'll push this idea out and see if it sinks...          Hugh ---
**Author:** ![Austin\_Ziegler5](https://yyz1.discourse-cdn.com/flex029/user_avatar/rubytalk.org/austin_ziegler5/32/1985_2.png) [@Austin\_Ziegler5](https://rubytalk.org/u/Austin_Ziegler5)\ **Post date:** [2 December 2004 14:57 UTC](https://rubytalk.org/t/nested-defs-what-if/15095/2 "2004-12-02T14:57:09Z")
irb(main):001:0\> class Thingy irb(main):002:1\> def somefunc irb(main):003:2\> def newfunc irb(main):004:3\> end irb(main):005:2\> end irb(main):006:1\> end irb(main):007:0\> Thingy.instance\_methods.grep(/func/) =\> ["somefunc"] irb(main):009:0\> Thingy.new.somefunc =\> nil irb(main):010:0\> Thingy.instance\_methods.grep(/func/) =\> ["newfunc", "somefunc"] -austin > **···** > > On Thu, 2 Dec 2004 23:44:08 +0900, Hugh Sasse Staff Elec Eng \ wrote: > > > This is too half-baked to be an RCR, but here goes... > > > > At the moment we cannot write > > > > class Thingy > >    def somefunc > >      def newfunc > >        ... > >      end > >    end > > end > > -- > Austin Ziegler \* halostatue@gmail.com >                \* Alternate: austin@halostatue.ca ---
**Author:** ![Yukihiro\_Matsumoto2](https://avatars.discourse-cdn.com/v4/letter/y/b9e5f3/32.png) [@Yukihiro\_Matsumoto2](https://rubytalk.org/u/Yukihiro_Matsumoto2)\ **Post date:** [2 December 2004 15:08 UTC](https://rubytalk.org/t/nested-defs-what-if/15095/3 "2004-12-02T15:08:07Z")
Hi, > **···** > > In message "Re: nested defs, what if..." on Thu, 2 Dec 2004 23:44:08 +0900, Hugh Sasse Staff Elec Eng \ writes: > > > So, my half-baked idea: let the above code be a shorthand for > > > > class Thingy > >   def somefunc > >     class \<\< self > >       def newfunc > >         ... > >       end > >     end > >   end > > end > > I had the same half-baked idea before, but has not been sure how much > it is useful. If you come up a new insight, it might be happened. > >               matz. ---
**Author:** ![Hugh\_Sasse](https://avatars.discourse-cdn.com/v4/letter/h/d6d6ee/32.png) [@Hugh\_Sasse](https://rubytalk.org/u/Hugh_Sasse)\ **Post date:** [2 December 2004 15:19 UTC](https://rubytalk.org/t/nested-defs-what-if/15095/4 "2004-12-02T15:19:41Z")
OH!! This didn't work in the past. I never noticed it change. I'll have to see what happens when it depends on variable values then ...          Hugh (somewhat embarrassed) > **···** > > On Thu, 2 Dec 2004, Austin Ziegler wrote: > > > irb(main):007:0\> Thingy.instance\_methods.grep(/func/) > > =\> ["somefunc"] > > irb(main):009:0\> Thingy.new.somefunc > > =\> nil > > irb(main):010:0\> Thingy.instance\_methods.grep(/func/) > > =\> ["newfunc", "somefunc"] ---
**Author:** ![Hugh\_Sasse](https://avatars.discourse-cdn.com/v4/letter/h/d6d6ee/32.png) [@Hugh\_Sasse](https://rubytalk.org/u/Hugh_Sasse)\ **Post date:** [2 December 2004 16:18 UTC](https://rubytalk.org/t/nested-defs-what-if/15095/5 "2004-12-02T16:18:26Z")
> Hi,          [...] > I had the same half-baked idea before, but has not been sure how much > it is useful. If you come up a new insight, it might be happened. > >               matz. Thanks, Matz. If I get struck by any "bolts of inspiration" I'll let you know.          Thank you,          Hugh > **···** > > On Fri, 3 Dec 2004, Yukihiro Matsumoto wrote: ---
**Author:** ![Brian\_SchrA\_der](https://avatars.discourse-cdn.com/v4/letter/b/c67d28/32.png) [@Brian\_SchrA\_der](https://rubytalk.org/u/Brian_SchrA_der)\ **Post date:** [2 December 2004 17:22 UTC](https://rubytalk.org/t/nested-defs-what-if/15095/6 "2004-12-02T17:22:07Z")
But where is this usefull? It seems only complicated and inefficent to me (Doesn't it create a new instance method on each call?): class A   def a()     def b()       self     end     self   end end     ==\>nil A.new.b NoMethodError: undefined method `b' for #\         from (irb):2 A.new.a     ==\>#\ A.new.a.b     ==\>#\ A.new.b     ==\>#\ > **···** > > On Thu, 2 Dec 2004 23:57:09 +0900 Austin Ziegler \ wrote: > > > On Thu, 2 Dec 2004 23:44:08 +0900, Hugh Sasse Staff Elec Eng \> \ wrote: > > \> This is too half-baked to be an RCR, but here goes... > > \> > > \> At the moment we cannot write > > \> > > \> class Thingy > > \> def somefunc > > \> def newfunc > > \> ... > > \> end > > \> end > > \> end > > > > irb(main):001:0\> class Thingy > > irb(main):002:1\> def somefunc > > irb(main):003:2\> def newfunc > > irb(main):004:3\> end > > irb(main):005:2\> end > > irb(main):006:1\> end > > irb(main):007:0\> Thingy.instance\_methods.grep(/func/) > > =\> ["somefunc"] > > irb(main):009:0\> Thingy.new.somefunc > > =\> nil > > irb(main):010:0\> Thingy.instance\_methods.grep(/func/) > > =\> ["newfunc", "somefunc"] > > -- > Brian Schröder > [http://www.brian-schroeder.de/](http://www.brian-schroeder.de/) ---
**Author:** ![T\_Onoma](https://avatars.discourse-cdn.com/v4/letter/t/c2a13f/32.png) [@T\_Onoma](https://rubytalk.org/u/T_Onoma)\ **Post date:** [2 December 2004 23:20 UTC](https://rubytalk.org/t/nested-defs-what-if/15095/7 "2004-12-02T23:20:34Z")
It is interesting. Does this mean that an \_object\_ could dynamically change the state of all objects of its class? I have to test.... class T   def a     def b       puts "Hello"     end end end =\> nil t = T.new =\> #\ t2 = T.new =\> #\ t.b =\> NoMethodError: undefined method `b' for #\ t2.b =\> NoMethodError: undefined method `b' for #\ t.a =\> nil t.b =\> nil Hello t2.b =\> nil Hello Yep. It sure does. This is very strange indeed. I wonder if you could write extentions in this way.   class String     def use(x)       case x       when :chars         def chars           self.split(//)         end       when :tab         # ...       end     end   end Of course, you have to instantiate a string first. Well, it's an idea, but I don't think a very good one. In general I don't think this is useful, and would rather obfuscate code if actually used. I think what would be more useful is if such methods were local methods, like local variables:   class A     def a       def b(x)         x + 1       end       10.times{ |i| print b(i) }     end   end   o = A.new   o.b =\> NoMethodError   A.a =\> 12345678910   o.b =\> NoMethodError This would allow for embedded subroutines --much more useful. T. > **···** > > On Thursday 02 December 2004 12:22 pm, Brian Schröder wrote: > > > But where is this usefull? It seems only complicated and inefficent to me > > (Doesn't it create a new instance method on each call?): > > > > class A > >   def a() > >     def b() > >       self > >     end > >     self > >   end > > end > >     ==\>nil > > A.new.b > > NoMethodError: undefined method `b' for #\ > >         from (irb):2 > > A.new.a > >     ==\>#\ > > A.new.a.b > >     ==\>#\ > > A.new.b > >     ==\>#\ ---
**Author:** ![Nobuyoshi\_Nakada](https://avatars.discourse-cdn.com/v4/letter/n/edb3f5/32.png) [@Nobuyoshi\_Nakada](https://rubytalk.org/u/Nobuyoshi_Nakada)\ **Post date:** [3 December 2004 02:47 UTC](https://rubytalk.org/t/nested-defs-what-if/15095/8 "2004-12-03T02:47:32Z")
Hi, At Fri, 3 Dec 2004 08:20:34 +0900, trans. (T. Onoma) wrote in [ruby-talk:122265]: > Well, it's an idea, but I don't think a very good one. In general I don't > think this is useful, and would rather obfuscate code if actually used. I > think what would be more useful is if such methods were local methods, like > local variables: I also have thought the idea, though haven't implemented it. I'm still worndering whether this should be valid or error.   class A     def a(y)       def b(x)         x + y # `y' in a or `undefined local variable'?       end       10.times{ |i| print b(i) }     end   end > **···** > > -- > Nobu Nakada ---
**Author:** ![Kevin\_Bullock1](https://avatars.discourse-cdn.com/v4/letter/k/aca169/32.png) [@Kevin\_Bullock1](https://rubytalk.org/u/Kevin_Bullock1)\ **Post date:** [3 December 2004 06:43 UTC](https://rubytalk.org/t/nested-defs-what-if/15095/9 "2004-12-03T06:43:26Z")
This would also make Ruby more like LISP, which allows any depth of inner functions to be defined. Those inner functions are only in scope in the defining function. Ruby's blocks function this way right now, actually. That is, to achieve the above effect, you could do: class A    def a      b = proc do |x|        x + 1      end      10.times { |i| print b.call(i) }    end end o = A.new      ==\>#\ o.b NoMethodError: undefined method `b' for #\          from (irb):10 o.a 12345678910 ==\>10 o.b NoMethodError: undefined method `b' for #\          from (irb):13 In this example, b is a reference to a block, rather than a method, and b is only in scope within a(). Embedded subroutines can indeed be useful, especially in recursive methods that use an "interface method" and a "worker method" that takes extra parameters. For example: def fact( n )    def fact\_iter( n, total )      if n == 1        total      else        fact\_iter( n - 1, total \* n )      end    end    fact\_iter( n, 1 ) end fact( 3 ) ==\> 6 In this case, fact\_iter() doesn't need to be visible to the outside world; but the way Ruby currently works, the following can happen: fact\_iter( 3 ) ==\> 6 The question becomes, though, whether or not fact\_iter() is being defined every time fact() is called. It shouldn't be hard to optimize around this redefinition problem. (Does Ruby already do so?) Pacem in terris / Mir / Shanti / Salaam / Heiwa Kevin R. Bullock > **···** > > On Dec 2, 2004, at 5:20 PM, trans. (T. Onoma) wrote: > > > Well, it's an idea, but I don't think a very good one. In general I don't > > think this is useful, and would rather obfuscate code if actually used. I > > think what would be more useful is if such methods were local methods, like > > local variables: > > > >   class A > >     def a > >       def b(x) > >         x + 1 > >       end > >       10.times{ |i| print b(i) } > >     end > >   end > > > >   o = A.new > >   o.b =\> NoMethodError > >   A.a =\> 12345678910 > >   o.b =\> NoMethodError > > > > This would allow for embedded subroutines --much more useful. ---
**Author:** ![Brian\_SchrA\_der](https://avatars.discourse-cdn.com/v4/letter/b/c67d28/32.png) [@Brian\_SchrA\_der](https://rubytalk.org/u/Brian_SchrA_der)\ **Post date:** [3 December 2004 10:27 UTC](https://rubytalk.org/t/nested-defs-what-if/15095/10 "2004-12-03T10:27:58Z")
I tried this in fact while learning ruby, and was disappointed, that it did not work the way I expected. The last language before Ruby was Delphi (Object Pascal) where you can have nested subroutines. I think they are a lot clearer than having to flatten everything out. Regards, Brian > **···** > > On Fri, 3 Dec 2004 08:20:34 +0900 "trans. (T. Onoma)" \ wrote: > > > [snip] > > Well, it's an idea, but I don't think a very good one. In general I don't > > think this is useful, and would rather obfuscate code if actually used. I > > think what would be more useful is if such methods were local methods, like > > local variables: > > > >   class A > >     def a > >       def b(x) > >         x + 1 > >       end > >       10.times{ |i| print b(i) } > >     end > >   end > > > >   o = A.new > >   o.b =\> NoMethodError > >   A.a =\> 12345678910 > >   o.b =\> NoMethodError > > > > This would allow for embedded subroutines --much more useful. > > -- > Brian Schröder > [http://www.brian-schroeder.de/](http://www.brian-schroeder.de/) ---
**Author:** ![Gavin\_Sinclair](https://avatars.discourse-cdn.com/v4/letter/g/db5fbb/32.png) [@Gavin\_Sinclair](https://rubytalk.org/u/Gavin_Sinclair)\ **Post date:** [3 December 2004 05:00 UTC](https://rubytalk.org/t/nested-defs-what-if/15095/11 "2004-12-03T05:00:44Z")
Is there any difference between an "inner method" (with 'y' in a) and a lambda? I've happily used lambdas to define private functionality before, but I'm concerned about efficiency:   class A     def a(y)       b = lambda { |x| x + y }       10.times { |i| print b(i) }     end   end Does the lambda attached to b get regenerated with each call to a? Gavin > **···** > > On Friday, December 3, 2004, 1:47:32 PM, nobu wrote: > > > Hi, > > > At Fri, 3 Dec 2004 08:20:34 +0900, > > trans. (T. Onoma) wrote in [ruby-talk:122265]: > > > > > Well, it's an idea, but I don't think a very good one. In general I don't > > > think this is useful, and would rather obfuscate code if actually used. I > > > think what would be more useful is if such methods were local methods, like > > > local variables: > > > I also have thought the idea, though haven't implemented it. > > I'm still worndering whether this should be valid or error. > > >   class A > >     def a(y) > >       def b(x) > >         x + y # `y' in a or `undefined local variable'? > >       end > >       10.times{ |i| print b(i) } > >     end > >   end ---
**Author:** ![Nobuyoshi\_Nakada](https://avatars.discourse-cdn.com/v4/letter/n/edb3f5/32.png) [@Nobuyoshi\_Nakada](https://rubytalk.org/u/Nobuyoshi_Nakada)\ **Post date:** [3 December 2004 05:18 UTC](https://rubytalk.org/t/nested-defs-what-if/15095/12 "2004-12-03T05:18:38Z")
Hi, At Fri, 3 Dec 2004 14:00:44 +0900, Gavin Sinclair wrote in [ruby-talk:122305]: > \> class A > \> def a(y) > \> def b(x) > \> x + y # `y' in a or `undefined local variable'? > \> end > \> 10.times{ |i| print b(i) } > \> end > \> end > > Is there any difference between an "inner method" (with 'y' in a) and > a lambda? Actually, no. Just a syntax sugar, and it would be implemented using a lambda. And another question; should b be visible from other methods called from a? > I've happily used lambdas to define private functionality before, but > I'm concerned about efficiency: > >   class A >     def a(y) >       b = lambda { |x| x + y } >       10.times { |i| print b(i) } >     end >   end > > Does the lambda attached to b get regenerated with each call to a? I guess so. > **···** > > -- > Nobu Nakada ---
**Author:** ![Gavin\_Sinclair](https://avatars.discourse-cdn.com/v4/letter/g/db5fbb/32.png) [@Gavin\_Sinclair](https://rubytalk.org/u/Gavin_Sinclair)\ **Post date:** [3 December 2004 05:37 UTC](https://rubytalk.org/t/nested-defs-what-if/15095/13 "2004-12-03T05:37:22Z")
> Hi, > At Fri, 3 Dec 2004 14:00:44 +0900, > Gavin Sinclair wrote in [ruby-talk:122305]: > > > \> class A > > \> def a(y) > > \> def b(x) > > \> x + y # `y' in a or `undefined local variable'? > > \> end > > \> 10.times{ |i| print b(i) } > > \> end > > \> end > > > > Is there any difference between an "inner method" (with 'y' in a) and > > a lambda? > Actually, no. Just a syntax sugar, and it would be implemented > using a lambda. And another question; should b be visible from > other methods called from a? I don't think so. I can't imagine a use case, and the \_appearance\_ of the code is that b() is private to a(). > > I've happily used lambdas to define private functionality before, but > > I'm concerned about efficiency: > > > >   class A > >     def a(y) > >       b = lambda { |x| x + y } > >       10.times { |i| print b(i) } > >     end > >   end > > > > Does the lambda attached to b get regenerated with each call to a? > I guess so. So an inner method, which \_looks\_ static, would actually be inefficiently regenerated each time? (You said the inner method would be syntax sugar for a lambda.) Gavin > **···** > > On Friday, December 3, 2004, 4:18:38 PM, nobu wrote: ---
**Author:** ![T\_Onoma](https://avatars.discourse-cdn.com/v4/letter/t/c2a13f/32.png) [@T\_Onoma](https://rubytalk.org/u/T_Onoma)\ **Post date:** [3 December 2004 06:02 UTC](https://rubytalk.org/t/nested-defs-what-if/15095/14 "2004-12-03T06:02:49Z")
Hi -- > Gavin Sinclair wrote in [ruby-talk:122305]: > \> \> class A > \> \> def a(y) > \> \> def b(x) > \> \> x + y # `y' in a or `undefined local variable'? > \> \> end > \> \> 10.times{ |i| print b(i) } > \> \> end > \> \> end > \> > \> Is there any difference between an "inner method" (with 'y' in a) and > \> a lambda? > > Actually, no. Just a syntax sugar, and it would be implemented > using a lambda. And another question; should b be visible from > other methods called from a? First, it is debatable as to whether `y' should have an open scope like a lambda. But I think "no". def a() cannot see vars outside its scope either, so nor should def b(). This gives good inner namespace protection and differentiates its functionality from a lambda. Second, b() should not be visible from other methods just a local vars are not visible. I am surprised to hear they would be implemented using lambdas. I was under the impression that implementation of Procs and Methods are quite different. > \> I've happily used lambdas to define private functionality before, but > \> I'm concerned about efficiency: > \> > \> class A > \> def a(y) > \> b = lambda { |x| x + y } > \> 10.times { |i| print b(i) } > \> end > \> end > \> > \> Does the lambda attached to b get regenerated with each call to a? Yes, I think so since lambdas are not singleton/multiton (could they be?) Of course the fix is something like:    class A      def a(y)        @a\_b ||= lambda { |x| x + y }        10.times { |i| print @a\_b(i) }      end    end But true inner methods would be the bomb for these use cases (IMHO). T. > **···** > > On Friday 03 December 2004 12:18 am, nobu.nokada@softhome.net wrote: ---
**Author:** ![T\_Onoma](https://avatars.discourse-cdn.com/v4/letter/t/c2a13f/32.png) [@T\_Onoma](https://rubytalk.org/u/T_Onoma)\ **Post date:** [3 December 2004 06:04 UTC](https://rubytalk.org/t/nested-defs-what-if/15095/15 "2004-12-03T06:04:09Z")
Yea, that's not good. They need to persist, bound to the local scope. T. > **···** > > On Friday 03 December 2004 12:37 am, Gavin Sinclair wrote: > > > So an inner method, which \_looks\_ static, would actually be > > inefficiently regenerated each time? (You said the inner method would > > be syntax sugar for a lambda.) ---
**Author:** ![Mauricio\_Fernndez](https://avatars.discourse-cdn.com/v4/letter/m/e495f1/32.png) [@Mauricio\_Fernndez](https://rubytalk.org/u/Mauricio_Fernndez)\ **Post date:** [3 December 2004 09:00 UTC](https://rubytalk.org/t/nested-defs-what-if/15095/16 "2004-12-03T09:00:23Z")
> Yes, I think so since lambdas are not singleton/multiton (could they be?) Of > course the fix is something like: > >    class A >      def a(y) >        @a\_b ||= lambda { |x| x + y } >        10.times { |i| print @a\_b(i) } >      end >    end Not quite... > > class A; def a(y); @a\_b ||= lambda { |x| x + y }; 10.times { |i| > > print @a\_b[i]}; end end =\> nil > > a = A.new =\> #\ > > a.a(10) 10111213141516171819=\> 10 > > a.a(1000) 10111213141516171819=\> 10 > But true inner methods would be the bomb for these use cases (IMHO). They don't seem any more powerful than lambdas, just sugar. They would offer some opportunities for optimization though. > **···** > > On Fri, Dec 03, 2004 at 03:02:49PM +0900, trans. (T. Onoma) wrote: > > -- > Hassle-free packages for Ruby? > RPA is available from [http://www.rubyarchive.org/](http://www.rubyarchive.org/) ---
**Author:** ![T\_Onoma](https://avatars.discourse-cdn.com/v4/letter/t/c2a13f/32.png) [@T\_Onoma](https://rubytalk.org/u/T_Onoma)\ **Post date:** [3 December 2004 11:57 UTC](https://rubytalk.org/t/nested-defs-what-if/15095/17 "2004-12-03T11:57:24Z")
> \> Yes, I think so since lambdas are not singleton/multiton (could they be?) > \> Of course the fix is something like: > \> > \> class A > \> def a(y) > \> @a\_b ||= lambda { |x| x + y } > \> 10.times { |i| print @a\_b(i) } > \> end > \> end > > Not quite... > \>\> class A; def a(y); @a\_b ||= lambda { |x| x + y }; 10.times { |i| > \>\> print @a\_b[i]}; end end > =\> nil > \>\> a = A.new > =\> #\ > \>\> a.a(10) > 10111213141516171819=\> 10 > \>\> a.a(1000) > 10111213141516171819=\> 10 Ah right. There's a gotchya. Try,     class A       def a(y)         @a\_b ||= lambda { |x,y| x + y }         10.times { |i| print @a\_b(i,y) }       end     end I think this is another reason for having the inner defs with a protected scope. > \> But true inner methods would be the bomb for these use cases (IMHO). > > They don't seem any more powerful than lambdas, just sugar. > They would offer some opportunities for optimization though. Depends on the meaning of "powerful". But see above. Scope isolation can be advantageous. And, yes, optimization would be nice too. T. > **···** > > On Friday 03 December 2004 04:00 am, Mauricio Fernández wrote: > > > On Fri, Dec 03, 2004 at 03:02:49PM +0900, trans. (T. Onoma) wrote: