ruby-dev summary 25781-25961
Kazuo Saito
Here is a summary of ruby-dev mailing list.
[ruby-dev:25853] conflict method and local variable
[ruby-dev:25879] Ruby2.0MethodSearchRule
[ruby-dev:25880] Ruby2.0LambdaWithLocalVariable
Hidetoshi Nagai asked about following behavior on 1.9:
$ /usr/local/bin/ruby -v
ruby 1.9.0 (2005-03-07) [i686-linux]
$ /usr/local/bin/ruby -e "
class A
def hoge(x)
p x
end
end
a = A.new
a.instance_eval{hoge('fuga')}
hoge = 'aaa'
a.instance_eval{hoge('fuga')}
p hoge
"
"fuga"
-e:11: undefined method `call' for "aaa":String (NoMethodError)
Matz replied that it is a experimental 2.0 feature allowing us to
call Proc object in local variables directly (See [1] for details).
During the discussion, Matz brought another new idea to change
method search rule (See [2]). The idea protects unwanted method
overriding and conflict of method signatures, by starting method
search from the class we are looking at, not from "self" object.
You can call the method in "self" object by adding "self." to
function style call.
Matz said that these are *experimental* yet and feel free to
show your idea.
[ruby-dev:25877] Ruby2.0BlockLocalVariable
SASADA Koichi suggest us consider a new specification of block local
variables, appeared on Matz blog. Babie posted a good English summary
of the spec to Redhand (See [3]). Shugo Maeda asked about warning for
statements that uses block local variables from outside of the block:
def hoge
iter{|a ; b|
...
}
p a #=> error on CVS HEAD, but this will be warned
end
He said that it may be OK to keep this causes error. Matz answered
this will be changed to warning, but users will fixed the warning
in most cases.
[1] Ruby2.0LambdaWithLocalVariable:
http://pub.cozmixng.org/~the-rwiki/rw-cgi.rb?cmd=view;
name=Ruby2.0LambdaWithLocalVariableEnglish
[2] Ruby2.0MethodSearchRule:
http://pub.cozmixng.org/~the-rwiki/rw-cgi.rb?cmd=view;
name=Ruby2.0MethodSearchRuleEnglish
[3] Ruby 2.0 block local variable:
http://redhanded.hobix.com/inspect/ruby20BlockLocalVariable.html
ruby-dev summary index:
http://i.loveruby.net/en/ruby-dev-summary.html
Kazuo Saito <ksa...@uranus.dti.ne.jp>
David A. Black
On Sat, 2 Apr 2005, Kazuo Saito wrote:
> During the discussion, Matz brought another new idea to change
> method search rule (See [2]). The idea protects unwanted method
> overriding and conflict of method signatures, by starting method
> search from the class we are looking at, not from "self" object.
> You can call the method in "self" object by adding "self." to
> function style call.
>
> Matz said that these are *experimental* yet and feel free to
> show your idea.
To paraphrase the example on the website:
class C
def process
util # will always call C#util, even if overridden
self.util # will call subclass's #util, if present
end
def util
end
end
I don't like this because it requires that when you're writing a
class, the class has to know what its subclasses (and subclass
authors) might do. In general, I don't think accidental re-use of a
method name should be recognized as something the language needs to
intervene in. The subclass author should look at and work with the
interface of the original class.
> SASADA Koichi suggest us consider a new specification of block local
> variables, appeared on Matz blog. Babie posted a good English summary
> of the spec to Redhand (See [3]). Shugo Maeda asked about warning for
> statements that uses block local variables from outside of the block:
>
> def hoge
> iter{|a ; b|
> ...
> }
> p a #=> error on CVS HEAD, but this will be warned
> end
>
> He said that it may be OK to keep this causes error. Matz answered
> this will be changed to warning, but users will fixed the warning
> in most cases.
Given that this is all being redesigned and changed, I would strongly
prefer a design where everything legal was completely legal and
everything illegal was completely illegal. Having warning scenarios
be part of a new design makes me feel like the design isn't completely
self-consistent. However, I do not claim to have a better design
(except the current one, which I prefer, but I know I've lost that
argument :-)
Thanks for the summary!
David
--
David A. Black
dbl...@wobblini.net