Open koendehondt opened 5 months ago
Fixing it for the Spec book means fixing it in Pharo 12.
My reasoning was based on what the argument name and the comment express:
enabled: aBooleanOrValuable
"Set if the widget is enabled (clickable or focusable).
This can either be a boolean or a block returning a boolean."
Maybe the argument name and the comment are wrong? After all, does it make sense to pass a block if it is evaluated only once? There is no way to evaluate it again to have an effect on the visual representation. See #1561.
So maybe a presenter with a (toolbar) button should update the button explicitly by sending #enabled: true
or #enabled: false
. That would be fine for me, but then the method above has to be adapted to avoid the confusion.
@estebanlm, @Ducasse and I discussed this issue.
SpAbstractWidgetPresenter>>#enabled:
should not take a block. The argument name and the method comment are wrong.
I would suggest to change the method in SpAbstractWidgetPresenter
to:
enabled: aBoolean
"Set whether the widget is enabled (clickable or focusable)."
enabled := aBoolean
but SpMenuItemPresenter
is a subclass, and it allows a block or a boolean. That is not expressed anywhere, not even in the comment of the SpMenuItemPresenter
class.
SpAbstractWidgetPresenter>>#enabled:
is implemented as:but
SpAbstractWidgetPresenter>>#isEnabled
is implemented as:so that
fails with
NonBooleanReceiver: proceed for truth.
SpAbstractWidgetPresenter>>#enabled:
allows aaBooleanOrValuable
argument, so the implementation ofSpAbstractWidgetPresenter>>#isEnabled
should be:Please note that this bug makes code examples in the Spec book unusable. cc @Ducasse.