From: Charles Oliver Nutter Date: 2010-03-25T15:01:54+09:00 Subject: [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 wrote: > On 3/24/10, Charles Oliver Nutter 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 >> 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. >