<div dir="ltr"><div dir="ltr">Thinking about names and usage...<br><br>UserRequest (base class)<br>"Christoph proposed UserNotification, but notifications can be<br>dismissed easily, confirmations or choices should not be"<br>"Also Monticello and other packages already use *Request for the purpose"<br>InputRequest "accurate, but too general?"<br>Request "probably too general"<br>"contrast with WebRequest, for example"<br>"asynchronous/continuation style:"<br>(InputRequestSubclass signal)<br>    eventually: [:response | ... ];<br>    then: [:response | ...];</div><div>    ifRejected:/ifCancelled: [...].</div><div dir="ltr">"handling:"<br>on: InputRequest do: [:request | request resume:/provide:/answer:/reply:/respond: whatever].<br><br>    UserInformation signalWith: 'Looks ok'<br>    "remains open whether this will be a modal popup or a message in some kind of notification area"<br>    on: UserInformation do: [:info | info resume/dismiss/accept/continue "ok"]<br>    "but it might also be information about (not for) a user"<br>    UserNotification signalWith: 'This makes more sense to me here for inform:'.<br>    "This is not really a request for information, only for acknowledgement"<br><br>    UserConfirmation signal .... "strange because here we want to request confirmation, not give one"<br>    UserConfirmation request: 'Does this look better?' "but signal is still inherited"<br>    on: UserConfirmation do: [:confirm | "strange again because the confirmation is yet to be given or denied"]<br>    UserConfirmRequest signal: 'This looks wordy even though it is already abbreviated'<br>    UserConfirmRequest request: 'Double double words'.<br>    UserConfirmRequest confirm: 'Double double, and the request shall confirm something??'<br>    "can be circumvented with a UserConfirmation factory but then signalling and handling use different class names"<br>    ConfirmationRequest signal: 'More letters, but looks nicer to me' trueChoice: #Agreed falseChoice: #Disagreed.<br>    on: ConfirmationRequest do: [:request | request resume:/respond:/reply:/answer:/choose: #Agreeable].<br>    on: ConfirmationRequest do: [:request | request confirm/deny].<br>    "ConfirmationRequested also possible, but not a noun -- different style"<br><br>    MultipleChoiceRequest signal: 'I think it is...' choices: #(Good Bad Done) labels: #(Yay Nay What)<br>    "unfortunately the class name is already taken in RefactoringTools"<br>    ChoiceRequest signal: 'shorter but maybe stranger?' choices: #(Yep Nope)<br>        MultiResponseRequest signal: 'I like...' responses: #(Cats Dogs Squeak You)<br>        "funnily the term 'multiple choice' implies a single answer from a set of many"<br>        ConfirmationRequest "or others (see above) could also be a subclass of multiple choice"<br>        ClassOrTraitRequest signal: 'Choose your request'.<br>        (ClassOrTraitRequest fromPattern: '*Class*Request') signal: 'Other ideas?'<br>        ClassifierRequest signal: 'Do you prefer UML-speak?'<br>    DirectoryRequest signal: 'What kinds of other requests to/from/by/with/... a directory are there?'<br>    DirectoryRequested signal: 'This might be less ambiguous'<br>    File/Font/String/Text/Password/Credentials/ObjectRequest/ed signal: 'Likewise' initialAnswer: whatever.<br>    "Makes me wonder whether UserRequest might imply that a user must be chosen<br>    instead of requesting something from users"<br>    XyzRequestedFromUser signal: 'More explicit purpose, but yet another naming style'<br>    "Can there be a protocol to request a certain kind of object from the user<br>    or would we really need one subclass for each kind?"<br>    Xyz requestFromUser: 'Choose your Xyz...'.<br>    on: Xyz input/userRequest do: [:request | ...].<br>    InputRequest signal: 'Choose your object' ofKind: Xyz.<br>    on: InputRequest do: [:request | (request acceptsA/n: Xyz) ifTrue: [...] ifFalse: [request pass]].<br>    ...<br><br>There is also ProgressInitiationException which does not have a nice name.<br>It is not a request, but it already has displayProgress:* in UIManager<br>as defaultAction.<br>Alternative names:<br>ProgressInitiation/ed<br>ProgressStart/ed<br><br></div><br><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">Am Fr., 28. Feb. 2020 um 22:11 Uhr schrieb Jakob Reschke <<a href="mailto:forums.jakob@resfarm.de">forums.jakob@resfarm.de</a>>:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">HI,<br>
<br>
Unless there is a good reason why handling ProvideAnswerNotification<br>
is not a good idea in scripted environments, I agree with Chris. I<br>
would prefer using the existing mechanism to introducing a strange<br>
synonym for Notification.<br>
<br>
Swapping the control flow, like Christoph proposed (user code signals<br>
the notification and defaultAction is the modal dialog), sounds ok to<br>
me too. It would also mean that user code does not have to access the<br>
UIManager singleton. On the other hand, it is less obvious whether<br>
something is meant to be a UI interaction if the names of the<br>
Notifications make the code strange to read. For the most basic cases,<br>
at least there still is Object>>inform:/confirm:/confirm:orCancel:.<br>
<br>
Kind regards,<br>
Jakob<br>
<br>
<br>
Am Mi., 26. Feb. 2020 um 22:41 Uhr schrieb Chris Muller <<a href="mailto:asqueaker@gmail.com" target="_blank">asqueaker@gmail.com</a>>:<br>
><br>
> Hi Marcel,<br>
><br>
>> > especially for this one tiny little thing of a modal alert when renaming classes?<br>
>><br>
>> 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.<br>
><br>
><br>
> Actually, they can.<br>
><br>
>     "example 1"<br>
>     [ self inform: 'stop everything and pay attention to me!' ] on: ProvideAnswerNotification do: [ : noti | noti resume ]     "nil"<br>
><br>
>     "example 2"<br>
>     [UIManager default request: 'what is the answer?' initialAnswer: 'tell me now!' ] on: ProvideAnswerNotification do: [ : noti | noti resume: 42 ]      "42 "<br>
><br>
> I assumed this is what the CI jobs were doing.. they're not?<br>
><br>
> 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.<br>
><br>
> 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.<br>
><br>
> Best,<br>
>   Chris<br>
><br>
>><br>
>><br>
>> > What happened to simply opening up a MessageSet on the references afterward?<br>
>><br>
>> Still there. Unrelated to this issue. See the end of Browser >> #renameClass.<br>
>><br>
>> > Say, why do we need a modal alert at all?<br>
>><br>
>> I agree, that extra check in Class >> #rename: might not be necessary and maybe moved to our refactoring tools.<br>
>><br>
>> Best,<br>
>> Marcel<br>
>><br>
>> Am 26.02.2020 00:21:48 schrieb Chris Muller <<a href="mailto:asqueaker@gmail.com" target="_blank">asqueaker@gmail.com</a>>:<br>
>><br>
>> -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?<br>
>><br>
>>  - Chris<br>
>><br>
>><br>
>><br>
>><br>
>><br>
>> On Tue, Feb 25, 2020 at 8:17 AM Marcel Taeumel <<a href="mailto:marcel.taeumel@hpi.de" target="_blank">marcel.taeumel@hpi.de</a>> wrote:<br>
>>><br>
>>> Just "Notice"?<br>
>>><br>
>>> Am 25.02.2020 12:11:33 schrieb Eliot Miranda <<a href="mailto:eliot.miranda@gmail.com" target="_blank">eliot.miranda@gmail.com</a>>:<br>
>>><br>
>>><br>
>>><br>
>>> On Feb 25, 2020, at 1:40 AM, Marcel Taeumel <<a href="mailto:marcel.taeumel@hpi.de" target="_blank">marcel.taeumel@hpi.de</a>> wrote:<br>
>>><br>
>>> <br>
>>> Fixed. BUT: Please take a look at<br>
>>><br>
>>> Kernel-mt.1305<br>
>>> Tools-mt.941<br>
>>><br>
>>> We need a name! :-)<br>
>>><br>
>>><br>
>>> On second thoughts Notice might be a better name.<br>
>>><br>
>>><br>
>>> Best,<br>
>>> Marcel<br>
>>><br>
>>> Am 25.02.2020 10:11:22 schrieb Marcel Taeumel <<a href="mailto:marcel.taeumel@hpi.de" target="_blank">marcel.taeumel@hpi.de</a>>:<br>
>>><br>
>>> > Maybe it is a sporadic issue?<br>
>>><br>
>>> It is! Related to the ProgressNotification which I accidentially catch in Browser >> #renameClass. I wanted to get the UI call out of Class >> #rename:.<br>
>>><br>
>>> That progress notification does not appear every time. Only above a certain threshold. That's why it appears to be sporadic.<br>
>>><br>
>>> Best,<br>
>>> Marcel<br>
>>><br>
>>> Am 25.02.2020 09:37:13 schrieb Thiede, Christoph <<a href="mailto:christoph.thiede@student.hpi.uni-potsdam.de" target="_blank">christoph.thiede@student.hpi.uni-potsdam.de</a>>:<br>
>>><br>
>>> I could reproduce it one single time ... Maybe it is a sporadic issue?<br>
>>><br>
>>><br>
>>> Best,<br>
>>><br>
>>> Christoph<br>
>>><br>
>>> ________________________________<br>
>>> Von: Squeak-dev <<a href="mailto:squeak-dev-bounces@lists.squeakfoundation.org" target="_blank">squeak-dev-bounces@lists.squeakfoundation.org</a>> im Auftrag von Taeumel, Marcel<br>
>>> Gesendet: Dienstag, 25. Februar 2020 09:34:03<br>
>>> An: John Pfersich via Squeak-dev; Chris Muller<br>
>>> Betreff: Re: [squeak-dev] 5.3 cannot rename subclasses of Error<br>
>>><br>
>>> Hmm... I can reproduce the bug. Yet, calling "Error2 rename: #Error1" from a workspace works fine. Strange.<br>
>>><br>
>>> Best,<br>
>>> Marcel<br>
>>><br>
>>> Am 25.02.2020 09:16:13 schrieb Thiede, Christoph <<a href="mailto:christoph.thiede@student.hpi.uni-potsdam.de" target="_blank">christoph.thiede@student.hpi.uni-potsdam.de</a>>:<br>
>>><br>
>>> Hi Chris,<br>
>>><br>
>>><br>
>>> 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?<br>
>>><br>
>>><br>
>>> Best,<br>
>>><br>
>>> Christoph<br>
>>><br>
>>> ________________________________<br>
>>> Von: Squeak-dev <<a href="mailto:squeak-dev-bounces@lists.squeakfoundation.org" target="_blank">squeak-dev-bounces@lists.squeakfoundation.org</a>> im Auftrag von Chris Muller <<a href="mailto:asqueaker@gmail.com" target="_blank">asqueaker@gmail.com</a>><br>
>>> Gesendet: Dienstag, 25. Februar 2020 06:29:00<br>
>>> An: squeak dev<br>
>>> Betreff: [squeak-dev] 5.3 cannot rename subclasses of Error<br>
>>><br>
>>> In trunk / 5.3 RC.<br>
>>><br>
>>>    - Make a subclass of Error called MyError1<br>
>>>    - Make a subclass of Error called MyError2<br>
>>>    - Delete MyError1<br>
>>>    - Try to rename MyError2 to MyError1<br>
>>><br>
>>> The last step fails.  No errors or debuggers, but the class is not renamed.<br>
>>><br>
>>> Works in 5.2.<br>
>>><br>
>>><br>
>>><br>
>><br>
><br>
</blockquote></div></div>