Hi! I realized that because

Morphic>>findA: aClass
��� "Return the first submorph of the receiver that is descended from the given class. Return nil if there is no such submorph. Clients of this code should always check for a nil return value so that the code will be robust if the user takes the morph apart."

��� ^self submorphs
��� ��� detect: [:p | p isKindOf: aClass]
��� ��� ifNone: [nil]

we can simply replace MenuMorph>>doButtonAction by

MenuMorph>>doButtonAction
��� "Do the receiver's inherent button action.� A MenuMorph that is a wrapper for a single menu-item -- pass it on the the item. We should enhance or think what to do with a MenuMorph with multiple items"

��� self menuItems notEmpty ifTrue:[ self menuItems first doActionButton ]

I'll look at that a few minutes to give a little fix :).

On Fri, Aug 6, 2010 at 6:28 PM, St�phane Ducasse <stephane.ducasse@inria.fr> wrote:

On Aug 6, 2010, at 4:54 AM, Guillermo Polito wrote:

> Hi, removing some findA: message sendings

Yes yes yes!!!
We only need a few of them.

> i've found:
>
> MenuMorph>>doButtonAction
> � � "Do the receiver's inherent button action. �Makes sense for the kind of MenuMorph that is a wrapper for a single menu-item -- pass it on the the item"
>
> � � (self findA: MenuItemMorph) ifNotNil: [:aMenuItem | aMenuItem doButtonAction]
>
>
> And for me it doesn't make sense :). �Even the comment doesn't make sense, because it isn't considering the case where a MenuMorph has multiple MenuItemMorph s.
>
> What should be done in cases like that? �If it's my code, i should be tempted to delete it or maybe to deprecate it. �And I'm really upset because it is a very difficult thing to verify not to break too much other things. �So, what is the "official policy" about this cases? :P �I don't like to leave it as it is...

Get one or more scenario where the code behavior normally
and rewrite so that it does not use findA:
What I suggest is that you start with the easy findA: and publish often so that we integrate them in the system
and slowly we learn and fix the ugly.

Stef



>
> Cheers,
> Guille
> _______________________________________________
> Pharo-project mailing list
> Pharo-project@lists.gforge.inria.fr
> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project


_______________________________________________
Pharo-project mailing list
Pharo-project@lists.gforge.inria.fr
http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project