Suggestions II

A few more suggestions, hoping they don't bother:

* Copy/paste on in-place editing of class names

* In-place editing of method, variable and category names in the
browser

* There is a bug in the 'default' aspect of a PushButton.  When it is
not selected and I double click on the aspect, I get the check-box
marked, but the icon is still the red cross.  I save, exit, edit the
view again, and the button is still not marked as default.  I should
double click twice in order to get the desired effect

* To see what categories a method belongs to I usually right-click on
it and see the subitems of remove category.  Is there a better, more
correct or more intuitive way?

* I am still learning to use the refactorings, so I may be missing
something already here that already exists.  Suppose I am editing a
method and I write:   self someMethod.
#someMethod still does not exist, so I must open another browser (or
accept the current method first, then use this one) and create
someMethod (having to write the selector again, or pasting it if I
took the precaution of copying it first).  I would like to have a more
automated way of doing this.  Perhaps selecting someMethod and,
through a shortcut, opening another browser positioned in a newly
created stub method with #someMethod as a selector.

* Sometimes I realize I must override a method in a superclass.  I
would be nice if I can make the following:
   + Open a browser showing inherited methods
   + Select a "gray" method  (belonging to some superclass)
   + Right click on it and select #override
   + A new stub method is automatically generated for the current
class with the following content:
      method
        ^ super method

* When subclassing a class that has abstract methods, you could be
warned that the following xxx methods, should be overriden

Best Regards,
Dan

Daniel ,

Just a few random comments.

> * Copy/paste on in-place editing of class names

You can, can't you?  Selecting Refactoring/Rename allows in-place
editing (including copy/paste) of the class name in the class list.  You
can also edit the name (and change the superclass) in the class
definition view..

> * In-place editing of method, variable and category names in the
> browser

Can't agree about editing Method names - what about the arguments?.
Variables are easily edited in the class definition.
Categories - possibly, but I can't see you will gain much?

> * To see what categories a method belongs to I usually right-click on
> it and see the subitems of remove category.  Is there a better, more
> correct or more intuitive way?

Select the method in the Class or System Browser and look at the title
bar?

Having said that I (personally) quite like the way it's done in the
MethodBrowser (hover help shows the categories) and have been thinking
about implementing something similar in the other browsers - possibly
with a bit of extra information about the hoveree.

> * When subclassing a class that has abstract methods, you could be
> warned that the following xxx methods, should be overriden

That's what protocols are for, aren't they?.   IIRC, and I don't use
them very often, it will also offer to insert stub methods for you as
well.

--
Ian

"Daniel Rozzeta" <[hidden email]> wrote in message
news:[hidden email]...
>
> * To see what categories a method belongs to I usually right-click on
> it and see the subitems of remove category.  Is there a better, more
> correct or more intuitive way?

Nope--that's "the way." :) It's not intuitive, but it works fine.

> * I am still learning to use the refactorings, so I may be missing
> something already here that already exists.  Suppose I am editing a
> method and I write:   self someMethod.

One good way is not to implement someMethod at this point. Run your
automated test, and when the debugger gets to this point, it'll tell you
that someMethod doesn't exist. Right-click on that line in the callstack and
check out the Implement menu item. It'll stub in that method for you,
continue execution into it, from where you can actually write the code for
it. This is a weird way to work, but try it. What's cool is that while
you're writing the method, you have full access to its context--all the
objects are set up for your inspection--you just have to make the code work.

> #someMethod still does not exist, so I must open another browser (or
> accept the current method first, then use this one)

That's perfectly acceptable, though. There are a couple of other shortcuts:

One, you can write the method in place, then highlight it and hit Ctrl-M to
extract it to the new method.

Second, you can create a new method by typing over the name of an existing
method (in the method pane). So you can write the code that calls the
method, then modify that pane into the method itself. Helps you remember the
parameters and context.

Third, look at Ian Bartholomew's goodies for his unknown selector goodie,
which will let you know if you use one of these methods by accident. :)

> * Sometimes I realize I must override a method in a superclass.  I
> would be nice if I can make the following:
>    + Open a browser showing inherited methods
>    + Select a "gray" method  (belonging to some superclass)
>    + Right click on it and select #override
>    + A new stub method is automatically generated for the current
> class with the following content:
>       method
> ^ super method

This would all be good (and probably one of us could code it ourselves). Do
be aware that you can drag a superclass method to a subclass to copy it for
overriding.

> * When subclassing a class that has abstract methods, you could be
> warned that the following xxx methods, should be overriden

Have a look at the 'subclass responsibility' method pseudocategory.

"Daniel Rozzeta" <[hidden email]> wrote in message
news:[hidden email]...
> A few more suggestions, hoping they don't bother:
>
> * Copy/paste on in-place editing of class names
>
> * In-place editing of method, variable and category names in the
> browser

I agree with Ian about editing method and category names. You can in fact do
in-place editing of instance variable names.

One thing I love about Dolphin/RB/Smalltalk is how easy it is to rename
stuff to match your understanding.

"Ian Bartholomew" <[hidden email]> wrote in message
news:R0jna.10317$[hidden email]...
>
> > * To see what categories a method belongs to I usually right-click on
> > it and see the subitems of remove category.  Is there a better, more
> > correct or more intuitive way?
>
> Select the method in the Class or System Browser and look at the title
> bar?

I don't care for this, myself. There's too much stuff up there. It confused
me when I first started, and I still never think of looking at the title bar
to find out what category a method belongs to.

Hi Daniel,

> * Sometimes I realize I must override a method in a superclass.  I
> would be nice if I can make the following:
>    + Open a browser showing inherited methods
>    + Select a "gray" method  (belonging to some superclass)
>    ...

What I do is drag and drop the superclass method into the subclass, then
switch to the subclass and edit the method.  The nice things about this are
1) the superclass method's code is right there (sometimes you want to use
some of the code from the inherited method) and 2) the category is
preserved.  Maybe not exactly what you want, but it ain't so bad.

-- Louis

Daniel Rozzeta wrote:

> * To see what categories a method belongs to I usually right-click on
> it and see the subitems of remove category.  Is there a better, more
> correct or more intuitive way?

I once suggested that the "method category" tree could show the currently
applicable categories in bold.  I'd still like to see some sort of direct
feedback like that.  Especially since the category list in the CHB's titlebar
tends to be longer that the titlebar itself...

I admit I haven't tried it to see whether the performance could be made
acceptable.

    -- chris

Daniel

You wrote in message news:[hidden email]...
> A few more suggestions, hoping they don't bother:

Of course not. Feedback is always useful.

> * Copy/paste on in-place editing of class names

Already supported on the context menu, though some of the usual accelerator
keys do
not function, e.g. for Paste Ctrl+V does not work even though Shift+Insert
does. I've never noticed that before, and will record it cosmetic defect for
investigation.

> * In-place editing of method, variable and category names in the
> browser

In-place editing of instance variable names is already supported on the
variables pane. We chose not to do in-place editing of method selectors
because one might want to limit the scope of the rename, or potentially
reorder arguments as well, meaning that a dialog is needed for the general
case. We chose not to use in-place editing for categories because we found
that most commonly we were renaming to another existing category, and so a
choice of these was useful. However this usage pattern may not fit the way
others use the system, and a simpler in-place edit might be more
appropriate?

> * There is a bug in the 'default' aspect of a PushButton.  When it is
> not selected and I double click on the aspect, I get the check-box
> marked, but the icon is still the red cross.  I save, exit, edit the
> view again, and the button is still not marked as default.  I should
> double click twice in order to get the desired effect

I can't reproduce this on Windows XP. There was, however, a bug in the
default button handling in D5 which is fixed in D5.1, and this may be
related (see #1166 in
http://www.object.arts.dial.pipex.com/Lib/Downloads/5.1RC/ReleaseNotes51.htm
).

> * To see what categories a method belongs to I usually right-click on
> it and see the subitems of remove category.  Is there a better, more
> correct or more intuitive way?

Just look at the title bar of the browser when the method is selected. The
categories are listed there.

My answer to that would be "don't worry about it". Either wait until you hit
a DNU error while running your tests, and let the debuggier do the work of
implementing a stub for you. Or you could just save the method you are
editing, and then just overwrite that with the text of the new/missing
method and save again.

> * Sometimes I realize I must override a method in a superclass.  I
> would be nice if I can make the following:
>    + Open a browser showing inherited methods
>    + Select a "gray" method  (belonging to some superclass)
>    + Right click on it and select #override
>    + A new stub method is automatically generated for the current
> class with the following content:
>       method
> ^ super method

It would be nice to have an override command, though probably I'd be
inclined to have the stub body raise an error rather than do a supersend.
Probably, though, this is just my aversion to supersends showing through.

In the meantime you can achieve something close to what you want by
displaying inherited methods in the browser, and then dragging the greyed
superclass method you want to override and dropping it over the class you
are browsing, this will create a copy of it in the class, replacing the
greyed method in the list. This sounds complicated, but actually its pretty
natural and easy to do.

>
> * When subclassing a class that has abstract methods, you could be
> warned that the following xxx methods, should be overriden

The Code Mentor in D6 will do this. For D5 Steve Waring has an add-on:

    http://www.dolphinharbor.org/dh/projects/goodies/smallLintBrowser.html

Regards

Blair

I wrote:

> I once suggested that the "method category" tree could show the
> currently applicable categories in bold.  I'd still like to see some
> sort of direct feedback like that.[...]
>
> I admit I haven't tried it to see whether the performance could be
> made acceptable.

It was bound to happen...

I've just hacked together a very rough implementation that "fades" the names of
all categories (including the intermediate categories that are "branches" of
the category tree) that are not applicable to the currently selected method.

I think it works very well, and -- having tried it -- that it'd be a useful
improvement to the base image.

I found that it was a little sluggish on my machine if I just faded categories
naively, so I added a cache of "applicable categories" to the CHB subclass, and
I refresh the cache when the selected method changes.

It's very small, so I'll attach the package in case anyone wants to give it a
try.

    -- chris

=============== "CU Class Browser 2.pac" ===============
| package |
package := Package name: 'CU Class Browser 2'.
package paxVersion: 0;
 basicComment: ''.


package classNames
 add: #ClassBrowserShell2;
 yourself.

package binaryGlobalNames: (Set new
 yourself).

package globalAliases: (Set new
 yourself).

package allResourceNames: (Set new
 yourself).

package setPrerequisites: (IdentitySet new
 add: '..\..\..\Program Files\Dolphin Smalltalk 5.0\Object
Arts\Dolphin\IDE\Base\Development System';
 add: '..\..\..\Program Files\Dolphin Smalltalk 5.0\Object
Arts\Dolphin\Base\Dolphin';
 yourself).

package!

"Class Definitions"!

ClassBrowserShell subclass: #ClassBrowserShell2
 instanceVariableNames: 'applicableCategories'
 classVariableNames: ''
 poolDictionaries: ''
 classInstanceVariableNames: ''!

"Global Aliases"!


"Loose Methods"!

"End of package definition"!

"Source Globals"!

"Classes"!

ClassBrowserShell2 guid: (GUID fromString:
'{A5C5605B-A553-46DA-A84E-A122C1A7975A}')!
ClassBrowserShell2 comment: ''!
!ClassBrowserShell2 categoriesForClass!Unclassified! !
!ClassBrowserShell2 methodsFor!

fadeCategory: aCategory
 "private -- answer whether we should de-emphasise the representation of the
given method category"

 ^ (applicableCategories includes: aCategory) not.!

initialize

 applicableCategories := IdentitySet new.
 super initialize.
!

onMethodCategorized: aCompiledMethod

 super onMethodCategorized: aCompiledMethod.
 self refreshApplicableCategories.!

onMethodSelected
 "Private - The method selected within the receiver has changed"

 self refreshApplicableCategories.
 super onMethodSelected.
!

onViewOpened

 super onViewOpened.
 categoriesPresenter view customDrawBlock: [:ctx | self ownerDrawCategory: ctx.
ctx := nil].!

ownerDrawCategory: anNMTVCUSTOMDRAW
 "private -- called when Windows wants us to fill in the given NMTVCUSTOMDRAW
object
 for an item in the method category pane"

 | category color |

 category := anNMTVCUSTOMDRAW item.
 category isNil ifTrue: [^ self].

 color := anNMTVCUSTOMDRAW forecolor.

 (self fadeCategory: category) ifTrue: [color := color fadedBy:
ClassBrowserAbstract grayedMethodFadeFactor].

 anNMTVCUSTOMDRAW forecolor: color.
!

refreshApplicableCategories

 | tree intermediates |

 "keep cache of all relevant categories (otherwise
 the owner draw category tree is noticably sluggish)"
 applicableCategories := self method
     ifNil: [IdentitySet new]
     ifNotNil: [:it | it categories].

 "add in intermediate categories too"
 tree := categoriesPresenter model.
 intermediates := IdentitySet new.
 applicableCategories do: [:each | intermediates addAll: (tree allParentsOf:
each)].
 applicableCategories addAll: intermediates.

 categoriesPresenter view invalidate.
! !
!ClassBrowserShell2 categoriesFor: #fadeCategory:!helpers!private! !
!ClassBrowserShell2 categoriesFor: #initialize!initializing!private! !
!ClassBrowserShell2 categoriesFor: #onMethodCategorized:!event
handling!private! !
!ClassBrowserShell2 categoriesFor: #onMethodSelected!event handling!private! !
!ClassBrowserShell2 categoriesFor: #onViewOpened!event handling!public! !
!ClassBrowserShell2 categoriesFor: #ownerDrawCategory:!helpers!private! !
!ClassBrowserShell2 categoriesFor: #refreshApplicableCategories!event
handling!private! !

!ClassBrowserShell2 class methodsFor!

displayOn: aStream
 "Append, to aStream, a String whose characters are a representation of the
receiver as a user
 would want to see it."

 aStream nextPutAll: 'Class Browser 2'!

initialize
 "private -- class initialization.
  self initialize.
 "

 | icon |

 "there must be a better way of doing this"
 self initializeOptionFlags.
 self wordWrapComment: self superclass wordWrapComment.
 self wordWrapDefinition: self superclass wordWrapDefinition.
 self defaultShowInheritedMethods: self superclass defaultShowInheritedMethods.
 self defaultFilterObjectMethods: self superclass defaultFilterObjectMethods.

 "add ourself to the 'Extra tools' folder"
 icon := SmalltalkSystemIcon show: self description: self displayString.
 SmalltalkSystem current addAdditionalToolsFolderIcon: icon.

 "add ourself to the 'Dolphin Options' set"
 SmalltalkSystem registerTool: self.
!

uninitialize
 "private -- class-side deinitialisation.
  self uninitialize.
 "

 | icon |

 "remove ourself from the 'Extra tools' folder"
 icon := SmalltalkSystemIcon show: self description: self displayString.
 SmalltalkSystem current removeSystemFolderIcon: icon.

 "remove ourself from the 'Dolphin Options' set"
 SmalltalkSystem unregisterTool: self.
! !
!ClassBrowserShell2 class categoriesFor: #displayOn:!displaying!public! !
!ClassBrowserShell2 class categoriesFor: #initialize!initializing!private! !
!ClassBrowserShell2 class categoriesFor: #uninitialize!initializing!private! !

"Binary Globals"!

"Resources"!

Blair,

> We chose not to use in-place editing for
> categories because we found that most commonly we were renaming to
> another existing category, and so a choice of these was useful.

While we're on the subject.  Currently, adding a new category to a method takes
two operations, one to bring up the list of existing categories, and then
another to get to the new category dialog.  Could you (not in 5.1, obviously)
add a "new category" option directly to the category pull-right menu, please ?

> However this usage pattern may not fit the way others use the system,
> and a simpler in-place edit might be more appropriate?

Not for me.  I rarely rename categories anyway.

    -- chris

Hi,
Since I´ve been away for some days and the thread already has a few
messages, I'll try to respond all of them in this one (sorry if I mix
who said what ;o)

First of all, let me make this clear.  Some of my comments here were
suggestions for improvements, while others just cosmetic ones.  In
other words, it is not that you couldn't do this or that, but just
suggested what seemed to me a better/shorter/clearer way to do
something.

Ian wrote:
> You can, can't you?  Selecting Refactoring/Rename allows in-place
> editing (including copy/paste) of the class name in the class list.

As Blair later mentioned, the usual shortcut keys don't work.  That's
what I meant.  I heavily use Ctrl+V, Ctrl+X and Ctrl+C, didn't think
of trying the Shift+XXX alternatives

> Can't agree about editing Method names - what about the arguments?.

OK, it is not a complete solution.  But for restricted cases it is
useful for my working style.

> Variables are easily edited in the class definition

Right but, what is wrong with an alternative?
Not all of us use the same working patterns.  Adding some alternative
ways that are intuitive and don't collide with other still seems
useful to me.

> Categories - possibly, but I can't see you will gain much?

Not much, just a little.  But again, what is wrong with that?  It is a
small cosmetic suggestion.

> Select the method in the Class or System Browser and look at the title bar

I din't realize this before.  I wonder why.  May be because it is not
"local", nor intuitive.  Don't really like having to look at the title
bar.  I like Chris Uppal solution much better.


> That's what protocols are for, aren't they?

OK.  That is the second time I get caught by this.  Since I still
never used them I haven't thought about it.  May be it is about time
to take a look at them.



Mark Wilden wrote:
> One good way is not to implement someMethod at this point.
> Run your automated test, and when the debugger gets to this point

I know you can do this, but I don't work that way.
While programming at this point, I do know that this someMethod
doesn't exist, I do know that I want to write and also know what to
put in it.  Why waiting till the debugger makes that for me.
In other words I have an idea and am quickly coding to get it done, I
don't want to interrupt that flow and lose context.

Blair wrote:
> My answer to that would be "don't worry about it". Either wait until you hit
> a DNU error while running your tests

Why wait?  I know what to do right away.


> you can create a new method by typing over the name of an existing
> method (in the method pane). So you can write the code that calls the
> method, then modify that pane into the method itself. Helps you remember the
> parameters and context.

Yes, that is what I always do.  It just occured to me that a simple
keystroke opening a browser with a stub method would be a nicer way


>> * When subclassing a class that has abstract methods, you could be
>> warned that the following xxx methods, should be overriden

> Have a look at the 'subclass responsibility' method pseudocategory.

I am not sure on what you mean.
If I understand you correctly, after subclassing you need to check for
subclass responsibility category on the superclass.  But this will not
work since it may not be redefining a subclassResponsibility method of
an upper class.
Besides, you are making me take an extra step that I tend do forget.
A warning dialog when creating a subclass (with an option for creating
stubs methods) seems a viable and appealing (at least for me) help.


> You can in fact do in-place editing of instance variable names.

You are right.  I wonder why I said you can't.  Aha, because what it
doesn't work just as Class Names do, e.g., when you click on it and
wait some seconds without moving the mouse, you can in-place edit it
(agreed, it is not all that important).


Regards,
Dan

Daniel Rozzeta wrote:

[re: method categories]
> > Select the method in the Class or System Browser and look at the
> > title bar
>
> I din't realize this before.  I wonder why.  May be because it is not
> "local", nor intuitive.  Don't really like having to look at the title
> bar.  I like Chris Uppal solution much better.

I'm glad somebody liked it.  I was wondering why nobody responded at all, I'd
been hoping for at least a "yeuch!".  That addition is, BTW, now a permanent
part of my image, and I've configured it as my default CHB.

For everybody else: it probably depends to some extent on your way of working
(and also on the size of your screen), but for me there often isn't *room* to
display all the categories in the titlebar.

[re: assisted generation of stub methods]
> > One good way is not to implement someMethod at this point.
> > Run your automated test, and when the debugger gets to this point
>
> I know you can do this, but I don't work that way.
> While programming at this point, I do know that this someMethod
> doesn't exist, I do know that I want to write and also know what to
> put in it.  Why waiting till the debugger makes that for me.
> In other words I have an idea and am quickly coding to get it done, I
> don't want to interrupt that flow and lose context.

I hadn't understood what you meant when you first posted.  Now that I've caught
up, I agree with you.  I don't code-in-the-debugger either (I don't like it, as
I've mentioned elsewhere) and would also find some such feature useful.  How
about a menu option to generate stub (Error notYetImplemented) methods, either
as a pull-right from the method menu (like "browse definitions"), or a context
menu from the method source pane (in which case it could use the currently
selected text).  An accelerator, too, would help.

Incidentally, that would work better if methods that were in the "not yet
implemented" category had their own icon (but that would be a useful addition
anyway).

Again, I think I agree.  A tickbox on the class creation dialog to create stubs
for subclassResponsibility methods seems both helpful and harmless.

BTW, Daniel, you do realise that we can add most of these additions ourselves
if we wish ?   Dolphin has fairly good hooks now for adding behaviour to the
system tools (the mod to the class-creation dialog would be more tricky).

    -- chris

"Daniel Rozzeta" <[hidden email]> wrote in message
news:[hidden email]...

The way test-first works, you don't actually interrupt the flow. Typically,
you are writing a little code, testing, then writing some more, etc. The
"testing" part is what gets you to that automatic stub that you want.

For example, let's say I'm working on a method called foo. The only reason
I'm working on that method is because I have a TestCase with a method
testFoo that is failing. foo needs to call bar, so I write that call and
click an icon on the SUnit Browser. Less than a second later, I'm looking at
the stub of bar (which was your request). I'm also looking at bar's actual,
realtime arguments, and I can look at the complete calling context of bar.
Furthermore, all of this is enveloped in a representative test case, so the
context and the arguments are formalized and useful.

Then I write bar, while I'm "swimming" in what bar needs to do.

So here's the short version:

1. Write foo (including call to missing bar)
2. Click a couple of times to run test and bring up debugger in stubbed bar
3. Write bar

It's not for every situation, and it's not for everyone. But give it a try!

> Blair wrote:
> > My answer to that would be "don't worry about it". Either wait until you
hit
> > a DNU error while running your tests
>
> Why wait?  I know what to do right away.

Believe it or not, with the method I suggest above, it really does seem like
you're doing it "right away."

> Yes, that is what I always do.  It just occured to me that a simple
> keystroke opening a browser with a stub method would be a nicer way

However, I think this is a fine idea.

> >> * When subclassing a class that has abstract methods, you could be
> >> warned that the following xxx methods, should be overriden
>
> > Have a look at the 'subclass responsibility' method pseudocategory.
>
> I am not sure on what you mean.

Me neither. Never mind. :)

> Besides, you are making me take an extra step that I tend do forget.
> A warning dialog when creating a subclass (with an option for creating
> stubs methods) seems a viable and appealing (at least for me) help.

Have you checked out Smalllint?

Don't get me wrong--I like most of your suggestions. I'm just suggesting
some workarounds.

The more IDEs I use, the more I realize that each one has a way it wants you
to work. Maybe the best ones have more ways--but not necessarily. So when I
start learning one, I try not to be too judgmental at first, and try to
adapt my habits to it (though previous posts have shown that I have still
brought too many irrelevant ideas to the table). After a while, the
Stockholm Syndrome takes hold and I find myself wondering why things used to
seem weird that are perfectly natural to me now.