A new version of Collections was added to project The Inbox: http://source.squeak.org/inbox/Collections-ct.922.mcz
==================== Summary ====================
Name: Collections-ct.922 Author: ct Time: 7 December 2020, 6:46:19.160326 pm UUID: 633c2dcc-4586-e443-bf03-02ae9ae42ee6 Ancestors: Collections-mt.919
Proposal: Implements #add:put:during: as execution around method on Dictionary. This logic is not absolutely trivial, so I would not like to reimplement it again every time I need to build an execution around setter.
=============== Diff against Collections-mt.919 ===============
Item was added: + ----- Method: Dictionary>>at:put:during: (in category 'accessing') ----- + at: key put: anObject during: aBlock + + | revertBlock assoc | + revertBlock := self + at: key + ifPresent: [:value | [self at: key put: value]] + ifAbsent: [[self removeKey: key]]. + self at: key put: anObject. + assoc := self associationAt: key ifAbsent: [nil]. + ^ aBlock ensure: [ + | newAssoc | + ((newAssoc := self associationAt: key ifAbsent: [nil]) == assoc + and: [newAssoc value = anObject]) + ifTrue: [revertBlock value]]!
On 2020-12-07, at 9:46 AM, commits@source.squeak.org wrote:
A new version of Collections was added to project The Inbox: http://source.squeak.org/inbox/Collections-ct.922.mcz
==================== Summary ====================
Name: Collections-ct.922 Author: ct Time: 7 December 2020, 6:46:19.160326 pm UUID: 633c2dcc-4586-e443-bf03-02ae9ae42ee6 Ancestors: Collections-mt.919
Proposal: Implements #add:put:during: as execution around method on Dictionary. This logic is not absolutely trivial, so I would not like to reimplement it again every time I need to build an execution around setter.
Possibly useful idea for this - instead of altering the original twice, how about copying the dictionary and adding to it, then simply abandoning it?
tim -- tim Rowledge; tim@rowledge.org; http://www.rowledge.org/tim All computers run at the same speed...with the power off.
IIUYC this would make it impossible to keep other changes to the dictionary after leaving the execution around method?
________________________________ Von: Squeak-dev squeak-dev-bounces@lists.squeakfoundation.org im Auftrag von tim Rowledge tim@rowledge.org Gesendet: Montag, 7. Dezember 2020 18:52:58 An: The general-purpose Squeak developers list Betreff: Re: [squeak-dev] The Inbox: Collections-ct.922.mcz
On 2020-12-07, at 9:46 AM, commits@source.squeak.org wrote:
A new version of Collections was added to project The Inbox: http://source.squeak.org/inbox/Collections-ct.922.mcz
==================== Summary ====================
Name: Collections-ct.922 Author: ct Time: 7 December 2020, 6:46:19.160326 pm UUID: 633c2dcc-4586-e443-bf03-02ae9ae42ee6 Ancestors: Collections-mt.919
Proposal: Implements #add:put:during: as execution around method on Dictionary. This logic is not absolutely trivial, so I would not like to reimplement it again every time I need to build an execution around setter.
Possibly useful idea for this - instead of altering the original twice, how about copying the dictionary and adding to it, then simply abandoning it?
tim -- tim Rowledge; tim@rowledge.org; http://www.rowledge.org/tim All computers run at the same speed...with the power off.
On 2020-12-07, at 10:05 AM, Thiede, Christoph Christoph.Thiede@student.hpi.uni-potsdam.de wrote:
IIUYC this would make it impossible to keep other changes to the dictionary after leaving the execution around method?
Absolutely. Depends on what your deeper purpose is.
tim -- tim Rowledge; tim@rowledge.org; http://www.rowledge.org/tim Strange OpCodes: LAG: Load and Garble
I wanted to provide it as a general functionality - you could use this in many situations, for example for adding a process variable temporarily, changing a morphic extension temporarily, or maybe even to adjust a preference temporarily ... Where temporary, just for example, might mean for the duration of a test execution (which, of course, might be debugged, so is not necessarily run as an atomic operation). In all these situations, the entire system needs to be kept running without introducing any unintended sandbox effects. :-)
Best, Christoph ________________________________ Von: Squeak-dev squeak-dev-bounces@lists.squeakfoundation.org im Auftrag von tim Rowledge tim@rowledge.org Gesendet: Montag, 7. Dezember 2020 19:10:11 An: The general-purpose Squeak developers list Betreff: Re: [squeak-dev] The Inbox: Collections-ct.922.mcz
On 2020-12-07, at 10:05 AM, Thiede, Christoph Christoph.Thiede@student.hpi.uni-potsdam.de wrote:
IIUYC this would make it impossible to keep other changes to the dictionary after leaving the execution around method?
Absolutely. Depends on what your deeper purpose is.
tim -- tim Rowledge; tim@rowledge.org; http://www.rowledge.org/tim Strange OpCodes: LAG: Load and Garble
Hmm... Preferences does not expose the dictionary. It is rather an implementation detail. See:
Preferences class >> #setPreference:toValue:
Preferences class >> #setPreference:toValue:during:
Hmm... there are implementations of #at:put: where a "nil" value deletes the key. See:
Morph >> #setProperty:toValue:
Hmm... I am not sure about the returned value. Shouldn't it be the object? Should it the block's last result? Depends on the purpose, I suppose.
Hmm... I would rather not support modifying the dictionary during "aBlock". Similar to #do: etc. in a collection.
What about this implementation? Seems to so "low level":
| hasKey oldValue | self at: key ifPresent: [:v | oldValue := v. hasKey := true]. self at: key put: anObject. ^ aBlock ensure: [ hasKey == true ifTrue: [self at: key put: oldValue] ifFalse: [self removeKey: key]]
Best, Marcel Am 07.12.2020 19:14:30 schrieb Thiede, Christoph christoph.thiede@student.hpi.uni-potsdam.de: I wanted to provide it as a general functionality - you could use this in many situations, for example for adding a process variable temporarily, changing a morphic extension temporarily, or maybe even to adjust a preference temporarily ... Where temporary, just for example, might mean for the duration of a test execution (which, of course, might be debugged, so is not necessarily run as an atomic operation). In all these situations, the entire system needs to be kept running without introducing any unintended sandbox effects. :-) [http://www.hpi.de/]
Best, Christoph Von: Squeak-dev squeak-dev-bounces@lists.squeakfoundation.org im Auftrag von tim Rowledge tim@rowledge.org Gesendet: Montag, 7. Dezember 2020 19:10:11 An: The general-purpose Squeak developers list Betreff: Re: [squeak-dev] The Inbox: Collections-ct.922.mcz
On 2020-12-07, at 10:05 AM, Thiede, Christoph Christoph.Thiede@student.hpi.uni-potsdam.de wrote:
IIUYC this would make it impossible to keep other changes to the dictionary after leaving the execution around method?
Absolutely. Depends on what your deeper purpose is.
tim -- tim Rowledge; tim@rowledge.org; http://www.rowledge.org/tim [http://www.rowledge.org/tim] Strange OpCodes: LAG: Load and Garble
Hi Marcel,
Preferences does not expose the dictionary. It is rather an implementation detail.
Yes, but #setPreference:toValue:during: *could* reuse #at:put:during: instead of reinventing this - though small - wheel. :-)
there are implementations of #at:put: where a "nil" value deletes the key.
Isn't this a completely domain-specific design decision? I think we should look at this at a different level of abstraction.
I would rather not support modifying the dictionary during "aBlock". Similar to #do: etc. in a collection.
But the semantics of an execution-around method do not need to be timeless as mentioned earlier. Imagine a morph that changes its fill style regularly while stepping, and that should be displayed with a different border style while a dialog window is open. In this example, forbidding the manipulation of extensions during aBlock would rule out the use of #at:put:during: ...
What about this implementation? Seems to so "low level":
Might be less efficient (I haven't measured it) but provides better readability. :-)
Best, Christoph ________________________________ Von: Squeak-dev squeak-dev-bounces@lists.squeakfoundation.org im Auftrag von Taeumel, Marcel Gesendet: Dienstag, 8. Dezember 2020 13:34:33 An: squeak-dev Betreff: Re: [squeak-dev] The Inbox: Collections-ct.922.mcz
Hmm... Preferences does not expose the dictionary. It is rather an implementation detail. See:
Preferences class >> #setPreference:toValue: Preferences class >> #setPreference:toValue:during:
Hmm... there are implementations of #at:put: where a "nil" value deletes the key. See:
Morph >> #setProperty:toValue:
Hmm... I am not sure about the returned value. Shouldn't it be the object? Should it the block's last result? Depends on the purpose, I suppose.
Hmm... I would rather not support modifying the dictionary during "aBlock". Similar to #do: etc. in a collection.
What about this implementation? Seems to so "low level":
| hasKey oldValue | self at: key ifPresent: [:v | oldValue := v. hasKey := true]. self at: key put: anObject. ^ aBlock ensure: [ hasKey == true ifTrue: [self at: key put: oldValue] ifFalse: [self removeKey: key]]
Best, Marcel
Am 07.12.2020 19:14:30 schrieb Thiede, Christoph christoph.thiede@student.hpi.uni-potsdam.de:
I wanted to provide it as a general functionality - you could use this in many situations, for example for adding a process variable temporarily, changing a morphic extension temporarily, or maybe even to adjust a preference temporarily ... Where temporary, just for example, might mean for the duration of a test execution (which, of course, might be debugged, so is not necessarily run as an atomic operation). In all these situations, the entire system needs to be kept running without introducing any unintended sandbox effects. :-)
Best, Christoph ________________________________ Von: Squeak-dev squeak-dev-bounces@lists.squeakfoundation.org im Auftrag von tim Rowledge tim@rowledge.org Gesendet: Montag, 7. Dezember 2020 19:10:11 An: The general-purpose Squeak developers list Betreff: Re: [squeak-dev] The Inbox: Collections-ct.922.mcz
On 2020-12-07, at 10:05 AM, Thiede, Christoph Christoph.Thiede@student.hpi.uni-potsdam.de wrote:
IIUYC this would make it impossible to keep other changes to the dictionary after leaving the execution around method?
Absolutely. Depends on what your deeper purpose is.
tim -- tim Rowledge; tim@rowledge.org; http://www.rowledge.org/tim Strange OpCodes: LAG: Load and Garble
Might be less efficient (I haven't measured it) but provides better readability. :-)
Mine is actually faster than yours. ;o)
Imagine a morph that changes its fill style regularly while stepping, and that should be displayed with a different border style while a dialog window is open.
You want to optimize for the functional style around "DialogWindow >> getUserResponse"? I wouldn't do that. Most of Morphic is state-based. Maybe we find a better way for showing dialogs as well. It is tricky to support [CMD]+[Dot] along with nested UI loops.
Best, Marcel Am 08.12.2020 14:19:34 schrieb Thiede, Christoph christoph.thiede@student.hpi.uni-potsdam.de: Hi Marcel,
Preferences does not expose the dictionary. It is rather an implementation detail.
Yes, but #setPreference:toValue:during: *could* reuse #at:put:during: instead of reinventing this - though small - wheel. :-)
there are implementations of #at:put: where a "nil" value deletes the key.
Isn't this a completely domain-specific design decision? I think we should look at this at a different level of abstraction.
I would rather not support modifying the dictionary during "aBlock". Similar to #do: etc. in a collection.
But the semantics of an execution-around method do not need to be timeless as mentioned earlier. Imagine a morph that changes its fill style regularly while stepping, and that should be displayed with a different border style while a dialog window is open. In this example, forbidding the manipulation of extensions during aBlock would rule out the use of #at:put:during: ... [http://www.hpi.de/]
What about this implementation? Seems to so "low level":
Might be less efficient (I haven't measured it) but provides better readability. :-)
Best, Christoph Von: Squeak-dev squeak-dev-bounces@lists.squeakfoundation.org im Auftrag von Taeumel, Marcel Gesendet: Dienstag, 8. Dezember 2020 13:34:33 An: squeak-dev Betreff: Re: [squeak-dev] The Inbox: Collections-ct.922.mcz Hmm... Preferences does not expose the dictionary. It is rather an implementation detail. See:
Preferences class >> #setPreference:toValue:
Preferences class >> #setPreference:toValue:during:
Hmm... there are implementations of #at:put: where a "nil" value deletes the key. See:
Morph >> #setProperty:toValue:
Hmm... I am not sure about the returned value. Shouldn't it be the object? Should it the block's last result? Depends on the purpose, I suppose.
Hmm... I would rather not support modifying the dictionary during "aBlock". Similar to #do: etc. in a collection.
What about this implementation? Seems to so "low level":
| hasKey oldValue | self at: key ifPresent: [:v | oldValue := v. hasKey := true]. self at: key put: anObject. ^ aBlock ensure: [ hasKey == true ifTrue: [self at: key put: oldValue] ifFalse: [self removeKey: key]]
Best, Marcel Am 07.12.2020 19:14:30 schrieb Thiede, Christoph christoph.thiede@student.hpi.uni-potsdam.de: I wanted to provide it as a general functionality - you could use this in many situations, for example for adding a process variable temporarily, changing a morphic extension temporarily, or maybe even to adjust a preference temporarily ... Where temporary, just for example, might mean for the duration of a test execution (which, of course, might be debugged, so is not necessarily run as an atomic operation). In all these situations, the entire system needs to be kept running without introducing any unintended sandbox effects. :-) [http://www.hpi.de/]
Best, Christoph Von: Squeak-dev squeak-dev-bounces@lists.squeakfoundation.org im Auftrag von tim Rowledge tim@rowledge.org Gesendet: Montag, 7. Dezember 2020 19:10:11 An: The general-purpose Squeak developers list Betreff: Re: [squeak-dev] The Inbox: Collections-ct.922.mcz
On 2020-12-07, at 10:05 AM, Thiede, Christoph Christoph.Thiede@student.hpi.uni-potsdam.de wrote:
IIUYC this would make it impossible to keep other changes to the dictionary after leaving the execution around method?
Absolutely. Depends on what your deeper purpose is.
tim -- tim Rowledge; tim@rowledge.org; http://www.rowledge.org/tim [http://www.rowledge.org/tim] Strange OpCodes: LAG: Load and Garble
Hi all,
what is the current state of this proposal? I would love to see this in the Trunk - I'd also be fine with Marcel's optimization from above. :-)
Best, Christoph
----- Carpe Squeak! -- Sent from: http://forum.world.st/Squeak-Dev-f45488.html
Hi Christoph,
On Sat, 8 May 2021, Christoph Thiede wrote:
Hi all,
what is the current state of this proposal? I would love to see this in the Trunk - I'd also be fine with Marcel's optimization from above. :-)
My assumption would be that such method restores the original state once the block has been evaluated. But that's not always the case. Can you explain the logic behind it? (Comments and test cases would probably be helpful there.)
Levente
Hi Levente, hi all,
I think that the former state of the relevant key in the dictionary should be always reverted after evaluating aBlock (even if it has been curtailed). One exception could be newer changes made to this key during aBlock, but this is a question I'm actually not sure about. I have attached an updated changeset that 1) adds a few tests and 2) adds #removeKeyDuring: analogously to #at:put:during:.
Looking forward to your thoughts! :-)
Best,
Christoph
________________________________ Von: Squeak-dev squeak-dev-bounces@lists.squeakfoundation.org im Auftrag von Levente Uzonyi leves@caesar.elte.hu Gesendet: Samstag, 8. Mai 2021 23:30:52 An: The general-purpose Squeak developers list Betreff: Re: [squeak-dev] The Inbox: Collections-ct.922.mcz
Hi Christoph,
On Sat, 8 May 2021, Christoph Thiede wrote:
Hi all,
what is the current state of this proposal? I would love to see this in the Trunk - I'd also be fine with Marcel's optimization from above. :-)
My assumption would be that such method restores the original state once the block has been evaluated. But that's not always the case. Can you explain the logic behind it? (Comments and test cases would probably be helpful there.)
Levente
squeak-dev@lists.squeakfoundation.org