Source Tracking System bug discovered when using the Refactoring Browser

I am using David Goriseks Source Tracking System 2.01 and Dolphin 4.01
Professional and it seems to be a bug in ClassBrowserShell>>onViewOpened
which belongs to the STS. When opening the Refactoring Browser, I get the
following error:

ListView does not understand #referee

17:47:21,  den 6 april 2001: 'ListView does not understand #referee'
ListView(Object)>>doesNotUnderstand:
RefactoringBrowserShell(ClassBrowserShell)>>onViewOpened
RefactoringBrowserShell>>onViewOpened
RefactoringBrowserShell(Shell)>>view:
RefactoringBrowserShell class>>create:
RefactoringBrowserShell class(Presenter class)>>create
RefactoringBrowserShell class(Presenter class)>>show
RefactoringBrowserShell class(SmalltalkToolShell class)>>show
[] in RefactoringBrowserShell class>>initialize
[] in SmalltalkSystemIcon>>openIn:
BlockClosure>>ifCurtailed:

and so on.

The bug is in the code after the comment "added by David Gorisek for Source
Tracking System".

By changing the line:

(self view viewNamed: 'methods' ifNone: []) referee contextMenu

to:

(self view viewNamed: 'methods' ifNone: []) contextMenu

the problem seems to be solved. But perhaps there are some side effects that
I am unaware of, perhaps for those not using the RB?


Regards,

Mikael Svane
[hidden email]

>But perhaps there are some side effects that
>I am unaware of, perhaps for those not using the RB?


Answering my own questions...

If the RB isn't installed, the code:

(self view viewNamed: 'methods' ifNone: [])

answers a ReferenceView and #referee is of course needed, but with the RB
installed it instead answers a ListView. Obviously this isn't a bug in the
STS. I guess that the easiest solution would be if the RB had the following
loose method:

ListView>>referee
    ^ self


Regards,

Mikael
[hidden email]

Mikael,

> If the RB isn't installed, the code:
>
> (self view viewNamed: 'methods' ifNone: [])
>
> answers a ReferenceView and #referee is of course needed, but with the RB
> installed it instead answers a ListView. Obviously this isn't a bug in the
> STS. I guess that the easiest solution would be if the RB had the
following
> loose method:
>
> ListView>>referee
>     ^ self

I'm a big fan of dispatching things through loose methods added to existing
classes, but, #referee is not a message I'd choose to add in this way.  It's
not pretty, but, a test on type in the troublesome code might be more
appropriate, or, one could define a different selector for the purpose.

With that said, perhaps OA would be willing to define View>>referee to
answer self, in effect, allowing one to always assume a reference is
present.  I've hit this kind of problem (alternating "normal" and reference
views) myself, and it would be nice to have a clean way to smooth it over.

Have a good one,

Bill

--
Wilhelm K. Schwab, Ph.D.
[hidden email]

what version of the dolphin are you using? most of the testing was done on
version 3.

"Mikael Svane" <[hidden email]> wrote in message
news:9al40g$5qs6g$[hidden email]... following

I'm using 4.01 PL1 and STS 2.01.

/Mikael

Ok, I'll add the type checking in the next release. However this is not a
bug, it's simply that RB and CHB do not behave the same. And since the
#referee message send was added by Blair at CS@OOPSLA when we were porting
STS from 4.0 beta1 to beta3 one could hardly call it a bug.

Best regards,

David


Bill Schwab <[hidden email]> wrote in message
news:9al60h$5orie$[hidden email]...
> Mikael,
>
> > If the RB isn't installed, the code:
> >
> > (self view viewNamed: 'methods' ifNone: [])
> >
> > answers a ReferenceView and #referee is of course needed, but with the
RB
> > installed it instead answers a ListView. Obviously this isn't a bug in
the
> > STS. I guess that the easiest solution would be if the RB had the
> following
> > loose method:
> >
> > ListView>>referee
> >     ^ self
>
> I'm a big fan of dispatching things through loose methods added to
existing
> classes, but, #referee is not a message I'd choose to add in this way.
It's
> not pretty, but, a test on type in the troublesome code might be more
> appropriate, or, one could define a different selector for the purpose.
>
> With that said, perhaps OA would be willing to define View>>referee to
> answer self, in effect, allowing one to always assume a reference is
> present.  I've hit this kind of problem (alternating "normal" and
reference

>I'm using 4.01 PL1 and STS 2.01.


Sorry, that should be STS 2.02.

/Mikael

>Ok, I'll add the type checking in the next release. However this is not a
>bug, it's simply that RB and CHB do not behave the same. And since the
>#referee message send was added by Blair at CS@OOPSLA when we were porting
>STS from 4.0 beta1 to beta3 one could hardly call it a bug.
>


When I started this thread, I thought that the bug was in the STS. After
having examined the problem, I found that it was caused by the RB answering
a ListView instead of a ReferenceView and therefore I suggested that the
change would be added to the RB, since it doesn't behave like the normal
CHB.

However I understand why Bill doesn't like my suggestion, but I don't think
that the STS should be changed. It can't be David's responsibility to
predict where other packages might change the behaviour of the different
browsers and add type checking everywhere where it might be needed, in my
opinion.

Perhaps Bill's suggestion (#referee added to View by OA) is the best one,
especially if others have encountered this problem before?


Best regards,

Mikael
[hidden email]