Forum: Ruby-core [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

Issue #8016 has been updated by naruse (Yui NARUSE).

Category set to core
Status changed from Open to Assigned
Assignee set to matz (Yukihiro Matsumoto)
Target version set to next minor


----------------------------------------
Feature #8016: Alias __FILE__ and __LINE__ as methods
https://bugs.ruby-lang.org/issues/8016#change-37294

Author: wardrop (Tom Wardrop)
Status: Assigned
Priority: Normal
Assignee: matz (Yukihiro Matsumoto)
Category: core
Target version: next minor


=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