Issue #13939 has been updated by shevegen (Robert A. Heiler).


Let's ignore the "Seattle.rb style" for the moment because I don't know of such a
thing - may well be seattle-duck style. :P

But anyway, I agree with you in at the least one point, which is the warning message:

> Anyone who tries to load my 'read_source' gem will get a failure message
> in require without explaining the specific area of code.

Perhaps the error message could be more indicative of the error or what the exact
problem is or how to solve it. I understand that the () provide additional information
that is in some way useful to the parser, or whatever is responsible, so perhaps the
message above could be changed somewhat.

I guess ruby core prefers short messages when possible (aka "syntax error, unexpected '}'")
but this is indeed not always extremely helpful. With more recent changes such as the
did-you-mean-gem, but also some other discussions about better and more fine-tuned 
control over warnings/error messages, that may be helpul.

To the issue about differential parsing, that is actually indeed strange.

Even more surprising is that I actually thought that:

    define_method(:some_method_name) { "asdf" }

Is the only way to use define_method()   :D

I think I used that always ...

It reminds me a bit of:

    get '/' do
      play_intro_music
    end

versus

    get '/' { play_intro_music }
    # which does not work

versus

    get('/') { play_intro_music }

which works. I always thought that in some cases the ruby parse
needs the (). I'd love to be able to make them optional in the
second case. Oddly enough, for method DEFINITIONS, I always use
() when there are arguments, so "def foo(bar)" is what I prefer
over "def foo bar". This is more an aside though, it is strange
that this changed.

By the way your last example does not work as-is :D

    define_method :johny, instance_method(:apple)

NoMethodError: undefined method `instance_method' for main:Object

Sorry for nitpicking there, I understand what you mean.

I guess it may be because of {} having different meanings in ruby
but then again, there was probably some reason unless it was an 
accident. It's ~3:15 in Tokyo so I guess in a few hours perhaps 
some from the ruby core team can chime in. I did not even know
that we could omit the () there, that was awesome if that was 
possible. I remember in my code though, that whenever I used 
define_method(), I always used () ... usually in combination with
some *eval* method thing.

----------------------------------------
Bug #13939: Ruby 2.4.2 has issue supporting Seattle.rb style for define_method
https://bugs.ruby-lang.org/issues/13939#change-66913

* Author: danielpclark (Daniel P. Clark)
* Status: Open
* Priority: Normal
* Assignee: 
* Target version: 
* ruby -v: ruby 2.4.2p198 (2017-09-14 revision 59899) [x86_64-linux]
* Backport: 2.2: UNKNOWN, 2.3: UNKNOWN, 2.4: UNKNOWN
----------------------------------------
In Ruby 2.3 & 2.4.0 you can do this

~~~ruby
define_method :some_method_name { "asdf" }
~~~

As of my trying 2.4.2 this is no longer supported.  Anyone who tries to load my 'read_source' gem will get a failure message in require without explaining the specific area of code.

~~~
SyntaxError: /home/danielpclark/dev/read_source/test/support/example.rb:18: syntax error, unexpected '{', expecting keyword_end
ethod :also_attr_method_name { "asdf" }
                              ^
/home/danielpclark/dev/read_source/test/support/example.rb:18: syntax error, unexpected '}', expecting keyword_end
so_attr_method_name { "asdf" }
                              ^
	from (irb):2:in `require_relative'
	from (irb):2
	from /usr/share/rvm/rubies/ruby-2.4.2/bin/irb:11:in `<main>'
~~~

To fix my gem for Ruby 2.4.2 I now have to wrap the method name in parenthesis `()`

~~~ruby
define_method(:some_method_name) { "asdf" }
~~~

And that will work.  But I find this odd as the following will still work in 2.4.2:

~~~ruby
define_method :johny, instance_method(:apple)
~~~

Which is still Seattle.rb style.



-- 
https://bugs.ruby-lang.org/

Unsubscribe: <mailto:ruby-core-request / ruby-lang.org?subject=unsubscribe>
<http://lists.ruby-lang.org/cgi-bin/mailman/options/ruby-core>