Thinking about names and usage...

UserRequest (base class)
"Christoph proposed UserNotification, but notifications can be
dismissed easily, confirmations or choices should not be"
"Also Monticello and other packages already use *Request for the purpose"
InputRequest "accurate, but too general?"
Request "probably too general"
"contrast with WebRequest, for example"
"asynchronous/continuation style:"
(InputRequestSubclass signal)
    eventually: [:response | ... ];
    then: [:response | ...];
    ifRejected:/ifCancelled: [...].
"handling:"
on: InputRequest do: [:request |
request resume:/provide:/answer:/reply:/respond: whatever].

    UserInformation signalWith: 'Looks ok'
    "remains open whether this will be a modal popup or a message in some
kind of notification area"
    on: UserInformation do: [:info | info resume/dismiss/accept/continue
"ok"]
    "but it might also be information about (not for) a user"
    UserNotification signalWith: 'This makes more sense to me here for
inform:'.
    "This is not really a request for information, only for acknowledgement"

    UserConfirmation signal .... "strange because here we want to request
confirmation, not give one"
    UserConfirmation request: 'Does this look better?' "but signal is still
inherited"
    on: UserConfirmation do: [:confirm | "strange again because
the confirmation is yet to be given or denied"]
    UserConfirmRequest signal: 'This looks wordy even though it is already
abbreviated'
    UserConfirmRequest request: 'Double double words'.
    UserConfirmRequest confirm: 'Double double, and the request
shall confirm something??'
    "can be circumvented with a UserConfirmation factory but
then signalling and handling use different class names"
    ConfirmationRequest signal: 'More letters, but looks nicer to
me' trueChoice: #Agreed falseChoice: #Disagreed.
    on: ConfirmationRequest do: [:request |
request resume:/respond:/reply:/answer:/choose: #Agreeable].
    on: ConfirmationRequest do: [:request | request confirm/deny].
    "ConfirmationRequested also possible, but not a noun -- different style"

    MultipleChoiceRequest signal: 'I think it is...' choices: #(Good Bad
Done) labels: #(Yay Nay What)
    "unfortunately the class name is already taken in RefactoringTools"
    ChoiceRequest signal: 'shorter but maybe stranger?' choices: #(Yep Nope)
        MultiResponseRequest signal: 'I like...' responses: #(Cats Dogs
Squeak You)
        "funnily the term 'multiple choice' implies a single answer from a
set of many"
        ConfirmationRequest "or others (see above) could also be a subclass
of multiple choice"
        ClassOrTraitRequest signal: 'Choose your request'.
        (ClassOrTraitRequest fromPattern: '*Class*Request') signal: 'Other
ideas?'
        ClassifierRequest signal: 'Do you prefer UML-speak?'
    DirectoryRequest signal: 'What kinds of other
requests to/from/by/with/... a directory are there?'
    DirectoryRequested signal: 'This might be less ambiguous'
    File/Font/String/Text/Password/Credentials/ObjectRequest/ed signal:
'Likewise' initialAnswer: whatever.
    "Makes me wonder whether UserRequest might imply that a user must be
chosen
    instead of requesting something from users"
    XyzRequestedFromUser signal: 'More explicit purpose, but yet another
naming style'
    "Can there be a protocol to request a certain kind of object from the
user
    or would we really need one subclass for each kind?"
    Xyz requestFromUser: 'Choose your Xyz...'.
    on: Xyz input/userRequest do: [:request | ...].
    InputRequest signal: 'Choose your object' ofKind: Xyz.
    on: InputRequest do: [:request | (request acceptsA/n: Xyz)
ifTrue: [...] ifFalse: [request pass]].
    ...

There is also ProgressInitiationException which does not have a nice name.
It is not a request, but it already has displayProgress:* in UIManager
as defaultAction.
Alternative names:
ProgressInitiation/ed
ProgressStart/ed



Am Fr., 28. Feb. 2020 um 22:11 Uhr schrieb Jakob Reschke <
forums.jakob at resfarm.de>:

> HI,
>
> Unless there is a good reason why handling ProvideAnswerNotification
> is not a good idea in scripted environments, I agree with Chris. I
> would prefer using the existing mechanism to introducing a strange
> synonym for Notification.
>
> Swapping the control flow, like Christoph proposed (user code signals
> the notification and defaultAction is the modal dialog), sounds ok to
> me too. It would also mean that user code does not have to access the
> UIManager singleton. On the other hand, it is less obvious whether
> something is meant to be a UI interaction if the names of the
> Notifications make the code strange to read. For the most basic cases,
> at least there still is Object>>inform:/confirm:/confirm:orCancel:.
>
> Kind regards,
> Jakob
>
>
> Am Mi., 26. Feb. 2020 um 22:41 Uhr schrieb Chris Muller <
> asqueaker at gmail.com>:
> >
> > Hi Marcel,
> >
> >> > especially for this one tiny little thing of a modal alert when
> renaming classes?
> >>
> >> It is a more general issue. There should be no UI invocation code in a
> non-UI part of the system. So, "Transcript showln:." is fine but "self
> inform:" is not. Why? Because those cannot be trapped in scripts, which is
> - for example - unfortunate in automated pipelines such as our CI.
> >
> >
> > Actually, they can.
> >
> >     "example 1"
> >     [ self inform: 'stop everything and pay attention to me!' ] on:
> ProvideAnswerNotification do: [ : noti | noti resume ]     "nil"
> >
> >     "example 2"
> >     [UIManager default request: 'what is the answer?' initialAnswer:
> 'tell me now!' ] on: ProvideAnswerNotification do: [ : noti | noti resume:
> 42 ]      "42 "
> >
> > I assumed this is what the CI jobs were doing.. they're not?
> >
> > I totally share your sentiments about no UI invocation code in the
> domain, and is how I do my own designs, of course, but Squeak chose default
> to being an <<interactive system>>, and requires handlers of
> ProvideAnswerNotification to make it non-interactive, rather than the other
> way around.
> >
> > If you want to flip the above in 5.4 to the normal way -- signaling a
> kind of ProvideAnswerNotification whose defaultAction issues the modal
> popup -- then let's flip them, but it doesn't seem like we need a new layer
> of notification classes just yet.  ProvideAnswerNotification may be
> sufficient.
> >
> > Best,
> >   Chris
> >
> >>
> >>
> >> > What happened to simply opening up a MessageSet on the references
> afterward?
> >>
> >> Still there. Unrelated to this issue. See the end of Browser >>
> #renameClass.
> >>
> >> > Say, why do we need a modal alert at all?
> >>
> >> I agree, that extra check in Class >> #rename: might not be necessary
> and maybe moved to our refactoring tools.
> >>
> >> Best,
> >> Marcel
> >>
> >> Am 26.02.2020 00:21:48 schrieb Chris Muller <asqueaker at gmail.com>:
> >>
> >> -1.  "Notice" is such a generic, common word to steal from all
> applications that might want to create their own, especially for this one
> tiny little thing of a modal alert when renaming classes?  Say, why do we
> need a modal alert at all?  What happened to simply opening up a MessageSet
> on the references afterward?
> >>
> >>  - Chris
> >>
> >>
> >>
> >>
> >>
> >> On Tue, Feb 25, 2020 at 8:17 AM Marcel Taeumel <marcel.taeumel at hpi.de>
> wrote:
> >>>
> >>> Just "Notice"?
> >>>
> >>> Am 25.02.2020 12:11:33 schrieb Eliot Miranda <eliot.miranda at gmail.com
> >:
> >>>
> >>>
> >>>
> >>> On Feb 25, 2020, at 1:40 AM, Marcel Taeumel <marcel.taeumel at hpi.de>
> wrote:
> >>>
> >>> 
> >>> Fixed. BUT: Please take a look at
> >>>
> >>> Kernel-mt.1305
> >>> Tools-mt.941
> >>>
> >>> We need a name! :-)
> >>>
> >>>
> >>> On second thoughts Notice might be a better name.
> >>>
> >>>
> >>> Best,
> >>> Marcel
> >>>
> >>> Am 25.02.2020 10:11:22 schrieb Marcel Taeumel <marcel.taeumel at hpi.de>:
> >>>
> >>> > Maybe it is a sporadic issue?
> >>>
> >>> It is! Related to the ProgressNotification which I accidentially catch
> in Browser >> #renameClass. I wanted to get the UI call out of Class >>
> #rename:.
> >>>
> >>> That progress notification does not appear every time. Only above a
> certain threshold. That's why it appears to be sporadic.
> >>>
> >>> Best,
> >>> Marcel
> >>>
> >>> Am 25.02.2020 09:37:13 schrieb Thiede, Christoph <
> christoph.thiede at student.hpi.uni-potsdam.de>:
> >>>
> >>> I could reproduce it one single time ... Maybe it is a sporadic issue?
> >>>
> >>>
> >>> Best,
> >>>
> >>> Christoph
> >>>
> >>> ________________________________
> >>> Von: Squeak-dev <squeak-dev-bounces at lists.squeakfoundation.org> im
> Auftrag von Taeumel, Marcel
> >>> Gesendet: Dienstag, 25. Februar 2020 09:34:03
> >>> An: John Pfersich via Squeak-dev; Chris Muller
> >>> Betreff: Re: [squeak-dev] 5.3 cannot rename subclasses of Error
> >>>
> >>> Hmm... I can reproduce the bug. Yet, calling "Error2 rename: #Error1"
> from a workspace works fine. Strange.
> >>>
> >>> Best,
> >>> Marcel
> >>>
> >>> Am 25.02.2020 09:16:13 schrieb Thiede, Christoph <
> christoph.thiede at student.hpi.uni-potsdam.de>:
> >>>
> >>> Hi Chris,
> >>>
> >>>
> >>> in a fresh image, I cannot reproduce this. Are you sure the class has
> not been renamed or is it possible that the class list was not updated
> properly?
> >>>
> >>>
> >>> Best,
> >>>
> >>> Christoph
> >>>
> >>> ________________________________
> >>> Von: Squeak-dev <squeak-dev-bounces at lists.squeakfoundation.org> im
> Auftrag von Chris Muller <asqueaker at gmail.com>
> >>> Gesendet: Dienstag, 25. Februar 2020 06:29:00
> >>> An: squeak dev
> >>> Betreff: [squeak-dev] 5.3 cannot rename subclasses of Error
> >>>
> >>> In trunk / 5.3 RC.
> >>>
> >>>    - Make a subclass of Error called MyError1
> >>>    - Make a subclass of Error called MyError2
> >>>    - Delete MyError1
> >>>    - Try to rename MyError2 to MyError1
> >>>
> >>> The last step fails.  No errors or debuggers, but the class is not
> renamed.
> >>>
> >>> Works in 5.2.
> >>>
> >>>
> >>>
> >>
> >
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.squeakfoundation.org/pipermail/squeak-dev/attachments/20200228/ab12c40f/attachment.html>