[ruby-core:28975] Re: [Feature #1961] Kernel#__dir__

Actually, I proposed that it be a String subclass, so it actually  
would still be a String, but with some additional logic that people  
tend to rewrite themselves anyway.

- Charlie (mobile)

On Mar 24, 2010, at 1:35 PM, Caleb Clausen <[e-mail]> wrote:

> On 3/24/10, Charles Oliver Nutter <[e-mail]> 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 <[e-mail]>  
>> 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.
>