<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>