Re: [Pharo-dev] Issues 12717 and 12684
On 29 Jan 2014, at 7:41 , Sean P. DeNigris s...@clipperadams.com wrote: Nicolas Cellier wrote So maybe PropertyBinding could do it... Where is the binding? It's purpose is announcing changes. I don't get how binding epxresses that intent. What am I missing? No, its purpose is to *hold* a *value*, in a single place through which multiple users can access it. That it also informs those users when said value changes, so they can reflect any change as they see fit, is, albeit crucial, a secondary feature. It *is* by no means a *variable*, nor does it *react* to anything in and of itself. Cheers, Henry signature.asc Description: Message signed with OpenPGP using GPGMail
Re: [Pharo-dev] Issues 12717 and 12684
On 30 Jan 2014, at 11:02 , Henrik Johansen henrik.s.johan...@veloxit.no wrote: nor does it *react* to anything in and of itself. And by that I mean, announcing that something happens, is, by my definition, a passive role. The active role, are the subscribers of the announcement, who respond by carrying out some action. (in other words, *react*) Cheers, Henry signature.asc Description: Message signed with OpenPGP using GPGMail
Re: [Pharo-dev] Issues 12717 and 12684
On 30 Jan 2014, at 11:02 , Henrik Johansen henrik.s.johan...@veloxit.no wrote: That it also informs those users when said value changes, so they can reflect any change as they see fit, is, albeit crucial, a secondary feature. And by that I mean, a ValueHolder would fulfill its main role just the same in an architecture where users poll, rather than get notified. …I really should hold of pushing that send button a bit more often :) Cheers, Henry signature.asc Description: Message signed with OpenPGP using GPGMail
Re: [Pharo-dev] Issues 12717 and 12684
I have nothing invested in the new name, but I think the current discussion is off-track... Henrik Sperre Johansen wrote No, its purpose is to *hold* a *value* in a single place That's the purpose of a regular variable. Nothing is gained storage-wise Henrik Sperre Johansen wrote through which multiple users can access it. This also has nothing to do with access. If you have access to the wrapper, you could have access to the underlying value Henrik Sperre Johansen wrote It *is* by no means a *variable*, nor does it *react* to anything in and of itself. My argument with ValueHolder is that it doesn't give a clue as to the only added value it provides over a regular variable, which is change notification. You mentioned that you could poll, but then why not just poll an accessor to a regular variable? Then, when I googled it, I found on wikipedia that value holder is already in use in computer science regarding lazy initialization… So that was out. You're relating to these names as if we are inventing something new. ReactiveVariable came as a result of googling to see if there is a computer science term that applies to what we're actually doing. Reactive variables from FRP seemed close. So I think this is where we're at: - Ben already changed it on the Spec side, which is why I objected to I don't like it. To ask him to go through the work to change it again, there should be qualitative benefit. If we do find a valid argument, MonitoredValue seems closest so far to revealing the intention, but even that is thin. It can be monitored, but doesn't have to be. It's more like MonitorableValue (pseudo-English, not an actual suggestion). - reactive variable seems to be an existing term, so let's not argue as to whether we think the world should change the term, but only if the way it's already used accurately describes our situation here. - Cheers, Sean -- View this message in context: http://forum.world.st/Issues-12717-and-12684-tp4739761p4740370.html Sent from the Pharo Smalltalk Developers mailing list archive at Nabble.com.
Re: [Pharo-dev] Issues 12717 and 12684
On 30 January 2014 14:21, Sean P. DeNigris s...@clipperadams.com wrote: I have nothing invested in the new name, but I think the current discussion is off-track... Henrik Sperre Johansen wrote No, its purpose is to *hold* a *value* in a single place That's the purpose of a regular variable. Nothing is gained storage-wise Henrik Sperre Johansen wrote through which multiple users can access it. This also has nothing to do with access. If you have access to the wrapper, you could have access to the underlying value Henrik Sperre Johansen wrote It *is* by no means a *variable*, nor does it *react* to anything in and of itself. My argument with ValueHolder is that it doesn't give a clue as to the only added value it provides over a regular variable, which is change notification. You mentioned that you could poll, but then why not just poll an accessor to a regular variable? Then, when I googled it, I found on wikipedia that value holder is already in use in computer science regarding lazy initialization… So that was out. You're relating to these names as if we are inventing something new. ReactiveVariable came as a result of googling to see if there is a computer science term that applies to what we're actually doing. Reactive variables from FRP seemed close. The C# Reactive Extensions library would call this an Observable. You Subscribe to an Observable, and in this case when the value wrapped by the Observable changes, subscribers learn of the change. frank So I think this is where we're at: - Ben already changed it on the Spec side, which is why I objected to I don't like it. To ask him to go through the work to change it again, there should be qualitative benefit. If we do find a valid argument, MonitoredValue seems closest so far to revealing the intention, but even that is thin. It can be monitored, but doesn't have to be. It's more like MonitorableValue (pseudo-English, not an actual suggestion). - reactive variable seems to be an existing term, so let's not argue as to whether we think the world should change the term, but only if the way it's already used accurately describes our situation here. - Cheers, Sean -- View this message in context: http://forum.world.st/Issues-12717-and-12684-tp4739761p4740370.html Sent from the Pharo Smalltalk Developers mailing list archive at Nabble.com.
Re: [Pharo-dev] Issues 12717 and 12684
2014-01-29 Sean P. DeNigris s...@clipperadams.com Nicolai Hess wrote And I don't like the name either. I would prefere Binding or ValueBinding. Guys, I don't love the name either, but can we do a little better than I don't like it. The purpose of ValueHolder's existence was to notify changes to its value. A reactive variable, from FRP, kinda-sorta does that. How does Binding = 'I will notify of changes to my value'?! - Cheers, Sean -- View this message in context: http://forum.world.st/Issues-12717-and-12684-tp4739761p4740024.html Sent from the Pharo Smalltalk Developers mailing list archive at Nabble.com. We don't need to argue about names, ReactiveVariable is not wrong, I just don't like it:-) I just wanted to emphase on the missing discussion. Doing this change after the Pharo3 release may be more difficult than now. Even if it is a bit late. So, I am happy we have at least both. (We should try to force the use of the new name.) (Binding or PropertyBinding is how it is called in QTs QML) Nicolai
Re: [Pharo-dev] Issues 12717 and 12684
2014-01-29 Nicolai Hess nicolaih...@web.de 2014-01-29 Sean P. DeNigris s...@clipperadams.com Nicolai Hess wrote And I don't like the name either. I would prefere Binding or ValueBinding. Guys, I don't love the name either, but can we do a little better than I don't like it. The purpose of ValueHolder's existence was to notify changes to its value. A reactive variable, from FRP, kinda-sorta does that. How does Binding = 'I will notify of changes to my value'?! - Cheers, Sean -- View this message in context: http://forum.world.st/Issues-12717-and-12684-tp4739761p4740024.html Sent from the Pharo Smalltalk Developers mailing list archive at Nabble.com. We don't need to argue about names, ReactiveVariable is not wrong, I just don't like it:-) I just wanted to emphase on the missing discussion. Doing this change after the Pharo3 release may be more difficult than now. Even if it is a bit late. So, I am happy we have at least both. (We should try to force the use of the new name.) (Binding or PropertyBinding is how it is called in QTs QML) Nicolai Binding already has another semantic in Smalltalk. It's a kind of value holder used for shared variables (global/class/pool variables). It is not equipped with events mechanism nor mutex. So maybe PropertyBinding could do it...
Re: [Pharo-dev] Issues 12717 and 12684
Nicolas Cellier wrote So maybe PropertyBinding could do it... Where is the binding? It's purpose is announcing changes. I don't get how binding epxresses that intent. What am I missing? - Cheers, Sean -- View this message in context: http://forum.world.st/Issues-12717-and-12684-tp4739761p4740176.html Sent from the Pharo Smalltalk Developers mailing list archive at Nabble.com.
Re: [Pharo-dev] Issues 12717 and 12684
2014-01-29 Sean P. DeNigris s...@clipperadams.com Nicolas Cellier wrote So maybe PropertyBinding could do it... Where is the binding? It's purpose is announcing changes. I don't get how binding epxresses that intent. What am I missing? Binding is so generic... The question is what do you bind? With any value holder, you somehow bind several dependents of a value... With the annoucement, your intention is to monitor a change of value. MonitoredBinding? MonitoredValue? - Cheers, Sean -- View this message in context: http://forum.world.st/Issues-12717-and-12684-tp4739761p4740176.html Sent from the Pharo Smalltalk Developers mailing list archive at Nabble.com.
Re: [Pharo-dev] Issues 12717 and 12684
Ben I still think that it would have been good to discuss the valueHolder changes in Spec before doing it. Because it broke the tools of people that used Spec like martin and clement as well as the documentation ignaccio wrote. We should be cautious about other people too. Stef On 27 Jan 2014, at 20:08, Sven Van Caekenberghe s...@stfx.eu wrote: Are the compatible ? Does one have to come before the other ? Are they both needed ? I think we should drop https://pharo.fogbugz.com/f/cases/12717/ReactiveVariable-NewValueHolder and integrate https://pharo.fogbugz.com/f/cases/12684/NewValueHolder-Enhancements For at least two reasons: - I added hooks for Spec to continue working with the slice I proposed (otherwise no more Spec fix until the release) - I do not have to review it :P Ok maybe the second point is not that relevant LOL Just that I am sure that the fix I proposed works well with Spec. And I an pretty sure the other will break it :) I was not aware of another case related to this. It is not flagged Spec nor my name, so there is no way for me to guess it exists. Ben
Re: [Pharo-dev] Issues 12717 and 12684
On 28 Jan 2014, at 00:57, Sven Van Caekenberghe s...@stfx.eu wrote: Yes, I just tested: UserManager instVarNamed: 'default' put: nil. UserManager initialize. fixes the release tests. in 30 728 I have to go to bed though ;-) Thx! Sven On 28 Jan 2014, at 00:54, Benjamin benjamin.vanryseghem.ph...@gmail.com wrote: I think the fix https://pharo.fogbugz.com/default.asp?12711 might need to be applied again Ben On 27 Jan 2014, at 20:33, Sven Van Caekenberghe s...@stfx.eu wrote: On 28 Jan 2014, at 00:18, Sven Van Caekenberghe s...@stfx.eu wrote: OK, I will try and trust you and Sean. Well, it is in 30 726, but there are 2 regressions found: ReleaseTests.ReleaseTest.testObsoleteClasses ReleaseTests.ReleaseTest.testUnknownProcesses on all 3 platforms, these might be transient, but with all the renaming something could have gone wrong On 28 Jan 2014, at 00:13, Benjamin benjamin.vanryseghem.ph...@gmail.com wrote: On 27 Jan 2014, at 20:08, Sven Van Caekenberghe s...@stfx.eu wrote: Are the compatible ? Does one have to come before the other ? Are they both needed ? I think we should drop https://pharo.fogbugz.com/f/cases/12717/ReactiveVariable-NewValueHolder and integrate https://pharo.fogbugz.com/f/cases/12684/NewValueHolder-Enhancements For at least two reasons: - I added hooks for Spec to continue working with the slice I proposed (otherwise no more Spec fix until the release) - I do not have to review it :P Ok maybe the second point is not that relevant LOL Just that I am sure that the fix I proposed works well with Spec. And I an pretty sure the other will break it :) I was not aware of another case related to this. It is not flagged Spec nor my name, so there is no way for me to guess it exists. Ben
Re: [Pharo-dev] Issues 12717 and 12684
I do not know if I publish it somewhere but when I try to make UserManager I added reset on the class side to avoid such code. Stef On 28 Jan 2014, at 00:57, Sven Van Caekenberghe s...@stfx.eu wrote: Yes, I just tested: UserManager instVarNamed: 'default' put: nil. UserManager initialize. fixes the release tests. I have to go to bed though ;-) Thx! Sven On 28 Jan 2014, at 00:54, Benjamin benjamin.vanryseghem.ph...@gmail.com wrote: I think the fix https://pharo.fogbugz.com/default.asp?12711 might need to be applied again Ben On 27 Jan 2014, at 20:33, Sven Van Caekenberghe s...@stfx.eu wrote: On 28 Jan 2014, at 00:18, Sven Van Caekenberghe s...@stfx.eu wrote: OK, I will try and trust you and Sean. Well, it is in 30 726, but there are 2 regressions found: ReleaseTests.ReleaseTest.testObsoleteClasses ReleaseTests.ReleaseTest.testUnknownProcesses on all 3 platforms, these might be transient, but with all the renaming something could have gone wrong On 28 Jan 2014, at 00:13, Benjamin benjamin.vanryseghem.ph...@gmail.com wrote: On 27 Jan 2014, at 20:08, Sven Van Caekenberghe s...@stfx.eu wrote: Are the compatible ? Does one have to come before the other ? Are they both needed ? I think we should drop https://pharo.fogbugz.com/f/cases/12717/ReactiveVariable-NewValueHolder and integrate https://pharo.fogbugz.com/f/cases/12684/NewValueHolder-Enhancements For at least two reasons: - I added hooks for Spec to continue working with the slice I proposed (otherwise no more Spec fix until the release) - I do not have to review it :P Ok maybe the second point is not that relevant LOL Just that I am sure that the fix I proposed works well with Spec. And I an pretty sure the other will break it :) I was not aware of another case related to this. It is not flagged Spec nor my name, so there is no way for me to guess it exists. Ben
Re: [Pharo-dev] Issues 12717 and 12684
On 28 Jan 2014, at 18:47, Pharo4Stef pharo4s...@free.fr wrote: I do not know if I publish it somewhere but when I try to make UserManager I added reset on the class side to avoid such code. Yes that would be better, but it is not in the image as far as I can see... Stef On 28 Jan 2014, at 00:57, Sven Van Caekenberghe s...@stfx.eu wrote: Yes, I just tested: UserManager instVarNamed: 'default' put: nil. UserManager initialize. fixes the release tests. I have to go to bed though ;-) Thx! Sven On 28 Jan 2014, at 00:54, Benjamin benjamin.vanryseghem.ph...@gmail.com wrote: I think the fix https://pharo.fogbugz.com/default.asp?12711 might need to be applied again Ben On 27 Jan 2014, at 20:33, Sven Van Caekenberghe s...@stfx.eu wrote: On 28 Jan 2014, at 00:18, Sven Van Caekenberghe s...@stfx.eu wrote: OK, I will try and trust you and Sean. Well, it is in 30 726, but there are 2 regressions found: ReleaseTests.ReleaseTest.testObsoleteClasses ReleaseTests.ReleaseTest.testUnknownProcesses on all 3 platforms, these might be transient, but with all the renaming something could have gone wrong On 28 Jan 2014, at 00:13, Benjamin benjamin.vanryseghem.ph...@gmail.com wrote: On 27 Jan 2014, at 20:08, Sven Van Caekenberghe s...@stfx.eu wrote: Are the compatible ? Does one have to come before the other ? Are they both needed ? I think we should drop https://pharo.fogbugz.com/f/cases/12717/ReactiveVariable-NewValueHolder and integrate https://pharo.fogbugz.com/f/cases/12684/NewValueHolder-Enhancements For at least two reasons: - I added hooks for Spec to continue working with the slice I proposed (otherwise no more Spec fix until the release) - I do not have to review it :P Ok maybe the second point is not that relevant LOL Just that I am sure that the fix I proposed works well with Spec. And I an pretty sure the other will break it :) I was not aware of another case related to this. It is not flagged Spec nor my name, so there is no way for me to guess it exists. Ben
Re: [Pharo-dev] Issues 12717 and 12684
On 28 Jan 2014, at 13:53, Pharo4Stef pharo4s...@free.fr wrote: Ben I still think that it would have been good to discuss the valueHolder changes in Spec before doing it. This has been discussed for 2-3 days before I made it actually. Where? because I do not talk about just the question of sean about the name. But the impact. Because it broke the tools of people that used Spec like martin and clement as well as the documentation ignaccio wrote. We should be cautious about other people too. It actually did not break anything. ah so you did not remove asValueHolder. And it had been reverted two days ago ok good then. Ben
Re: [Pharo-dev] Issues 12717 and 12684
2014-01-28 Pharo4Stef pharo4s...@free.fr On 28 Jan 2014, at 13:53, Pharo4Stef pharo4s...@free.fr wrote: Ben I still think that it would have been good to discuss the valueHolder changes in Spec before doing it. This has been discussed for 2-3 days before I made it actually. Where? because I do not talk about just the question of sean about the name. But the impact. I missed that discussion too. And I don't like the name either. I would prefere Binding or ValueBinding. But I am already happe that it does not break code anymore :) Because it broke the tools of people that used Spec like martin and clement as well as the documentation ignaccio wrote. We should be cautious about other people too. It actually did not break anything. ah so you did not remove asValueHolder. And it had been reverted two days ago ok good then. Ben
Re: [Pharo-dev] Issues 12717 and 12684
Nicolai Hess wrote And I don't like the name either. I would prefere Binding or ValueBinding. Guys, I don't love the name either, but can we do a little better than I don't like it. The purpose of ValueHolder's existence was to notify changes to its value. A reactive variable, from FRP, kinda-sorta does that. How does Binding = 'I will notify of changes to my value'?! - Cheers, Sean -- View this message in context: http://forum.world.st/Issues-12717-and-12684-tp4739761p4740024.html Sent from the Pharo Smalltalk Developers mailing list archive at Nabble.com.
Re: [Pharo-dev] Issues 12717 and 12684
On 27 Jan 2014, at 20:08, Sven Van Caekenberghe s...@stfx.eu wrote: Are the compatible ? Does one have to come before the other ? Are they both needed ? I think we should drop https://pharo.fogbugz.com/f/cases/12717/ReactiveVariable-NewValueHolder and integrate https://pharo.fogbugz.com/f/cases/12684/NewValueHolder-Enhancements For at least two reasons: - I added hooks for Spec to continue working with the slice I proposed (otherwise no more Spec fix until the release) - I do not have to review it :P Ok maybe the second point is not that relevant LOL Just that I am sure that the fix I proposed works well with Spec. And I an pretty sure the other will break it :) I was not aware of another case related to this. It is not flagged Spec nor my name, so there is no way for me to guess it exists. Ben
Re: [Pharo-dev] Issues 12717 and 12684
OK, I will try and trust you and Sean. On 28 Jan 2014, at 00:13, Benjamin benjamin.vanryseghem.ph...@gmail.com wrote: On 27 Jan 2014, at 20:08, Sven Van Caekenberghe s...@stfx.eu wrote: Are the compatible ? Does one have to come before the other ? Are they both needed ? I think we should drop https://pharo.fogbugz.com/f/cases/12717/ReactiveVariable-NewValueHolder and integrate https://pharo.fogbugz.com/f/cases/12684/NewValueHolder-Enhancements For at least two reasons: - I added hooks for Spec to continue working with the slice I proposed (otherwise no more Spec fix until the release) - I do not have to review it :P Ok maybe the second point is not that relevant LOL Just that I am sure that the fix I proposed works well with Spec. And I an pretty sure the other will break it :) I was not aware of another case related to this. It is not flagged Spec nor my name, so there is no way for me to guess it exists. Ben
Re: [Pharo-dev] Issues 12717 and 12684
On 28 Jan 2014, at 00:18, Sven Van Caekenberghe s...@stfx.eu wrote: OK, I will try and trust you and Sean. Well, it is in 30 726, but there are 2 regressions found: ReleaseTests.ReleaseTest.testObsoleteClasses ReleaseTests.ReleaseTest.testUnknownProcesses on all 3 platforms, these might be transient, but with all the renaming something could have gone wrong On 28 Jan 2014, at 00:13, Benjamin benjamin.vanryseghem.ph...@gmail.com wrote: On 27 Jan 2014, at 20:08, Sven Van Caekenberghe s...@stfx.eu wrote: Are the compatible ? Does one have to come before the other ? Are they both needed ? I think we should drop https://pharo.fogbugz.com/f/cases/12717/ReactiveVariable-NewValueHolder and integrate https://pharo.fogbugz.com/f/cases/12684/NewValueHolder-Enhancements For at least two reasons: - I added hooks for Spec to continue working with the slice I proposed (otherwise no more Spec fix until the release) - I do not have to review it :P Ok maybe the second point is not that relevant LOL Just that I am sure that the fix I proposed works well with Spec. And I an pretty sure the other will break it :) I was not aware of another case related to this. It is not flagged Spec nor my name, so there is no way for me to guess it exists. Ben
Re: [Pharo-dev] Issues 12717 and 12684
I think the fix https://pharo.fogbugz.com/default.asp?12711 might need to be applied again Ben On 27 Jan 2014, at 20:33, Sven Van Caekenberghe s...@stfx.eu wrote: On 28 Jan 2014, at 00:18, Sven Van Caekenberghe s...@stfx.eu wrote: OK, I will try and trust you and Sean. Well, it is in 30 726, but there are 2 regressions found: ReleaseTests.ReleaseTest.testObsoleteClasses ReleaseTests.ReleaseTest.testUnknownProcesses on all 3 platforms, these might be transient, but with all the renaming something could have gone wrong On 28 Jan 2014, at 00:13, Benjamin benjamin.vanryseghem.ph...@gmail.com wrote: On 27 Jan 2014, at 20:08, Sven Van Caekenberghe s...@stfx.eu wrote: Are the compatible ? Does one have to come before the other ? Are they both needed ? I think we should drop https://pharo.fogbugz.com/f/cases/12717/ReactiveVariable-NewValueHolder and integrate https://pharo.fogbugz.com/f/cases/12684/NewValueHolder-Enhancements For at least two reasons: - I added hooks for Spec to continue working with the slice I proposed (otherwise no more Spec fix until the release) - I do not have to review it :P Ok maybe the second point is not that relevant LOL Just that I am sure that the fix I proposed works well with Spec. And I an pretty sure the other will break it :) I was not aware of another case related to this. It is not flagged Spec nor my name, so there is no way for me to guess it exists. Ben
Re: [Pharo-dev] Issues 12717 and 12684
Yes, I just tested: UserManager instVarNamed: 'default' put: nil. UserManager initialize. fixes the release tests. I have to go to bed though ;-) Thx! Sven On 28 Jan 2014, at 00:54, Benjamin benjamin.vanryseghem.ph...@gmail.com wrote: I think the fix https://pharo.fogbugz.com/default.asp?12711 might need to be applied again Ben On 27 Jan 2014, at 20:33, Sven Van Caekenberghe s...@stfx.eu wrote: On 28 Jan 2014, at 00:18, Sven Van Caekenberghe s...@stfx.eu wrote: OK, I will try and trust you and Sean. Well, it is in 30 726, but there are 2 regressions found: ReleaseTests.ReleaseTest.testObsoleteClasses ReleaseTests.ReleaseTest.testUnknownProcesses on all 3 platforms, these might be transient, but with all the renaming something could have gone wrong On 28 Jan 2014, at 00:13, Benjamin benjamin.vanryseghem.ph...@gmail.com wrote: On 27 Jan 2014, at 20:08, Sven Van Caekenberghe s...@stfx.eu wrote: Are the compatible ? Does one have to come before the other ? Are they both needed ? I think we should drop https://pharo.fogbugz.com/f/cases/12717/ReactiveVariable-NewValueHolder and integrate https://pharo.fogbugz.com/f/cases/12684/NewValueHolder-Enhancements For at least two reasons: - I added hooks for Spec to continue working with the slice I proposed (otherwise no more Spec fix until the release) - I do not have to review it :P Ok maybe the second point is not that relevant LOL Just that I am sure that the fix I proposed works well with Spec. And I an pretty sure the other will break it :) I was not aware of another case related to this. It is not flagged Spec nor my name, so there is no way for me to guess it exists. Ben
Re: [Pharo-dev] Issues 12717 and 12684
Thank you for your motivation :) Ben On 27 Jan 2014, at 20:57, Sven Van Caekenberghe s...@stfx.eu wrote: Yes, I just tested: UserManager instVarNamed: 'default' put: nil. UserManager initialize. fixes the release tests. I have to go to bed though ;-) Thx! Sven On 28 Jan 2014, at 00:54, Benjamin benjamin.vanryseghem.ph...@gmail.com wrote: I think the fix https://pharo.fogbugz.com/default.asp?12711 might need to be applied again Ben On 27 Jan 2014, at 20:33, Sven Van Caekenberghe s...@stfx.eu wrote: On 28 Jan 2014, at 00:18, Sven Van Caekenberghe s...@stfx.eu wrote: OK, I will try and trust you and Sean. Well, it is in 30 726, but there are 2 regressions found: ReleaseTests.ReleaseTest.testObsoleteClasses ReleaseTests.ReleaseTest.testUnknownProcesses on all 3 platforms, these might be transient, but with all the renaming something could have gone wrong On 28 Jan 2014, at 00:13, Benjamin benjamin.vanryseghem.ph...@gmail.com wrote: On 27 Jan 2014, at 20:08, Sven Van Caekenberghe s...@stfx.eu wrote: Are the compatible ? Does one have to come before the other ? Are they both needed ? I think we should drop https://pharo.fogbugz.com/f/cases/12717/ReactiveVariable-NewValueHolder and integrate https://pharo.fogbugz.com/f/cases/12684/NewValueHolder-Enhancements For at least two reasons: - I added hooks for Spec to continue working with the slice I proposed (otherwise no more Spec fix until the release) - I do not have to review it :P Ok maybe the second point is not that relevant LOL Just that I am sure that the fix I proposed works well with Spec. And I an pretty sure the other will break it :) I was not aware of another case related to this. It is not flagged Spec nor my name, so there is no way for me to guess it exists. Ben
