Issues 12717 and 12684
Guys, What is the relationship between issues 12717 and 12684 ? https://pharo.fogbugz.com/f/cases/12717/ReactiveVariable-NewValueHolder https://pharo.fogbugz.com/f/cases/12684/NewValueHolder-Enhancements Are the compatible ? Does one have to come before the other ? Are they both needed ? Since they change so much it is hard (for me at least) to judge whether it is safe to integrate them. Sven
On 27 Jan 2014, at 20:08, Sven Van Caekenberghe <sven@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
OK, I will try and trust you and Sean. On 28 Jan 2014, at 00:13, Benjamin <benjamin.vanryseghem.pharo@gmail.com> wrote:
On 27 Jan 2014, at 20:08, Sven Van Caekenberghe <sven@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
On 28 Jan 2014, at 00:18, Sven Van Caekenberghe <sven@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.pharo@gmail.com> wrote:
On 27 Jan 2014, at 20:08, Sven Van Caekenberghe <sven@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
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 <sven@stfx.eu> wrote:
On 28 Jan 2014, at 00:18, Sven Van Caekenberghe <sven@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.pharo@gmail.com> wrote:
On 27 Jan 2014, at 20:08, Sven Van Caekenberghe <sven@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
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.pharo@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 <sven@stfx.eu> wrote:
On 28 Jan 2014, at 00:18, Sven Van Caekenberghe <sven@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.pharo@gmail.com> wrote:
On 27 Jan 2014, at 20:08, Sven Van Caekenberghe <sven@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
Thank you for your motivation :) Ben On 27 Jan 2014, at 20:57, Sven Van Caekenberghe <sven@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.pharo@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 <sven@stfx.eu> wrote:
On 28 Jan 2014, at 00:18, Sven Van Caekenberghe <sven@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.pharo@gmail.com> wrote:
On 27 Jan 2014, at 20:08, Sven Van Caekenberghe <sven@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
On 28 Jan 2014, at 00:57, Sven Van Caekenberghe <sven@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.pharo@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 <sven@stfx.eu> wrote:
On 28 Jan 2014, at 00:18, Sven Van Caekenberghe <sven@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.pharo@gmail.com> wrote:
On 27 Jan 2014, at 20:08, Sven Van Caekenberghe <sven@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
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 <sven@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.pharo@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 <sven@stfx.eu> wrote:
On 28 Jan 2014, at 00:18, Sven Van Caekenberghe <sven@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.pharo@gmail.com> wrote:
On 27 Jan 2014, at 20:08, Sven Van Caekenberghe <sven@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
On 28 Jan 2014, at 18:47, Pharo4Stef <pharo4Stef@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 <sven@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.pharo@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 <sven@stfx.eu> wrote:
On 28 Jan 2014, at 00:18, Sven Van Caekenberghe <sven@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.pharo@gmail.com> wrote:
On 27 Jan 2014, at 20:08, Sven Van Caekenberghe <sven@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
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 <sven@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
On 28 Jan 2014, at 13:53, Pharo4Stef <pharo4Stef@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.
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. And it had been reverted two days ago Ben
On 28 Jan 2014, at 13:53, Pharo4Stef <pharo4Stef@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
2014-01-28 Pharo4Stef <pharo4Stef@free.fr>
On 28 Jan 2014, at 13:53, Pharo4Stef <pharo4Stef@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
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.
2014-01-29 Sean P. DeNigris <sean@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
2014-01-29 Nicolai Hess <nicolaihess@web.de>
2014-01-29 Sean P. DeNigris <sean@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...
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.
2014-01-29 Sean P. DeNigris <sean@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.
On 29 Jan 2014, at 7:41 , Sean P. DeNigris <sean@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
On 30 Jan 2014, at 11:02 , Henrik Johansen <henrik.s.johansen@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
On 30 Jan 2014, at 11:02 , Henrik Johansen <henrik.s.johansen@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
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.
On 30 January 2014 14:21, Sean P. DeNigris <sean@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.
participants (9)
-
Benjamin -
Benjamin
-
Frank Shearar -
Henrik Johansen -
Nicolai Hess -
Nicolas Cellier -
Pharo4Stef -
Sean P. DeNigris -
Sven Van Caekenberghe