# FastRI, handling identical class names and methods **URL:** \ **Category:** Ruby\ **Created:** [December 4, 2006, 3:48am UTC](https://www.ruby-forum.com/t/fastri-handling-identical-class-names-and-methods/78216 "2006-12-04T03:48:11Z")\ **Posts on this page:** 7\ **Page:** 1
**Author:** ![danielb](https://www.ruby-forum.com/letter_avatar_proxy/v4/letter/d/c57346/32.png) [@danielb](https://www.ruby-forum.com/u/danielb)\ **Post date:** [December 4, 2006, 3:48am UTC](https://www.ruby-forum.com/t/fastri-handling-identical-class-names-and-methods/78216/1 "2006-12-04T03:48:11Z")
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 ---
**Author:** ![danielb](https://www.ruby-forum.com/letter_avatar_proxy/v4/letter/d/c57346/32.png) [@danielb](https://www.ruby-forum.com/u/danielb)\ **Post date:** [December 4, 2006, 8:52am UTC](https://www.ruby-forum.com/t/fastri-handling-identical-class-names-and-methods/78216/2 "2006-12-04T08:52:34Z")
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. ---
**Author:** ![danielb](https://www.ruby-forum.com/letter_avatar_proxy/v4/letter/d/c57346/32.png) [@danielb](https://www.ruby-forum.com/u/danielb)\ **Post date:** [December 4, 2006, 1:31pm UTC](https://www.ruby-forum.com/t/fastri-handling-identical-class-names-and-methods/78216/3 "2006-12-04T13:31:07Z")
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. - Dan ---
**Author:** ![danielb](https://www.ruby-forum.com/letter_avatar_proxy/v4/letter/d/c57346/32.png) [@danielb](https://www.ruby-forum.com/u/danielb)\ **Post date:** [December 4, 2006, 6:35pm UTC](https://www.ruby-forum.com/t/fastri-handling-identical-class-names-and-methods/78216/4 "2006-12-04T18:35:55Z")
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. ---
**Author:** ![danielb](https://www.ruby-forum.com/letter_avatar_proxy/v4/letter/d/c57346/32.png) [@danielb](https://www.ruby-forum.com/u/danielb)\ **Post date:** [December 4, 2006, 8:00pm UTC](https://www.ruby-forum.com/t/fastri-handling-identical-class-names-and-methods/78216/5 "2006-12-04T20:00:31Z")
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. - removed\_email\_address@domain.invalid - [http://blog.segment7.net](http://blog.segment7.net) I LIT YOUR GEM ON FIRE! ---
**Author:** ![danielb](https://www.ruby-forum.com/letter_avatar_proxy/v4/letter/d/c57346/32.png) [@danielb](https://www.ruby-forum.com/u/danielb)\ **Post date:** [December 4, 2006, 8:16pm UTC](https://www.ruby-forum.com/t/fastri-handling-identical-class-names-and-methods/78216/6 "2006-12-04T20:16:35Z")
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. ---
**Author:** ![danielb](https://www.ruby-forum.com/letter_avatar_proxy/v4/letter/d/c57346/32.png) [@danielb](https://www.ruby-forum.com/u/danielb)\ **Post date:** [December 4, 2006, 2:45pm UTC](https://www.ruby-forum.com/t/fastri-handling-identical-class-names-and-methods/78216/7 "2006-12-04T14:45:16Z")
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).