Ruby keywords vs methods

[Chris Roos]

Hi,

I attended Jim Weirich's talk at Rails Conf on Friday. It was about
thoughtful library design and contained a section on ways to mitigate
risk when re-opening standard libraries.

Rake uses the following pattern when adding to standard library classes...

class BaseClass
unless instance_methods.include? "foo"
def foo
# meth body here
end
end
end

It struck me that it might be quite useful to wrap this up and apply
it to all methods defined for [a] given class[es]. Unfortunately, it
appears not to be (completely) possible. I thought we might be able
to use the method_added hook, but this gets fired after the method
definition. We need something to fire right before the method
definition. As def is a keyword and not a method, we can't override
and add to the default behaviour. Note, that we can, however, do this
with define_method.

So, my actual question is, why are some things keywords and most
things method calls? I think it's io (language) that doesn't have any
keywords at all (so I guess it must be possible). In addition, I'm
interested in whether there are there any plans to increase or
decrease the number of keywords in ruby?

Looking forward to some insight,

Chris

 

[Trans]

Hi,

I attended Jim Weirich's talk at Rails Conf on Friday. It was about
thoughtful library design and contained a section on ways to mitigate
risk when re-opening standard libraries.

Rake uses the following pattern when adding to standard library classes...

class BaseClass
unless instance_methods.include? "foo"
def foo
# meth body here
end
end
end

It struck me that it might be quite useful to wrap this up and apply
it to all methods defined for [a] given class[es]. Unfortunately, it
appears not to be (completely) possible. I thought we might be able
to use the method_added hook, but this gets fired after the method
definition. We need something to fire right before the method
definition. As def is a keyword and not a method, we can't override
and add to the default behaviour. Note, that we can, however, do this
with define_method.

Well, the Extensions project does this. And another way to avoid it is
to use a module instead of adding the method directly, a la
ActiveSupport. But, I can't say I see the point exactly. Maybe I
missing a usecase. But first of all it would only really matter if
you're bringing in a whole mess of methods all at once and thus are not
sure what you are getting, otherwise you would have avoided the clash
yourself. Plus it shouldn't matter al all if you require the extensions
FIRST. After all, it's presumed you're going to use the extensions but
if you need to use one of the already used method names you're code can
just overwrite the extension definition --rather than the other way
around. Also, what if you actaully want it to override the method?

So, my actual question is, why are some things keywords and most
things method calls? I think it's io (language) that doesn't have any
keywords at all (so I guess it must be possible). In addition, I'm
interested in whether there are there any plans to increase or
decrease the number of keywords in ruby?

Seems like there's rather few as it is, but in anycase it's unlikely to
increase. Of course that's up to Matz.

T.

 

[Jeremy Tregunna]

So, my actual question is, why are some things keywords and most
things method calls? I think it's io (language) that doesn't have any
keywords at all (so I guess it must be possible).

That's correct. In Io, everything is a dynamic message send. There
are several reasons why we've chosen this route, but instead of
hijacking this thread, I'll just leave it here.

 

[Chris Roos]

It struck me that it might be quite useful to wrap this up and apply
it to all methods defined for [a] given class[es]. Unfortunately, it
appears not to be (completely) possible. I thought we might be able
to use the method_added hook, but this gets fired after the method
definition. We need something to fire right before the method
definition. As def is a keyword and not a method, we can't override
and add to the default behaviour. Note, that we can, however, do this
with define_method.

Well, the Extensions project does this.

I just had a look at the extensions project (albeit briefly) and can
only see Object#define_method. I don't think this does what I was
after. To clarify, I'm thinking (and Jim was addressing) of the case
where we import multiple libraries from different places. There is no
easy way of knowing whether two libraries modify the same class
(stdlib or otherwise) in an incompatible manner. We've actually
experienced this at work a couple of times. I recall at one point
ending up with two String#stem methods defined by different libs.

It'd be nice if, on redefining an existing method, we could get a
warning to allow us a quicker route to the problem.

This, in particular, is the problem that cannot be solved using the
def keyword but can be solved using define_method.

class Module
def existing_method?(sym)
instance_method(sym) rescue nil # seems like the easiest way to
find if a method exists in any of the public, protected, private
scopes
end
alias :define_method_before_nasty_hack :define_method
def define_method(sym, &block)
puts "Warning: Overriding existing method definition
#{self}##{sym}" if existing_method?(sym)
define_method_before_nasty_hack(sym, &block)
end
end

class Foo
define_methodfoo) do
p 'foo'
end
end

# No warning generated at this point

class Foo
define_methodfoo) do
p 'new foo'
end
end

#=> Warning: Overriding existing method definition Foo#foo

And another way to avoid it is
to use a module instead of adding the method directly, a la
ActiveSupport.

I don't quite understand how this helps, maybe you can explain?

But, I can't say I see the point exactly. Maybe I
missing a usecase. But first of all it would only really matter if
you're bringing in a whole mess of methods all at once and thus are not
sure what you are getting, otherwise you would have avoided the clash
yourself. Plus it shouldn't matter al all if you require the extensions
FIRST. After all, it's presumed you're going to use the extensions but
if you need to use one of the already used method names you're code can
just overwrite the extension definition --rather than the other way
around. Also, what if you actaully want it to override the method?

Re, if you actually want to override the method and don't want
warnings. I'd suggest that this functionality be implemented in it's
own lib (similar to whiny_nils in rails) that can be required as a
debugging tool maybe.

Seems like there's rather few as it is, but in anycase it's unlikely to
increase. Of course that's up to Matz.

I have a figure in my head of around 40 keywords - that may be
inaccurate. I'm still interested in general as to why the language
would implement somethings as keywords? I'm guessing it could be to
do with efficiency.

Thanks for the responses so far folks.

Cheers,

Chris

 

[Chris Roos]

That's correct. In Io, everything is a dynamic message send. There

are several reasons why we've chosen this route, but instead of
hijacking this thread, I'll just leave it here.

Hi Jeremy,

I wonder if you might point me to some references as to why you chose
this route. I'm already aware of io site, mail list and some of the
wikis but any links to specific info would be great.

Cheers,

Chris

 

[Pit Capitain]

It'd be nice if, on redefining an existing method, we could get a
warning to allow us a quicker route to the problem.

Chris, just call Ruby with the -w command line option. With your example

class Foo
def foo
p 'foo'
end
end

class Foo
def foo
p 'new foo'
end
end

I get

warning: method redefined; discarding old foo

Regards,
Pit

 

[Chris Roos]

Chris, just call Ruby with the -w command line option. With your example

class Foo
def foo
p 'foo'
end
end

class Foo
def foo
p 'new foo'
end
end

I get

warning: method redefined; discarding old foo

Regards,
Pit

Ok, so this is being pedantic, but that doesn't appear to work if you
have two separate files, each defining Foo#foo, both being required by
another script.

Although I am interested in solutions to this 'problem', I'd still
love feedback on the decision of adding keywords to the language.
Maybe I should break that to another thread with a better subject (any
suggestions)?

Cheers,

Chris

 

[Pit Capitain]

Ok, so this is being pedantic, but that doesn't appear to work if you
have two separate files, each defining Foo#foo, both being required by
another script.

Works for me with Ruby 1.8.4 (2005-12-24) [i386-mswin32] on Windows 2000.

Although I am interested in solutions to this 'problem', I'd still
love feedback on the decision of adding keywords to the language.

I cannot answer that. I too think that having less keywords increases
the flexibility of a language, but there could be other drawbacks, for
example concerning performance or syntax changes, I don't know. Maybe
you can get an answer from Matz about this.

Another way to solve your original problem would be to add more hooks to
the Ruby interpreter.

Maybe I should break that to another thread with a better subject (any
suggestions)?

For me the subject is OK, I just wanted to answer the one detail
question about warnings upon method redefinitions.

Regards,
Pit

 

[Verno Miller]

Posted by Chris Roos (Guest)

on 16.09.2006 01:47

Hi,

I attended Jim Weirich's talk at Rails Conf on Friday. It was about
thoughtful library design and contained a section on ways to mitigate
risk when re-opening standard libraries.
...
It struck me that it might be quite useful to wrap this up and apply
it to all methods defined for [a] given class[es]. Unfortunately, it
appears not to be (completely) possible. I thought we might be able
to use the method_added hook, but this gets fired after the method
definition. We need something to fire right before the method
definition. As def is a keyword and not a method, we can't override
and add to the default behaviour. Note, that we can, however, do this
with define_method.

Maybe also check out metaprogramming hacks similar to the "Alternative
to inheriting from Array" (
http://www.bigbold.com/snippets/posts/show/2573 )!

 

[Chris Roos]

Ok, so this is being pedantic, but that doesn't appear to work if you
have two separate files, each defining Foo#foo, both being required by
another script.

Works for me with Ruby 1.8.4 (2005-12-24) [i386-mswin32] on Windows 2000.

You are, of course, absolutely right. I was obviously doing something
stoopid when I tested it earlier.

I cannot answer that. I too think that having less keywords increases
the flexibility of a language, but there could be other drawbacks, for
example concerning performance or syntax changes, I don't know. Maybe
you can get an answer from Matz about this.

Another way to solve your original problem would be to add more hooks to
the Ruby interpreter.

Hmm, although you've now shown me that this use case is essentially
null and void. I'll have to come up with some other complicated
answers to things that I don't realise are baked right into the
interpreter

For me the subject is OK, I just wanted to answer the one detail
question about warnings upon method redefinitions.

Cool, I appreciate your input.

Chris

 

[Jeremy Tregunna]

Hi Jeremy,

I wonder if you might point me to some references as to why you chose
this route. I'm already aware of io site, mail list and some of the
wikis but any links to specific info would be great.

Io suffers from a chronic lack of documentation (one several of us
are trying to fix at the moment, but it's going slowly). Your best
bet for sources of information, is the #io IRC channel on
irc.freenode.net. Steve Dekorte, myself, or a few others could fill
you in on many details.