Senders, Implementors browser - how about a "Sendees" browser?

Senders:
  aMessage -> set of methods (that send aMessage)
Implementors:
  aMessage -> set of methods (that implement aMessage)

Sendees:
  method -> set of messages (AS SENT by THAT method).

Does such a browser exist? It would be useful when browsing a particular
method, rather than repeatedly clicking around in the code pane to
understand more fully a method (as I do).

Selecting from the set of sent messages would either show its code (for
self-sends, known implementor), or show a further list of its implementors
(for non-self-sends, could be many implementors; or if you have RoelTyper or
something fancy installed, could further narrow by type inference).

=========================================
|*method A | messgA1  |implementors of messgA2
| method B |*messgA2  |....
|          |          |....
|          |          |
=========================================
|code pane
|  self messgA1.
|  bar messgA2.
|
============================

It this an OB structure?

Sophie

On 8-Jan-08, at 10:09 PM, itsme213 wrote:
>
> Sendees:
>  method -> set of messages (AS SENT by THAT method).
>
> Does such a browser exist?
Well, we've only had this for a decade or two so it's a new thing that  
may not have been noticed yet.

In the message pane of the browser, popup the menu. In either the  
senders or implementors submenu you'll see a list of all the messages  
sent in the currently selected method so you can see all the senders  
or implementors of the one you choose. The top item in each of the  
submenus is the name of the currently selected method so you can get  
to senders and implementors of that as well.


tim
--
tim Rowledge; [hidden email]; http://www.rowledge.org/tim
Strange OpCodes: XO: Execute Operator

For OB: http://bugs.squeak.org/view.php?id=6847

On Jan 10, 2008 7:28 AM, tim Rowledge <[hidden email]> wrote:


--
Damien Cassou

"tim Rowledge" <[hidden email]> wrote

> Well, we've only had this for a decade or two so it's a new thing that
> may not have been noticed yet.

:-)

> In the message pane of the browser, popup the menu. In either the  senders
> or implementors submenu you'll see a list of all the messages  sent in the
> currently selected method so you can see all the senders  or implementors
> of the one you choose.

But I don't want *all* implementors of the self-send messages in the current
method, I want the self-implementor (current class, ancestor class [or
trait]). Did it do that?

Sophie

Sounds like you want the menu that Tim is describing to appear after
selecting hierarchy implementors.

Zulq

itsme213 wrote:

On Jan 10, 2008, at 8:20 , itsme213 wrote:

Are you aware of the protocol browser (alt-p on a class)?

- Bert -

"Bert Freudenberg" <[hidden email]> wrote in message
>> But I don't want *all* implementors of the self-send messages in  the
>> current
>> method, I want the self-implementor (current class, ancestor class [or
>> trait]). Did it do that?
>
> Are you aware of the protocol browser (alt-p on a class)?

Just looked :-) It does not do the same thing.

A has methods: foo, a1, a2, a3, ...bar
A>>foo
  self bar.
  x baz.

===== The protocol browser shows all Methods in the context of a class, even
when I have selected a specific method. So when I am browsing
  A>>foo and want to see the corresponding
  self bar
I have to scroll the entire list of foo, a1, a2, a3, ...bar and select that
bar.

===== The Sendees Browser shows { SelfSend | MessageSend } in the context of
a method of that class. So when I am browsing
  A>>foo
    I automatically see and can select just 2 items:
     self bar (SelfSend: selecting shows method implementation)
     x baz (MessageSend: selecting shows list of implementors)

I find I am doing this kind of browsing by hand a large % of time.

Thoughts?

Sophie

p.s. Thinking some more about this ... a nice generalization: group sends
not just by (self | non-self) sends, but by [pseudo] variable (though this
info may be more deeply buried):
   self sends - each one leads to 1 Method
   super sends - " "
   instVar-1 sends - each one leads to list of MessageSends
   instVar-2 sends - each one leads to list of MessageSends
   arg1 sends - " "
   arg2 sends - " "
   class sends [?]
     - each leads to 1 Method *if* self class has not been overridden

This could be viewed at the class level (giving a nice typed collaboration
view of that class), or at the method level (giving a typed collaboration
view of that method, where variables could include args).

Type-inferences must make heavy use of this view, so why not me?? Perhaps
this could become a "CollaborationBrowser" or "TypedBrowser".

On 10-Jan-08, at 10:05 AM, itsme213 wrote:
>
> Type-inferences must make heavy use of this view, so why not me??
Types? What are these 'types' of which you write?  This is Smalltalk;  
we don't do types.

tim
--
tim Rowledge; [hidden email]; http://www.rowledge.org/tim
The world will end in 5 minutes.  Please log out.

"tim Rowledge" <[hidden email]> wrote in message
news:[hidden email]...
>
> On 10-Jan-08, at 10:05 AM, itsme213 wrote:
>>
>> Type-inferences must make heavy use of this view, so why not me??
> Types? What are these 'types' of which you write?  This is Smalltalk;  we
> don't do types.

Don't let the word 'Type-inference' or 'TypedBrowser' put you off. Just
think 'Collaboration', as in CRC.

If you look over the description, you will notice that these are not static
types. They are just groupings of message sends per inst-Var, pseudo-var,
etc. as are known 100% correctly to Squeak. They are not classes, groups of
classes, or even message categories.

e.g.
This is my class C.
I implement: #(foo, bar, baz, fooSub)
My instances collaborate by sending:
  #(m1, m2) to my collaborators via instVarA
  #(m1, m5) to my collaborators via instVarB
  #(initialize) to [self via] super
  #(fooSub) to self
  #(classFoo) to my class C
  #(x1, x2, x3, ....) to others via dynamic method params
And within each of my methods #(foo, bar, baz, fooSub)
  here is C>>each method's narrower collaboration ...

Do you think many ST programmers design and think in these terms? I know I
do. I think I would benefit *greatly* from seeing this view on both my own
classes, and from others' packages I want to use.

Sophie

"itsme213" <[hidden email]> wrote in message

I'm on a roll ... so here is a real example of what auto-generated class
documentation could look like following this approach: