Hi,
FastRI 0.2.1
Ruby 1.8.5
Windows XP
With FastRI (or rather, fri) how do you distinguish a lookup on classes
with identical names and methods (and no namespace to distinguish them)?
For example, I have the Pathname class from the stdlib and my own
Pathname class from the ‘pathname2’ package. If I do ‘fri
Pathname#descend’ I get the documentation from the Pathname class in the
stdlib instead of my own. Is there a way to force the issue?
I tried using the -S and -F options, but I received the following error
(with -S):
Couldn’t open the full-text index:
C:\Documents and Settings\djberge/.fastri-fulltext/full_text.dat
C:\Documents and Settings\djberge/.fastri-fulltext/suffixes.dat
The index needs to be rebuilt with fastri-server -B
Since I’m runnng FastRI as a service, rebuilding the index may be
problematic at the moment. 
But, even if that did work, I presume it
would give me all the results instead of just the one I’m looking for.
Suggestions?
Thanks,
Dan
Daniel B. wrote:
Pathname class from the ‘pathname2’ package. If I do ‘fri
Pathname#descend’ I get the documentation from the Pathname class in the
stdlib instead of my own. Is there a way to force the issue?
Yes, there is. The best solution is to give your own class a different
name.
It is not a good idea to use an existing class name for your own
classes.
Paul L. wrote:
For example, I have the Pathname class from the stdlib and my own
Pathname class from the ‘pathname2’ package. If I do ‘fri
Pathname#descend’ I get the documentation from the Pathname class in the
stdlib instead of my own. Is there a way to force the issue?
Yes, there is. The best solution is to give your own class a different name.
It is not a good idea to use an existing class name for your own classes.
My class is meant as a replacement for the one in the stdlib.
Daniel B. wrote:
With FastRI (or rather, fri) how do you distinguish a lookup on classes
name. It is not a good idea to use an existing class name for your own
classes.
My class is meant as a replacement for the one in the stdlib.
IMHO this is an even better reason to avoid a name collision. You may
eventually create a situation in which people will install your class or
library along with others and not realize that you have allowed a class
name conflict. This can produce an inability to sort out what is going
on,
to determine which class is actually being invoked, from one system to
another, due to differences in paths and other factors that could
produce
different outcomes for what appear to be identical libraries and
installations.
When Mr. Gray, a regular in this newsgroup, decided to replace the
standard
CSV management library with his own, he did not call it “CSV” (the
existing
name), he called it “FasterCSV”. As I understand it, part of the
reasoning
was his wish to clearly identify his own work, part was a wish not to
create a name collision.
This is just my opinion, reasonable people may differ.
On Dec 4, 2006, at 09:35 , Paul L. wrote:
create a name collision.
This is just my opinion, reasonable people may differ.
resolv-replace.rb disagrees with you.
–
Eric H. - [email protected] - http://blog.segment7.net
I LIT YOUR GEM ON FIRE!
Eric H. wrote:
was his wish to clearly identify his own work, part was a wish not to
create a name collision.
This is just my opinion, reasonable people may differ.
resolv-replace.rb disagrees with you.
I am sure many reasonable people will disagree on excellent grounds. But
all
of us have heard cases where same-name collisions occur in circumstances
other than an intentional replacement of one library/class/method with
another.
Last week in this newsgroup, a difficult problem came up that was only
resolved when someone realized that a different “open” was being called
that had been assumed to be the case, in circumstances where there were
multiple methods with that name and no clear way to distinguish them.
Ruby knew exactly what to do with the call, but we fallible mortals
mistakenly assumed we knew which “open” Ruby had chosen.
In the case of redefining an established class method, it is obviously a
feature that can produce mass confusion if not used carefully. I
generally
put such redefinitions in the same source file as the uses of the
redefinition, to minimize confusion, or I use a different name.
Just my opinion.
On Mon, Dec 04, 2006 at 11:47:44AM +0900, Daniel B. wrote:
With FastRI (or rather, fri) how do you distinguish a lookup on classes
with identical names and methods (and no namespace to distinguish them)?
For example, I have the Pathname class from the stdlib and my own
Pathname class from the ‘pathname2’ package. If I do ‘fri
Pathname#descend’ I get the documentation from the Pathname class in the
stdlib instead of my own. Is there a way to force the issue?
What you’re getting is the result of merging the documentation from the
Pathname class in the stdlib and that in the gem package, so you’ll see
methods defined in both, but for a given method only the description
from the
stdlib IIRC (that depends on the way RDoc defines “merging”, which is
not
commutative). Internally, FastRI knows where a class/module/method came
from,
but there’s no way to specify the scope of the search at the moment.
Once that
functionality is exposed, you’ll be able to do
fri --scope pathname2 Pathname
problematic at the moment. 
But, even if that did work, I presume it
would give me all the results instead of just the one I’m looking for.
It should work since fastri-server doesn’t access the full-text index
itself
at the moment. But it would show all the matches (and only the matching
lines,
it doesn’t show full entries).
But, even if that did work, I presume it