From: "wardrop (Tom Wardrop)" Date: 2013-03-05T12:16:35+09:00 Subject: [ruby-core:53134] [ruby-trunk - Feature #8016][Open] Alias __FILE__ and __LINE__ as methods Issue #8016 has been reported by wardrop (Tom Wardrop). ---------------------------------------- Feature #8016: Alias __FILE__ and __LINE__ as methods https://bugs.ruby-lang.org/issues/8016 Author: wardrop (Tom Wardrop) Status: Open Priority: Normal Assignee: Category: Target version: =begin All of the previous issues discussing the new (({Kernel#__dir__})) method (#1961, #3346, #7975), never came to any conclusion regarding the naming inconsistency between the likes of (({__dir__})) and (({__method__})), and the keywords (({__FILE__})) and (({__LINE__})). Should we not add (({__file__})) and (({__line__})) as methods also, and perhaps deprecate the keywords (({__FILE__})) and (({__LINE__})). This would keep it consistant with all the other double-underscore methods. To most developers who perhaps do not know Ruby as intricately as most of the people on this issue tracker, the inconsistency between (({__dir__})) and (({__FILE__})) is not just confusing by name, but the fact that one is a method and one isn't, is doubly confusing. Definitely not principle of least surprise. This needs to be addressed in my opinion, either through deprecation of (({__FILE__})) and (({__LINE__})), or by keeping those keywords and simply creating Kernel method equivalents for the sake of a consistant API. While on the topic, someone also suggested in one of those previous issues, to give (({__dir__})) an optional join argument, so you could do something like this: __dir__('somefile.txt') # => /Users/admin/somefile.txt I'd predict that at least 90% of use cases for (({__dir__})) will involve joining it to another path or filename. I can't see any harm in adding this. The naming inconstancies are my main concern however. This would just be a nice bonus that takes advantage of the fact that (({__dir__})) is a method rather than a keyword. =end -- http://bugs.ruby-lang.org/