There is a description for a method that does not exist presented by
“ri”:
Console Protocol >>>>>
C:\Dokumente und Einstellungen\wolfgang>ri Dir.empty?
------------------------------------------------------------ Dir::empty?
Dir::empty?(path)
Returns whether or not +path+ is empty. Returns false if +path+ is
not a directory, or contains any files other than '.' or '..'.
C:\Dokumente und Einstellungen\wolfgang>irb
irb(main):001:0> Dir::empty?(’./’)
NoMethodError: undefined method `empty?’ for Dir:Class
from (irb):1
irb(main):002:0>
EOCP >>>>>
Produced via OneClickInstaller 186-25 - ruby 1.8.6 (2007-03-13
patchlevel 0) [i386-mswin32]
A little more thought and a review of Ruby-doc shows that it could be
as simple as:
Class Dir
def empty?(path=Dir.pwd)
Dir.entries(path).empty?
end
end
again.
Then take your own advice about thinking first and then writing, friend.
No offense taken, I know I’m not the only one who writes something
and posts quickly because there are other things to do.
I wasn’t trying to give a 100% perfect solution, just a quick example
idea of what could be done.
Lack of the end token would be caught by the interpreter and the OP
would notice or learn from it anyway.
everybody forgets an end here and there.
As for hidden files, well that’s somebody else’s problem, isn’t it?
Depending on point of view, a directory only containing hidden files
could be considered empty!
So whether or not those files are important depends on the program’s
needs.
In that case, hidden or not should be an optional argument with a
default.
That said, though we really have to ask what is meant by empty?
Directories on many platforms contain hidden files or hidden
symlinks. I think that calls for more than one method definition to
handle those respective distinctions.
hidden_files_in_dir?(path_to_dir)
symlinks_in_dir?(path_to_dir)
As is often the case, d.a.b. has the most concise solution…
On Aug 12, 3:01 pm, “Wolfgang Nádasi-donner” [email protected]
wrote:
Returns whether or not +path+ is empty. Returns false if +path+ is
not a directory, or contains any files other than '.' or '..'.
C:\Dokumente und Einstellungen\wolfgang>irb
irb(main):001:0> Dir::empty?(‘./’)
NoMethodError: undefined method `empty?’ for Dir:Class
from (irb):1
irb(main):002:0>
You’re picking up Dir.empty? from win32-dir, which ships with the one-
click installer. In order to use it, you have to require it first.
On Aug 12, 3:01 pm, “Wolfgang N�dasi-donner” [email protected]
wrote:
Returns whether or not +path+ is empty. Returns false if +path+ is
not a directory, or contains any files other than '.' or '..'.
C:\Dokumente und Einstellungen\wolfgang>irb
irb(main):001:0> Dir::empty?(‘./’)
NoMethodError: undefined method `empty?’ for Dir:Class
from (irb):1
irb(main):002:0>
You’re picking up Dir.empty? from win32-dir, which ships with the one-
click installer. In order to use it, you have to require it first.
On Aug 14, 11:33 am, “Wolfgang Nádasi-donner” [email protected]
wrote:
from (irb):1
=> false
Unfortunately it is not visible in the ri output where the method comes
from.
That’s an excellent point Wolfgang. There ought to be a way within ri
for a user to distinguish between a core method and a method added on
by a 3rd party library. I haven’t double checked the ri options, but I
don’t think there’s a way.
If not, we should probably discuss (here or on ruby-core) if it’s
feasible and, if so, what the output should look like.
Or, we could collectively decide that, when modifying core classes, we
should stick a tag of some sort on the method doc itself, either so
that it shows up literally in the output, or something rdoc can latch
onto. For example, the actual comments look like this:
Returns whether or not +path+ is empty. Returns false if +path+
is not a directory, or contains any files other than ‘.’ or ‘…’.
def self.empty?(path)
…
end
Perhaps I should add this at the bottom of each comment?
On Aug 14, 11:33 am, “Wolfgang Nádasi-donner” [email protected]
wrote:
end
Perhaps I should add this at the bottom of each comment?
library: win32-dir
Dunno. What do people think?
I think that’s a hack solution to the problem. It might be a good idea
since getting rdoc/ri fixed will take a lot of time, but the proper
solution is as you say: We need rdoc and ri to be fixed to properly
note what file/library a method was defined (and redefined) in.
I’m not (yet) volunteering to do any of the spec or implementation
work for this, but I’m on the verge. Proper documentation is a near
passion of mine, and although my latest solution (years old now - http://phrogz.net/ObjJob/) doesn’t address this particular concern, I
would love to see and/or do some serious work to make auto-generated
documentation:
Include information on what file you need to add
Optionally show/hide inherited methods
Optionally list ‘attributes’ among methods
Handle method redefinitions, including documentation from both.
I’m quite disturbed that (last time I checked) http://www.ruby-doc.org/core
includes classes modules and methods from stdlib. Clearly that
shouldn’t be the case (right), and is related to this.
That’s an excellent point Wolfgang. There ought to be a way within ri
for a user to distinguish between a core method and a method added on
by a 3rd party library. I haven’t double checked the ri options, but I
don’t think there’s a way.
If not, we should probably discuss (here or on ruby-core) if it’s
feasible and, if so, what the output should look like.
I believe this is a known problem. (Known, at least, on the ruby-doc
list, and I think discussed on ruby-talk before)
Assorted libraries that ship with Ruby and alter core classes (for
example, Yaml) end up having their methods listed with the default
methods of core classes (for example, look at the rdocs for Array; it
lists ‘to_yaml’ as a method.)
end
Perhaps I should add this at the bottom of each comment?
library: win32-dir
Dunno. What do people think?
It may be a reasonable quick fix, though long term ri and rdoc need to
be re-written to stop producing broken docs.
–
James B.
“The use of anthropomorphic terminology when dealing with
computing systems is a symptom of professional immaturity.”
That’s an excellent point Wolfgang. There ought to be a way within ri
for a user to distinguish between a core method and a method added on
by a 3rd party library. I haven’t double checked the ri options, but I
don’t think there’s a way.
ri --system
$ ri Rake::Task -f simple
Class: Rake::Task
[…]
$ ri --system Rake::Task -f simple
Nothing known about Rake::Task
I’m quite disturbed that (last time I checked) RDoc Documentation
includes classes modules and methods from stdlib. Clearly that
shouldn’t be the case (right), and is related to this.
Quite true. Every so often people write to me to complain/inquire about
that; I don’t have a good response other than, “That’s how RDoc was
written.” And I don’t know of a good, automated solution to fixing that
on ruby-doc so that the generated docs make more sense.
I’ve wondered if custom .document files might help, but have not found
time to experiment.
Another question I get is, “Why are there two places to look for API
docs, instead of a single RDoc path where each class or lib page simply
tells you what you need to use it?”
Ruby Central has in the past offered funding to people or groups for
writing this or that cool or interesting code. I’d like to see that $$
offered to people (i.e. Ryan D. et al) to fix RDoc and ri.
It’s a non-trivial task but well worth community funding.
That’s an excellent point Wolfgang. There ought to be a way within ri
for a user to distinguish between a core method and a method added on
by a 3rd party library. I haven’t double checked the ri options, but I
don’t think there’s a way.
ri --system
$ ri Rake::Task -f simple
Class: Rake::Task
[…]
$ ri --system Rake::Task -f simple
Nothing known about Rake::Task
It helps in this case, but if some parts of the standard library change
core classes, the changes are still listed - example: “ri --system
Array” lists yaml stuff.
