[FIX] [?] RE: Automatic selection of '--all--'
Andreas Raab
andreas.raab at gmx.de
Mon Jan 6 20:30:04 UTC 2003
Dean,
The fix looks good and I was _almost_ about to endorse it but there's
one minor oddity: When you change between instance/comment/class then
the '-- all --' category gets selected and we see the class definition
fully selected (noticed on 3.4b).
But besides that it looks really good.
Cheers,
- Andreas
> -----Original Message-----
> From: squeak-dev-admin at lists.squeakfoundation.org
> [mailto:squeak-dev-admin at lists.squeakfoundation.org] On
> Behalf Of Swan, Dean
> Sent: Monday, January 06, 2003 9:14 PM
> To: 'squeak-dev at lists.squeakfoundation.org'
> Subject: [FIX] [?] RE: Automatic selection of '--all--'
>
>
> Hi Everyone!
>
> I hope everybody got to take some time off and enjoy the holiday
> season. I had a two week holiday, but I did manage to look into the
> '-- all --' category issues. I've attached a change set that is the
> distilled results of my investigation.
>
> The behavior that you should get with this change set is as
> follows:
>
> 1) with a system category and a class selected, the message
> category list displays the list of categories, including
> the '-- all --' category.
>
> If no message category is selected, all method selectors
> for the selected class will be displayed in the message
> list pane, and the code pane will display the class
> template for the selected class. The code pane will be
> in 'editClass' mode.
>
> 2) as above, but with any message category selected, including
> the '-- all --' category, but with no method selector
> selected in the message list pane, the new method template
> will be displayed in the code pane and selected. The code
> pane will be in 'newMessage' mode.
>
> 3) Accepting a new method while the '-- all --' category is
> selected will add the new message to the 'as yet
> unclassified'
> category. The 'as yet unclassified' category will be
> created if it doesn't exist.
>
> I have manually tested these changes fairly completely in a
> morphic project and I did some less thorough testing in an MVC
> project as well. Everything I tested behaved as I expected, and
> hopefully the way others would expect as well (i.e. no weird,
> un-helpful error messages, etc.). Sorry, but I didn't write
> any SUnit tests for these changes.
>
> This fix required touching four methods:
>
> METHOD PREVIOUS VERSION
> ------------------------------------ -------------------
> Browser>>classListIndex: nk
> 2/13/2001 13:26
> Browser>>contentsSelection dew
> 7/28/2000 00:44
> Browser>>messageCategoryListIndex: dew
> 7/28/2000 01:13
> Browser>>messageList ccn
> 3/24/1999 10:48
>
> I started with a clean 3.2-4956 image, and I have also tried
> the change
> set on a clean 3.0 final image, and things seem to work properly. If
> anybody is interested in reviewing the history of my work, I can make
> the image and change log available.
>
> I am happy with my fix, as far as I have looked at it. I don't
> know if this has implications for any other tools. Class browsers,
> senders, implementors, and things like that, that I used to "learn"
> the browser and find the places to change still work ok, but I haven't
> made any specific effort to look for other code that might be affected
> by my edits... So, caveat emptor. I would like to see the changes
> subject to some serious testing in other people's day-to-day work to
> see if I missed any problems or more importantly, unintentionally
> broke something.
>
> And an editorial comment on my part: The browser seems to have
> accumulated quite a bit of 'cruft' over the years. There are cases
> where there are methods with different selectors, but the same
> functionality, etc. Being such a central tool to the system, it
> might be worth the effort to seriously over-haul and/or re-build
> the browser from scratch.
>
> I spent a few days mucking around in the browser code, and I
> still don't feel like I really understand it (for whatever that is
> worth). I _feel_ that a simpler design with equivalent functionality
> should be possible. I would be interested in other points of view on
> this.
>
>
> -Dean
>
>
> > -----Original Message-----
> > From: Doug Way [mailto:dway at riskmetrics.com]
> > Sent: Thursday, December 19, 2002 12:03 AM
> > To: squeak-dev at lists.squeakfoundation.org
> > Subject: Re: Automatic selection of '--all--'
> >
> >
> >
> > I agree with Stephane and Andreas that the most
> > straightforward solution
> > is to just show all method names (and the class template)
> > when no method
> > category is selected.
> >
> > If we do this, there are still a couple of minor points:
> >
> > - I assume that we would get rid of the '-- all --' category,
> > since you
> > would already have a way to display all method names. It
> also might
> > make things a little cleaner for the Browser to have one
> less special
> > pseudo-category to deal with.
> >
> > - We would still have the 'no messages' pseudo-category which
> > shows up
> > when a new class is created. So you could still select this
> > category if
> > you want to add new methods which would show up as 'as yet
> > unclassified'.
> >
> > Anyway, 3.4 is almost finalized (in a couple of weeks), so these
> > enhancements will have to wait for 3.5alpha. The current
> > behavior (not
> > including the recent #5137 fix attempt) has existed for a couple of
> > years, so it seems reasonable to wait.
> >
> > If Dean or anyone else wants to try fixing it, that would
> be great.
> > Some of the Browser code can be tricky, but it should be
> doable. :-)
> > Otherwise I might try fixing it in a few weeks.
> >
> > - Doug Way
> >
> >
> > On Wednesday, December 18, 2002, at 04:25 PM, Andreas Raab wrote:
> >
> > > Dean and all,
> > >
> > > There's no reason to flame nor to blame here. This entire
> thread has
> > > been taken out of context of other messages. So let's try
> > to summarize:
> > > There is an apparent problem at this point if you try to add class
> > > variables. This is because there is a pattern match in the browser
> > > trying to recognize the '*subclass:' for class definitions
> > if the '--
> > > all --' category is selected. The proposal has been made to
> > change the
> > > pattern match that it "better recognizes" any attempt to
> > define a class
> > > when you hit accept while '-- all --' is selected.
> > >
> > > Looking at the code it appeared to me that all of this is
> due to the
> > > fact that if the '-- all --' category is selected we may or
> > may not try
> > > to define a class or a message. Since a category is
> selected you may
> > > expect to define a message. But since the '-- all --'
> > category shows the
> > > class definition when selected it is equally reasonable
> > trying to define
> > > a class rather than a message. That's the heart of the problem.
> > >
> > > My proposal was basically recognizing the fact that if a
> category is
> > > selected you should expect to edit a method and not a class
> > definition.
> > > There is nothing wrong with the '-- all --' category
> itself. What is
> > > wrong is the inability to distinguish between "class
> > definition mode"
> > > and "method definition mode" when '-- all --' is selected.
> > One way of
> > > solving this problem would be show all of the selectors even if no
> > > category is selected. This preserves the intent of automatically
> > > selecting the '-- all --' category (namely to give an
> > overview of the
> > > entire protocol of some class) without getting into the trouble of
> > > trying to do magic pattern matches if it is selected. In
> > which case it'd
> > > be very simple: You select a method category, you edit a
> method. You
> > > have no category selected, you edit the class definition.
> > >
> > > That's really all there is to it.
> > >
> > > Cheers,
> > > - Andreas
> >
> >
>
>
More information about the Squeak-dev
mailing list
|