An alternative to adding arguments to methods would be an exception:

-------------------------------------
     "some event handling method"
     [
         "send message(s) to handle the event"
     ] on: WhatEventTriggeredMe do: [ :ex |
         ex resume: event
     ].
-------------------------------------
     "and where the real work gets done"
     event _ WhatEventTriggeredMe signal.
     (event notNil and: [event shiftPressed]) ifTrue: [
         'behave differently"
     ].

-------------------------------------

Cheers,
Bob

On 5/12/13 9:30 PM, David T. Lewis wrote:
> On Sun, May 12, 2013 at 05:52:32PM -0700, tim Rowledge wrote:
>> On 12-05-2013, at 5:48 PM, "David T. Lewis" <lewis at mail.msen.com> wrote:
>>>
>>> I also tried changing the menu selections to have separate selectors for
>>> case-sensitive and non-case-sensitive versions of the search, and this
>>> works fine. However, I'm not happy with that approach because it will
>>> lead to a cluttered menu if we apply the approach consistently to the
>>> various searches for "source with it", "comments with it", etc.
>>
>> Any reason not to go with
>> doFooblyCaseSensitive: evt shitPressed ?
>>
> Yes, I think that is the right thing to do. So for example instead of having
> "browseMethodsWithSourceString: aString" that checks Sensor shiftPressed, we
> would have "browseMethodsWithSourceString: aString caseSensitive: caseSensitive".
> That's what I did to try out the idea of separate menu selections for case-sensitive
> and non-case-sensitive search, and it works fine.
>
> It would be good to allow the shift state in the event to control the option.
> Maybe that is easy to do, I just haven't actually tried it yet.
>
> Dave
>
>
>

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.squeakfoundation.org/pipermail/squeak-dev/attachments/20130512/0f71959e/attachment.htm