The Inbox: Kernel-ct.1292.mcz

[self model merge]

on: MCMergeResolutionRequest & [:request |

request merger conflicts notEmpty]

do: [:request | request resume: true].

[client unusedBytecode]

on: MessageNotUnderstood

& [:ex | ex receiver == client]

& [:ex | ex message selector == #unusedBytecode]

do: [self error: 'unusedBytecode'].

references := [self resolvePackageSpecReferences: packageSpec gofer: gofer]

on: [self class retryPackageResolution] & (Error , GoferRepositoryError)

do: [:ex | retryCount < 2 ifTrue: [

ex return: #()]

on: [self class retryPackageResolution] & GoferRepositoryError.

Transcript showln: 'gofer repository error: '; show: ex description printString; show: '...ignoring'.

(repositoryError := ex) resume: #()].

Am 03.01.2020 07:43:42 schrieb Jakob Reschke <[hidden email]>:

Note that VA Smalltalk has a legacy approach to exceptions that precedes the ANSI standard. It uses #when:do: in place of #on:do:. (Nowadays it also supports #on:do: but not for old-style exceptions in applications.) Might not a blocker for the proposed nomenclature, but you should at least be aware of it.

<[hidden email]> schrieb am Fr., 3. Jan. 2020, 02:21:

A new version of Kernel was added to project The Inbox:
http://source.squeak.org/inbox/Kernel-ct.1292.mcz

==================== Summary ====================

Name: Kernel-ct.1292
Author: ct
Time: 3 January 2020, 2:21:26.297116 am
UUID: 95936a10-85a4-734e-a10b-0f87290b70f9
Ancestors: Kernel-nice.1291

Proposal: Implement conditional exception handling on blocks. The nomenclature is inspired from usual practice in .NET languages.

For an impression of possible users, have a look at:

        self systemNavigation
                browseMessageList: ((self systemNavigation allCallsOn: #on:do: and: #pass) intersection: (#(ifTrue: ifFalse: ifTrue:ifFalse: ifFalse:ifTrue:) gather: [:sel | self systemNavigation allCallsOn: sel]))
                name: 'Potential users of #on:when:do:'

=============== Diff against Kernel-nice.1291 ===============

Item was added:
+ ----- Method: BlockClosure>>on:when:do: (in category 'exceptions') -----
+ on: exceptionOrExceptionSet when: aPredicate do: handlerAction
+
+       ^ self
+               on: exceptionOrExceptionSet
+               do: [:exception |
+                       (aPredicate value: exception)
+                               ifTrue: [handlerAction cull: exception]
+                               ifFalse: [exception pass]]!

Item was added:
+ ----- Method: BlockClosure>>on:when:ensure: (in category 'exceptions') -----
+ on: exceptionOrExceptionSet when: aPredicate ensure: aBlock
+
+       ^ self
+               on: exceptionOrExceptionSet
+               do: [:exception |
+                       (aPredicate value: exception)
+                               ifTrue: [aBlock value].
+                       exception pass]!

Okay, so you would prefer a different naming?

On the other side, there are many prepositions that have different meanings in different selectors ...

For example, "in:" for Objects expects an evaluable. "in:" for Compilers expects either an environment or a context.

"on:" expects either an exception, or a model, or an event name, or a stream. :)

Personally, I don't really care - each selector in Squeak is only one Cmd + M or Cmd + ArrowRight away from revealing their argument's true names. Smalltalk's complexity is just greater than the complexity of any natural language :-)

Best,

Christoph

Am 09.10.2020 03:15:43 schrieb Chris Muller <[hidden email]>:

Hi Christoph,

Are these equivalent --

On Thu, Jan 2, 2020 at 7:58 PM Thiede, Christoph <[hidden email]> wrote:

Outlook jumbled my message completely. Here the examples again:

[self model merge]
        on: MCMergeResolutionRequest
                & [:request | request merger conflicts notEmpty]
        do: [:request | request resume: true].

equal to:

  [self model merge]

        on: MCMergeResolutionRequest

        do: 

           [:request | request merger conflicts notEmpty

                ifTrue: [request resume: true]

                ifFalse: [request pass] ]

?

 

[client unusedBytecode]
        on: MessageNotUnderstood
                & [:ex | ex receiver == client]
                & [:ex | ex message selector == #unusedBytecode]
        do: [self error: 'unusedBytecode'].

equal to

   [client unusedBytecode]

         on: MessageNotUnderstood

         do:

               [:ex | (ex receiver == client and: [ ex message selector == #unusedBytecode ])

                      ifTrue: [ self error: 'unusedBytecode' ]

                      ifFalse: [ ex pass ] ]

?

Not sure if I fully understood it, but is it just a reformat of the syntax?  Or something more empowering?

 

references := [self resolvePackageSpecReferences: packageSpec gofer: gofer]
        on: [self class retryPackageResolution] & (Error , GoferRepositoryError)
        do: [:ex | retryCount >= 2 ifFalse: [
                ex return: #() ]
        on: [self class retryPackageResolution] & GoferRepositoryError.
                Transcript showln: 'gofer repository error: '; show: ex description printString; show: '...ignoring'.
                (repositoryError := ex) resume: #()]. 

(wait, is that, #on:do:on: ?  I'm confused on this one...)

  - Chris

 

sz := 1024*1024*1024*1024.
self
        should: [Array new: sz]
        raise: OutOfMemory, (Error & [:ex | ex messageText includesSubstring: 'basicNew: with invalid argument']).

Hi Marcel, Hi Chris,

thanks for your feedback. I see your point of complexity, still, I think BlockClosure #& etc. could be a nice concept, but it would rather belong in an own repository (such as Xtreams, for example). 

See Kernel-ct.1292/2 for the next attempt. :-)

> See Kernel-ct.1292/2 for the next attempt. :-)