nested methods don't really exist?!

[Trans]

Hi --








I would guess because it's easier to constrain it to self.class, than
to un-constrain it to the outer class. In other words, you can do:

def a
def c
end
def self.b
end
end

but if the def c implied self, you'd have to jump through more hoops
to get at the outer class than you do to get *from* the outer class to
the singleton class. (I'm not claiming any great usefulness for this
idiom, but I imagine that's why the syntax is optimized for the outer
class case.)

Hmm... still a little confusion here. I don;t mean that it would imply
self, but that it would it would imply self.class. In other words, say
we had this code:

module N
def a
def b
"foo"
end
end
end

class X
include N
end

X.new.a

Currently we get:

N.instance_methods(false) #=> ["a", "b"]
X.instance_methods(false) #=> []

But why isn't it:

N.instance_methods(false) #=> ["a"]
X.instance_methods(false) #=> ["b"]

I'm not sure what it would mean to localize the method. Do you mean
it would be automatically removed from the class (whether singleton or
otherwise) when the method returns? That seems like something more
suited to an anonymous function. To have volatile method names like
that would also be a threading nightmare, I suspect.

Oh no. I mean that the method would actually be defined essentially
like a local variable is. So I don't think there wouldn't be threading
issues because the method isn't accessible outside it's locality
(outer method). You are right though, anonymous function are more
suited. But the problem there is we loose the method/variable
"ambiguity" I mentioned, because we have to invoke lambdas with a
different syntax.

Hmm.. if we could just methodize variables somehow. Maybe we could use
a different defining method? Say, #fn. Eg.

def x
f = fn { |z| z + 1 }
f(2)
end

x #=> 3

This is interesting because we could apply it to other type of
variables too, such as globals.

$int = fn { |n| Integer(n) }
$int("20") #=> 20

And it would make my argument in favor of localizing inner defs moot.

T.

 

[Trans]

Oh no. I mean that the method would actually be defined essentially
like a local variable is. So I don't think there wouldn't be threading
issues because the method isn't accessible outside it's locality
(outer method).

s/wouldn't/would/

T.

 

[James Britt]

There are dynamic behavior scenarios such as memoize where it could be
used. But such cases are pretty rare. So I agree. Unless inner defs
are local to their outer def, akin to local variables, they really
aren't very useful --being little more than a shortcut for (class <<
self; self; end).define_method().

Early on, SICP shows the use of inner methods for abstracting function
behavior but Ruby does not afford the same scoping.


--
James Britt

"Simplicity of the language is not what matters, but
simplicity of use."
- Richard A. O'Keefe in squeak-dev mailing list

 

[dblack]

Hi --

Hmm... still a little confusion here. I don;t mean that it would imply
self, but that it would it would imply self.class. In other words, say
we had this code:

Yes, I think I misunderstood, and garbled the answer anyway. So let's
start again

module N
def a
def b
"foo"
end
end
end

class X
include N
end

X.new.a

Currently we get:

N.instance_methods(false) #=> ["a", "b"]
X.instance_methods(false) #=> []

But why isn't it:

N.instance_methods(false) #=> ["a"]
X.instance_methods(false) #=> ["b"]

I'll give a modified version of my original answer. If the default is
to put the inner def in the same context as the outer def, then the
simplest case (no change in context) has the simplest syntax, and it
goes from there. If the default is to put it in the context of
self.class at the time of execution, then getting it into the flat
context would require more effort.

So I think it just keeps the semantics congruent with the syntax, or
something. One case or the other is going to require class_eval or
equivalent, so I guess having the default case be the one where
there's no automatic context-switching just keeps it more simple.


David

--
Q. What is THE Ruby book for Rails developers?
A. RUBY FOR RAILS by David A. Black (http://www.manning.com/black)
(See what readers are saying! http://www.rubypal.com/r4rrevs.pdf)
Q. Where can I get Ruby/Rails on-site training, consulting, coaching?
A. Ruby Power and Light, LLC (http://www.rubypal.com)

 

[Robert Dober]

Hi --

Hmm... still a little confusion here. I don;t mean that it would imply
self, but that it would it would imply self.class. In other words, say
we had this code:

Yes, I think I misunderstood, and garbled the answer anyway. So let's
start again

module N
def a
def b
"foo"
end
end
end

class X
include N
end

X.new.a

Currently we get:

N.instance_methods(false) #=> ["a", "b"]
X.instance_methods(false) #=> []

But why isn't it:

N.instance_methods(false) #=> ["a"]
X.instance_methods(false) #=> ["b"]

I'll give a modified version of my original answer. If the default is
to put the inner def in the same context as the outer def, then the
simplest case (no change in context) has the simplest syntax, and it
goes from there. If the default is to put it in the context of
self.class at the time of execution, then getting it into the flat
context would require more effort.

So I think it just keeps the semantics congruent with the syntax, or
something. One case or the other is going to require class_eval or
equivalent, so I guess having the default case be the one where
there's no automatic context-switching just keeps it more simple.

This seems however to be the first case I ever have seen where the
Proxy of the Mixin is not transparent any more.

Robert

 

[dblack]

Hi --

module N
def a
def b
"foo"
end
end
end

class X
include N
end

X.new.a

Currently we get:

N.instance_methods(false) #=> ["a", "b"]
X.instance_methods(false) #=> []

But why isn't it:

N.instance_methods(false) #=> ["a"]
X.instance_methods(false) #=> ["b"]

I'll give a modified version of my original answer. If the default is
to put the inner def in the same context as the outer def, then the
simplest case (no change in context) has the simplest syntax, and it
goes from there. If the default is to put it in the context of
self.class at the time of execution, then getting it into the flat
context would require more effort.

So I think it just keeps the semantics congruent with the syntax, or
something. One case or the other is going to require class_eval or
equivalent, so I guess having the default case be the one where
there's no automatic context-switching just keeps it more simple.

This seems however to be the first case I ever have seen where the
Proxy of the Mixin is not transparent any more.

How about constants:

module M
A = 1
def a
puts A
end
end

class C
include M
A = 2
end

C.new.a # 1

I think def is considered to be part of the business of the module
where it's physically located, kind of in a constant way.


David

--
Q. What is THE Ruby book for Rails developers?
A. RUBY FOR RAILS by David A. Black (http://www.manning.com/black)
(See what readers are saying! http://www.rubypal.com/r4rrevs.pdf)
Q. Where can I get Ruby/Rails on-site training, consulting, coaching?
A. Ruby Power and Light, LLC (http://www.rubypal.com)

 

[Robert Dober]

Hi --

Trans wrote:

module N
def a
def b
"foo"
end
end
end

class X
include N
end

X.new.a

Currently we get:

N.instance_methods(false) #=> ["a", "b"]
X.instance_methods(false) #=> []

But why isn't it:

N.instance_methods(false) #=> ["a"]
X.instance_methods(false) #=> ["b"]

I'll give a modified version of my original answer. If the default is
to put the inner def in the same context as the outer def, then the
simplest case (no change in context) has the simplest syntax, and it
goes from there. If the default is to put it in the context of
self.class at the time of execution, then getting it into the flat
context would require more effort.

So I think it just keeps the semantics congruent with the syntax, or
something. One case or the other is going to require class_eval or
equivalent, so I guess having the default case be the one where
there's no automatic context-switching just keeps it more simple.

This seems however to be the first case I ever have seen where the
Proxy of the Mixin is not transparent any more.

How about constants:

module M
A = 1
def a
puts A
end
end

class C
include M
A = 2
end

C.new.a # 1

I think def is considered to be part of the business of the module
where it's physically located, kind of in a constant way.


David

Ah thanks, I was not aware of this case.

Robert

 

[Trans]

Hi --

Hmm... still a little confusion here. I don;t mean that it would imply
self, but that it would it would imply self.class. In other words, say
we had this code:

Yes, I think I misunderstood, and garbled the answer anyway. So let's
start again

module N
def a
def b
"foo"
end
end
end

class X
include N
end

Currently we get:

N.instance_methods(false) #=> ["a", "b"]
X.instance_methods(false) #=> []

But why isn't it:

N.instance_methods(false) #=> ["a"]
X.instance_methods(false) #=> ["b"]

I'll give a modified version of my original answer. If the default is
to put the inner def in the same context as the outer def, then the
simplest case (no change in context) has the simplest syntax, and it
goes from there. If the default is to put it in the context of
self.class at the time of execution, then getting it into the flat
context would require more effort.

So I think it just keeps the semantics congruent with the syntax, or
something. One case or the other is going to require class_eval or
equivalent, so I guess having the default case be the one where
there's no automatic context-switching just keeps it more simple.

In other words, the conciser syntax does the thing that would be
harder to do via normal meta-coding. Good enough reason for me.
(Though I'd still like a way to create local methods via anonymous
functions).

Thanks David,
T.