Hi,
I want to test for the existence of a file. I’d expect to find a method
like File.exists, but there isn’t one. There must be a way to do this.
Does anyone know how?
Daniel Carrera | OpenPGP fingerprint:
Graduate TA, Math Dept | 6643 8C8B 3522 66CB D16C D779 2FDD 7DAC 9AF7 7A88
UMD (301) 405-5137 | http://www.math.umd.edu/~dcarrera/pgp.html
FileTest.exists?( file )
On Sun, Jun 22, 2003, Daniel Carrera wrote:
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1Hi,
I want to test for the existence of a file. I’d expect to find a method
like File.exists, but there isn’t one. There must be a way to do this.
–
Pierre Baillet
Il vaut mieux pomper même s’il ne se passe rien que risquer
qu’il se passe quelque chose de pire en ne pompant pas.
Devise Shadok
Sorry, stupid question. It is “File.exists?”.
FEATURE REQUEST: Add “File.exists?” to ri. Currently ri does not list
File.exists? under the File class methods.
On Sun, Jun 22, 2003 at 02:33:25AM +0900, Daniel Carrera wrote:
Hi,
I want to test for the existence of a file. I’d expect to find a method
like File.exists, but there isn’t one. There must be a way to do this.Does anyone know how?
–
Daniel Carrera | OpenPGP fingerprint:
Graduate TA, Math Dept | 6643 8C8B 3522 66CB D16C D779 2FDD 7DAC 9AF7 7A88
UMD (301) 405-5137 | http://www.math.umd.edu/~dcarrera/pgp.html
Daniel Carrera | OpenPGP fingerprint:
Graduate TA, Math Dept | 6643 8C8B 3522 66CB D16C D779 2FDD 7DAC 9AF7 7A88
UMD (301) 405-5137 | http://www.math.umd.edu/~dcarrera/pgp.html
Daniel Carrera wrote:
FEATURE REQUEST: Add “File.exists?” to ri. Currently ri does not list
File.exists? under the File class methods.
Because it’s mixed in from FileTest. I don’t show things like ‘map’ for
all the classes that mix in Enumerable also.
In an ideal world, I suppose I should follow my way up the inheritance
tree, but that would make method lists very long.
Cheers
Dave
In an ideal world, I suppose I should follow my way up the inheritance
tree, but that would make method lists very long.
To take that to its absurd conclusion, if ri reported NO methods, the list would
be very short indeed.
IMHO, ri should follow all the way up; if the information there isn’t complete,
it seems much less useful. (Javadoc, for example, at least lists what methods a
class is inheriting so you know at least what’s there (and where to look) even
if there isn’t a full-on description.)
No?
Eiffel has the concept of “flat” class views, where the class hierarchy
is flattened so that all methods (inherited and direct) are visible.
Perhaps we could add a --flat option to ri.
On Sat, 2003-06-21 at 14:28, Dave Thomas wrote:
Daniel Carrera wrote:
FEATURE REQUEST: Add “File.exists?” to ri. Currently ri does not list
File.exists? under the File class methods.Because it’s mixed in from FileTest. I don’t show things like ‘map’ for
all the classes that mix in Enumerable also.In an ideal world, I suppose I should follow my way up the inheritance
tree, but that would make method lists very long.
“Beware of bugs in the above code; I have only proved it correct,
not tried it.” – Donald Knuth (in a memo to Peter van Emde Boas)
irb could have a --verbose option to turn this behaviour on.
On Sun, Jun 22, 2003 at 04:53:01AM +0900, Mike Campbell wrote:
In an ideal world, I suppose I should follow my way up the inheritance
tree, but that would make method lists very long.To take that to its absurd conclusion, if ri reported NO methods, the list would
be very short indeed.IMHO, ri should follow all the way up; if the information there isn’t complete,
it seems much less useful. (Javadoc, for example, at least lists what methods a
class is inheriting so you know at least what’s there (and where to look) even
if there isn’t a full-on description.)No?
Daniel Carrera | OpenPGP fingerprint:
Graduate TA, Math Dept | 6643 8C8B 3522 66CB D16C D779 2FDD 7DAC 9AF7 7A88
UMD (301) 405-5137 | http://www.math.umd.edu/~dcarrera/pgp.html
Mike Campbell wrote:
In an ideal world, I suppose I should follow my way up the inheritance
tree, but that would make method lists very long.To take that to its absurd conclusion, if ri reported NO methods, the list would
be very short indeed.
ri reports the methods in a class or module, so I’m not sure I see this
as being a valid end-point in a thought experiment. However…
IMHO, ri should follow all the way up; if the information there isn’t complete,
it seems much less useful. (Javadoc, for example, at least lists what methods a
class is inheriting so you know at least what’s there (and where to look) even
if there isn’t a full-on description.)No?
Well, try it for yourself. Let’s say you wanted the methods for a Proc
object. Here’s ri’s output
[], arity, binding, call, new, to_proc, yield
and here is what you’re asking for:
(Note that both of these are slightly out of date wrt 1.8: ‘yield’ no
longer exists as a method of Proc)
It just seemed to me when I was writing ri that the former was a clearer
picture of the essence of ‘Proc’. However, I’m very open to suggestions
here.
Cheers
Dave
Well, try it for yourself. Let’s say you wanted the methods for a Proc
object. Here’s ri’s output
[], arity, binding, call, new, to_proc, yield
and here is what you’re asking for:
== === =~ id send arity binding call class clone display
dup eql? equal? extend freeze frozen? hash id inspect instance_eval
instance_of? instance_variable_get instance_variable_set
instance_variables is_a? kind_of? method methods nil? object_id
private_methods protected_methods public_methods respond_to? send
singleton_methods taint tainted? to_a to_proc to_s type untaint yield(Note that both of these are slightly out of date wrt 1.8: ‘yield’ no
longer exists as a method of Proc)It just seemed to me when I was writing ri that the former was a clearer
picture of the essence of ‘Proc’. However, I’m very open to suggestions
here.
2 suggestions (not of mine) that have come up on the list both indicate a flag
to get the latter display you show.
For me, I’d prefer something like the javadoc thing; you get your “this class
only” list, then a list of what this class gets as a result of inherited/mixed
in things. Ideally, 1 list per superclass/included class so you can see where
to go to get more information on those methods.
If the expanded list is displayed by default or by a flag to ri
doesn’t matter to me, but I would like to see the two separated.
So, I would get something like:
On Sunday, 22 June 2003 at 22:10:39 +0900, Dave Thomas wrote:
Well, try it for yourself. Let’s say you wanted the methods for a Proc
object. Here’s ri’s output
[], arity, binding, call, new, to_proc, yield
and here is what you’re asking for:
== === =~ id send arity binding call class clone display
dup eql? equal? extend freeze frozen? hash id inspect instance_eval
instance_of? instance_variable_get instance_variable_set
instance_variables is_a? kind_of? method methods nil? object_id
private_methods protected_methods public_methods respond_to? send
singleton_methods taint tainted? to_a to_proc to_s type untaint yieldIt just seemed to me when I was writing ri that the former was a clearer
picture of the essence of ‘Proc’. However, I’m very open to suggestions
here.
, arity, binding, call, new, to_proc, yield
“They’re unfriendly, which is fortunate, really. They’d be difficult
to like.”
– Avon
Or even as in Java: (output for Ruby 1.8)
On 24 Jun 2003 at 12:15, Jim Freeze wrote:
On Sunday, 22 June 2003 at 22:10:39 +0900, Dave Thomas wrote:
(… long list of methods …)
It just seemed to me when I was writing ri that the former was a clearer
picture of the essence of ‘Proc’. However, I’m very open to suggestions
here.If the expanded list is displayed by default or by a flag to ri
doesn’t matter to me, but I would like to see the two separated.
(… two lists …)
–
Regards,
Pit
Nice. How about a separator for every class/module? So ‘ri File
–name-of-flag-that-turns-on-superclass-following’ would look like this:
<general description for File goes here, like it normally would>
On Tue, 24 Jun 2003 12:15:12 +0900 Jim Freeze jim@freeze.org wrote:
If the expanded list is displayed by default or by a flag to ri
doesn’t matter to me, but I would like to see the two separated.
So, I would get something like:
, arity, binding, call, new, to_proc, yield
== === =~ id send class clone display
dup eql? equal? extend freeze frozen? hash id inspect instance_eval
instance_of? instance_variable_get instance_variable_set
instance_variables is_a? kind_of? method methods nil? object_id
private_methods protected_methods public_methods respond_to? send
singleton_methods taint tainted? to_a to_s type untaint
class: File < IO
atime, atime, basename, chmod, chmod, chown, chown, ctime, ctime,
delete, dirname, expand_path, extname, flock, fnmatch, fnmatch?,
ftype, join, lchmod, lchmod, lchown, lchown, link, lstat, lstat,
mtime, mtime, new, open, path, readlink, rename, size, split, stat,
symlink, truncate, truncate, umask, unlink, utime
class: IO
<<, binmode, clone, close, close_read, close_write, closed?, each,
each_byte, each_line, eof, eof?, fcntl, fileno, flush, for_fd,
foreach, fsync, getc, gets, ioctl, isatty, lineno, lineno=, new,
pid, pipe, popen, pos, pos=, print, printf, putc, puts, read, read,
readchar, readline, readlines, readlines, reopen, rewind, seek,
select, stat, sync, sync=, sysopen, sysread, sysseek, syswrite,
tell, to_i, to_io, tty?, ungetc, write
module: Enumerable
all?, any?, collect, detect, each_with_index, entries, find,
find_all, grep, include?, inject, map, max, member?, min,
partition, reject, select, sort, sort_by, to_a, zip
…or something like that. Should we show Object? I think not, as this would
clutter things up even more.
Jason Creighton