From: Caleb Clausen <vikkous@...>
Date: 2010-03-25T03:35:43+09:00
Subject: [ruby-core:28946] Re: [Feature #1961] Kernel#__dir__

On 3/24/10, Charles Oliver Nutter <headius@headius.com> wrote:
> This is nice but would not be backward compatible with code that
> depends on __FILE__ actually being a string (any code that splits on /
> or builds a path with + "../" for example. Maybe a subclass of String?
> Is there a down side to that?
>
> class FileString < String
>    def dir
>      File.dirname(self)
>    end
> end
>
> - Charlie (mobile)
>
> On Mar 23, 2010, at 5:53 PM, Evan Phoenix <evan@fallingsnow.net> wrote:
>
>> Perhaps __FILE__ should not be a raw String object, but rather a
>> CurrentFile object. It could have a #to_str to return the normal
>> String so it can be used like normal, but can provide methods like
>> #dir, where __FILE__.dir == File.dirname(__FILE__).
>>
>> This solves the need for __DIR__ in a very clean, object oriented way.
>>
>> - Evan Phoenix
>
>

Please, please, no. Right now, the fact that we have __ENCODING__ in
1.9 which resolves into a type of object that doesn't even exist in
the 1.8 interpreter means that I'm already having trouble parsing
1.9's __ENCODING__ correctly from within the 1.8 interpreter. I would
much rather have these magic keywords resolve to simple values with
universally available types: String, Integer, Array. It would have
been so much easier for me if __ENCODING__ were just a String.

My preference would be to go ahead and add __DIR__ as a new keyword
with a regular string value. It would be some effort for my lexer and
parser to support this, but not a lot. Having simple, regular,
straightforward semantics for __DIR__ is to my mind much preferable to
making __FILE__ be some kind of almost-a-String-but-not-quite.