[lnkForumImage]
TotalShareware - Download Free Software
Confronta i prezzi di migliaia di prodotti.
Asp Forum
 Home | Login | Register | Search 


 

Forums >

comp.lang.ruby

Re: FastRI, handling identical class names and methods

Daniel Berger

12/4/2006 12:27:00 PM


Paul Lutus wrote:
> Daniel Berger wrote:
>
> > 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?
>
> 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
3 Answers

Paul Lutus

12/4/2006 5:33:00 PM

0

Daniel Berger wrote:

>
> Paul Lutus wrote:
>> Daniel Berger wrote:
>>
>> > 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?
>>
>> 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.

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.

--
Paul Lutus
http://www.ara...

Eric Hodel

12/4/2006 6:58:00 PM

0

On Dec 4, 2006, at 09:35 , Paul Lutus wrote:
> Daniel Berger wrote:
>> My class is meant as a replacement for the one in the stdlib.
>
> 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.

resolv-replace.rb disagrees with you.

--
Eric Hodel - drbrain@segment7.net - http://blog.se...

I LIT YOUR GEM ON FIRE!

Paul Lutus

12/4/2006 7:10:00 PM

0

Eric Hodel wrote:

> On Dec 4, 2006, at 09:35 , Paul Lutus wrote:
>> Daniel Berger wrote:
>>> My class is meant as a replacement for the one in the stdlib.
>>
>> 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.
>
> 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.

--
Paul Lutus
http://www.ara...