According to the google code search, about 60% of uses of FILE
are of the form File.dirname(FILE). Ruby 1.9.2 provides
require_relative for this problem; but File.dirname(FILE) is
not always used for requiring ruby scripts, but also for reading
data files. dir helps these cases.

|= Proposal
|
| Kernel#dir
| returns the value of File.dirname(FILE)
|
|According to the google code search, about 60% of uses of FILE
|are of the form File.dirname(FILE). Ruby 1.9.2 provides
|require_relative for this problem; but File.dirname(FILE) is
|not always used for requiring ruby scripts, but also for reading
|data files. dir helps these cases.

According to the google code search, about 60% of uses of FILE
are of the form File.dirname(FILE). Ruby 1.9.2 provides
require_relative for this problem; but File.dirname(FILE) is
not always used for requiring ruby scripts, but also for reading
data files. dir helps these cases.

Wouldn't it be a little confusing to remember that FILE is uppercase and dir is downcase? Doesn't sound very POLS to me...//Magnus Holm
On Wed, Aug 19, 2009 at 16:57, Yutaka HARA <redmine@ruby-lang.org> wrote:

According to the google code search, about 60% of uses of FILE
are of the form File.dirname(FILE). Ruby 1.9.2 provides
require_relative for this problem; but File.dirname(FILE) is
not always used for requiring ruby scripts, but also for reading
data files. dir helps these cases.

I would be for DIR for the ease of writing and because it
resembles FILE, neither would be constants if we take into account
that leading underscore is not a valid character for constants.
But whatever name will be chosen, it would be nice if dir could
take arguments that are passed to File::expand_path.
A possible implementation is:http://github.com/manveru/ramaze/blob/master/lib/ramaze/snippets/object/__dir__.rb

(2) add Kernel#DIR
pros: no new keyword
cons: it should have a lower-case name (like 1.9's method),
because it is not a constant but a method.

(3) add Kernel#dir
pros: no new keyword, and it is clearer than (4) that it has
some associations with FILE.
cons: lacking consistency for FILE

(4) make FILE to the default argument of File.dirname
pros: no new keyword nor new method
cons: it is not clear that 'File.dirname' is expanded to
the path of directory of FILE.

+1 for (1) and (3)
I first felt that DIR is more "natural" to me (because the script directory is something constant).
After a bit thinking, (3) looks fine too (to remember we are calling a function).
I think (2) is a bad mix and (4) does not really improve File.dirname(FILE)

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, whereFILE.dir == File.dirname(FILE).

This solves the need for DIR in a very clean, object oriented way.

Sorry to not be according, but classes for one object and 'FILE.dir'
fear me.
The idea behind is everything but not bad anyway. Paths simply stored in
String doesn't seem very appropriate.

Something like Pathname, or maybe just a Path class would be a better OO
approach I think.
But I'm reluctant to the syntax of 'FILE.meth'

B.D.

P.S.:
Is not Ruby the language where everything is an Object ?
I mean if we can do -1.abs, Path("/dir/file.ext").{basedir,dirname,dir}
looks like a solution

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.
Sorry to not be according, but classes for one object and 'FILE.dir' fear me.The idea behind is everything but not bad anyway. Paths simply stored in String doesn't seem very appropriate.
Something like Pathname, or maybe just a Path class would be a better OO approach I think.But I'm reluctant to the syntax of 'FILE.meth'B.D.P.S.:Is not Ruby the language where everything is an Object ?
I mean if we can do -1.abs, Path("/dir/file.ext").{basedir,dirname,dir} looks like a solution

This is nice but would not be backward compatible with code that depends onFILE 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

Why don't you use Pathname?

note:
Including pathname lib to core is sometimes discussed in core members.
But it is not concrete yet.

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.

Yes, you are right. I tend to blur the distinction between subclassing
and extending objects at runtime in my own thinking. But whichever it
is, I'd rather not see a new type in ruby's semantics just to support
this feature. A new keyword seems so much more straightforward.

A new keyword is less backward-compatible than adding methods to a
string instance (or a string subclass). 1.8 could simply makeFILE's string additionally def dir; File.dirname(self); end and it
would be compatible

Of course, this is mostly academic for me...I'm just bikeshedding.DIR would be fine with me too, or a per-file hash so we don't have
to add future keywords (similar to __SOURCE_LINES)