[Pharo-project] About AXAnnouncements (was: some Announcements related questions)
Hi! Just to make things clear, AXAnnouncements - is not "a port of the original announcement implementation" - is (more or less) based on Vassili Bykov's blog (http://www.cincomsmalltalk.com/userblogs/vbykov/blogView?searchCategory=Anno...) just like the Announcements package in Pharo - is released under the MIT license (http://www.squeaksource.com/AXAnnouncements.html). We implemented the framework as the blog entries came out and integrated it into our rudimentary ajax framework (that's where the AX prefix came from). Later we abandoned the ajax framework but found announcements really useful (especially with seaside components), so we extracted the code and moved it to squeaksource. Our ajax framework demo was available at http://axdemo.seasidehosting.st/. For a quick comparison: AXAnnouncements is bloated and has lower code quality than Announcements, but it implements more features, like suspension and interception of announcements, weak subscriptions and allows different base class for the announcements hierarchy per announcer. Cheers, Levente
Just to make things clear, AXAnnouncements - is not "a port of the original announcement implementation"
Ok, excellent. Just trying to avoid possible issues. Lukas -- Lukas Renggli http://www.lukas-renggli.ch
I get a: Error: "/seaside/" not found. Alexandre -- _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: Alexandre Bergel http://www.bergel.eu ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.
Hello, in pharo1.0-10492-rc1dev09.11.1, the method metaclass in RBAbstractClass and RBMetaclass is not there... Is that normal ? François
I renamed the methods #metaclass and #nonMetaclass, because these selectors are not polymorphic with what is standard in the Pharo class hierarchy where #theMetaclass and #theNonMetaclass are used. Looks like O2-Refactory and other external users needs to be updated. I changed all senders OB-Refactory. Lukas 2009/10/30 François Tanguy <francois.tanguy@gmail.com>:
Hello,
in pharo1.0-10492-rc1dev09.11.1, the method metaclass in RBAbstractClass and RBMetaclass is not there... Is that normal ?
François _______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
-- Lukas Renggli http://www.lukas-renggli.ch
Yes, like the code generator of Fame for instance. François Le Oct 30, 2009 à 4:17 PM, Lukas Renggli a écrit :
I renamed the methods #metaclass and #nonMetaclass, because these selectors are not polymorphic with what is standard in the Pharo class hierarchy where #theMetaclass and #theNonMetaclass are used.
Looks like O2-Refactory and other external users needs to be updated.
I changed all senders OB-Refactory.
Lukas
2009/10/30 François Tanguy <francois.tanguy@gmail.com>:
Hello,
in pharo1.0-10492-rc1dev09.11.1, the method metaclass in RBAbstractClass and RBMetaclass is not there... Is that normal ?
François _______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
-- Lukas Renggli http://www.lukas-renggli.ch
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
lukas could you deprecate the methods so that users get the time to update. Stef On Oct 30, 2009, at 4:17 PM, Lukas Renggli wrote:
I renamed the methods #metaclass and #nonMetaclass, because these selectors are not polymorphic with what is standard in the Pharo class hierarchy where #theMetaclass and #theNonMetaclass are used.
Looks like O2-Refactory and other external users needs to be updated.
I changed all senders OB-Refactory.
Lukas
2009/10/30 François Tanguy <francois.tanguy@gmail.com>:
Hello,
in pharo1.0-10492-rc1dev09.11.1, the method metaclass in RBAbstractClass and RBMetaclass is not there... Is that normal ?
François _______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
-- Lukas Renggli http://www.lukas-renggli.ch
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
http://axdemo.seasidehosting.st/seaside/ax or http://axdemo.seasidehosting.st/browse 2009/10/30 Alexandre Bergel <alexandre@bergel.eu>
I get a: Error: "/seaside/" not found.
Alexandre
-- _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: Alexandre Bergel http://www.bergel.eu ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
-- Cédrick
Works better. Thanks, Alexandre On 30 Oct 2009, at 13:10, Cédrick Béler wrote:
http://axdemo.seasidehosting.st/seaside/ax
or
http://axdemo.seasidehosting.st/browse
2009/10/30 Alexandre Bergel <alexandre@bergel.eu>
I get a: Error: "/seaside/" not found.
Alexandre
-- _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: Alexandre Bergel http://www.bergel.eu ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
-- Cédrick _______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
-- _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: Alexandre Bergel http://www.bergel.eu ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.
Hi! On Fri, 30 Oct 2009, Alexandre Bergel wrote:
I get a: Error: "/seaside/" not found.
Try this: http://axdemo.seasidehosting.st/seaside/ax or this: http://axdemo.seasidehosting.st/seaside/browse :) Cheers, Levente
Levente what I would really love :) is if you could provide some extensions to the new version based on your experience. I think that Announcements are a bit limited right now. Then the core would be enhanced and we could clarified the license. Stef On Oct 30, 2009, at 1:25 AM, Levente Uzonyi wrote:
Hi!
Just to make things clear, AXAnnouncements - is not "a port of the original announcement implementation" - is (more or less) based on Vassili Bykov's blog (http://www.cincomsmalltalk.com/userblogs/vbykov/blogView?searchCategory=Anno... ) just like the Announcements package in Pharo - is released under the MIT license (http://www.squeaksource.com/AXAnnouncements.html ). We implemented the framework as the blog entries came out and integrated it into our rudimentary ajax framework (that's where the AX prefix came from). Later we abandoned the ajax framework but found announcements really useful (especially with seaside components), so we extracted the code and moved it to squeaksource. Our ajax framework demo was available at http://axdemo.seasidehosting.st/.
For a quick comparison: AXAnnouncements is bloated and has lower code quality than Announcements, but it implements more features, like suspension and interception of announcements, weak subscriptions and allows different base class for the announcements hierarchy per announcer.
Cheers, Levente
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
what would be good is to have a small discussion on the key and minimal features that could be added to Announcements, add some tests and code. Stef On Oct 31, 2009, at 5:17 PM, Stéphane Ducasse wrote:
Levente
what I would really love :) is if you could provide some extensions to the new version based on your experience. I think that Announcements are a bit limited right now. Then the core would be enhanced and we could clarified the license.
Stef
On Oct 30, 2009, at 1:25 AM, Levente Uzonyi wrote:
Hi!
Just to make things clear, AXAnnouncements - is not "a port of the original announcement implementation" - is (more or less) based on Vassili Bykov's blog (http://www.cincomsmalltalk.com/userblogs/vbykov/blogView?searchCategory=Anno... ) just like the Announcements package in Pharo - is released under the MIT license (http://www.squeaksource.com/AXAnnouncements.html ). We implemented the framework as the blog entries came out and integrated it into our rudimentary ajax framework (that's where the AX prefix came from). Later we abandoned the ajax framework but found announcements really useful (especially with seaside components), so we extracted the code and moved it to squeaksource. Our ajax framework demo was available at http://axdemo.seasidehosting.st/.
For a quick comparison: AXAnnouncements is bloated and has lower code quality than Announcements, but it implements more features, like suspension and interception of announcements, weak subscriptions and allows different base class for the announcements hierarchy per announcer.
Cheers, Levente
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
AXAnnouncements is pretty small and accompanied with tests. So why not integrate it + removing 'AX' prefix because, as decided previously, it should be in Pharo core? 2009/10/31 Stéphane Ducasse <stephane.ducasse@inria.fr>:
what would be good is to have a small discussion on the key and minimal features that could be added to Announcements, add some tests and code.
Stef On Oct 31, 2009, at 5:17 PM, Stéphane Ducasse wrote:
Levente
what I would really love :) is if you could provide some extensions to the new version based on your experience. I think that Announcements are a bit limited right now. Then the core would be enhanced and we could clarified the license.
Stef
On Oct 30, 2009, at 1:25 AM, Levente Uzonyi wrote:
Hi!
Just to make things clear, AXAnnouncements - is not "a port of the original announcement implementation" - is (more or less) based on Vassili Bykov's blog  (http://www.cincomsmalltalk.com/userblogs/vbykov/blogView?searchCategory=Anno... )  just like the Announcements package in Pharo - is released under the MIT license (http://www.squeaksource.com/AXAnnouncements.html ). We implemented the framework as the blog entries came out and integrated it into our rudimentary ajax framework (that's where the AX prefix came from). Later we abandoned the ajax framework but found announcements really useful (especially with seaside components), so we extracted the code and moved it to squeaksource. Our ajax framework demo was available at http://axdemo.seasidehosting.st/.
For a quick comparison: AXAnnouncements is bloated and has lower code quality than Announcements, but it implements more features, like suspension and interception of announcements, weak subscriptions and allows different base class for the announcements hierarchy per announcer.
Cheers, Levente
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
-- Best regards, Igor Stasenko AKA sig.
This could be a possibility now I think that this is nice that people get a chance to check it and discuss. Stef On Oct 31, 2009, at 10:02 PM, Igor Stasenko wrote:
AXAnnouncements is pretty small and accompanied with tests. So why not integrate it + removing 'AX' prefix because, as decided previously, it should be in Pharo core?
2009/10/31 Stéphane Ducasse <stephane.ducasse@inria.fr>:
what would be good is to have a small discussion on the key and minimal features that could be added to Announcements, add some tests and code.
Stef On Oct 31, 2009, at 5:17 PM, Stéphane Ducasse wrote:
Levente
what I would really love :) is if you could provide some extensions to the new version based on your experience. I think that Announcements are a bit limited right now. Then the core would be enhanced and we could clarified the license.
Stef
On Oct 30, 2009, at 1:25 AM, Levente Uzonyi wrote:
Hi!
Just to make things clear, AXAnnouncements - is not "a port of the original announcement implementation" - is (more or less) based on Vassili Bykov's blog (http://www.cincomsmalltalk.com/userblogs/vbykov/blogView?searchCategory=Anno... ) just like the Announcements package in Pharo - is released under the MIT license (http://www.squeaksource.com/AXAnnouncements.html ). We implemented the framework as the blog entries came out and integrated it into our rudimentary ajax framework (that's where the AX prefix came from). Later we abandoned the ajax framework but found announcements really useful (especially with seaside components), so we extracted the code and moved it to squeaksource. Our ajax framework demo was available at http://axdemo.seasidehosting.st/.
For a quick comparison: AXAnnouncements is bloated and has lower code quality than Announcements, but it implements more features, like suspension and interception of announcements, weak subscriptions and allows different base class for the announcements hierarchy per announcer.
Cheers, Levente
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
-- Best regards, Igor Stasenko AKA sig.
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
2009/10/31 Stéphane Ducasse <stephane.ducasse@inria.fr>:
This could be a possibility now I think that this is nice that people get a chance to check it and discuss.
yes, please decide. :) Because from that decision, we could then plan a new system-change annoucements layer + package system. In current core image, Announcements is quite small (just around 10 methods totally) and i doubt it provides enough flexibility which would not require adding & reinventing additional useful stuff on top of it.
Stef
On Oct 31, 2009, at 10:02 PM, Igor Stasenko wrote:
AXAnnouncements is pretty small and accompanied with tests. So why not integrate it + removing 'AX' prefix because, as decided previously, it should be in Pharo core?
2009/10/31 Stéphane Ducasse <stephane.ducasse@inria.fr>:
what would be good is to have a small discussion on the key and minimal features that could be added to Announcements, add some tests and code.
Stef On Oct 31, 2009, at 5:17 PM, Stéphane Ducasse wrote:
Levente
what I would really love :) is if you could provide some extensions to the new version based on your experience. I think that Announcements are a bit limited right now. Then the core would be enhanced and we could clarified the license.
Stef
On Oct 30, 2009, at 1:25 AM, Levente Uzonyi wrote:
Hi!
Just to make things clear, AXAnnouncements - is not "a port of the original announcement implementation" - is (more or less) based on Vassili Bykov's blog  (http://www.cincomsmalltalk.com/userblogs/vbykov/blogView?searchCategory=Anno... )  just like the Announcements package in Pharo - is released under the MIT license (http://www.squeaksource.com/AXAnnouncements.html ). We implemented the framework as the blog entries came out and integrated it into our rudimentary ajax framework (that's where the AX prefix came from). Later we abandoned the ajax framework but found announcements really useful (especially with seaside components), so we extracted the code and moved it to squeaksource. Our ajax framework demo was available at http://axdemo.seasidehosting.st/.
For a quick comparison: AXAnnouncements is bloated and has lower code quality than Announcements, but it implements more features, like suspension and interception of announcements, weak subscriptions and allows different base class for the announcements hierarchy per announcer.
Cheers, Levente
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
-- Best regards, Igor Stasenko AKA sig.
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
-- Best regards, Igor Stasenko AKA sig.
I think that Axa needs a good cleaning brush. So let us see what we can get. Stef On Oct 31, 2009, at 10:23 PM, Igor Stasenko wrote:
2009/10/31 Stéphane Ducasse <stephane.ducasse@inria.fr>:
This could be a possibility now I think that this is nice that people get a chance to check it and discuss.
yes, please decide. :) Because from that decision, we could then plan a new system-change annoucements layer + package system. In current core image, Announcements is quite small (just around 10 methods totally) and i doubt it provides enough flexibility which would not require adding & reinventing additional useful stuff on top of it.
Stef
On Oct 31, 2009, at 10:02 PM, Igor Stasenko wrote:
AXAnnouncements is pretty small and accompanied with tests. So why not integrate it + removing 'AX' prefix because, as decided previously, it should be in Pharo core?
2009/10/31 Stéphane Ducasse <stephane.ducasse@inria.fr>:
what would be good is to have a small discussion on the key and minimal features that could be added to Announcements, add some tests and code.
Stef On Oct 31, 2009, at 5:17 PM, Stéphane Ducasse wrote:
Levente
what I would really love :) is if you could provide some extensions to the new version based on your experience. I think that Announcements are a bit limited right now. Then the core would be enhanced and we could clarified the license.
Stef
On Oct 30, 2009, at 1:25 AM, Levente Uzonyi wrote:
Hi!
Just to make things clear, AXAnnouncements - is not "a port of the original announcement implementation" - is (more or less) based on Vassili Bykov's blog (http://www.cincomsmalltalk.com/userblogs/vbykov/blogView?searchCategory=Anno... ) just like the Announcements package in Pharo - is released under the MIT license (http://www.squeaksource.com/AXAnnouncements.html ). We implemented the framework as the blog entries came out and integrated it into our rudimentary ajax framework (that's where the AX prefix came from). Later we abandoned the ajax framework but found announcements really useful (especially with seaside components), so we extracted the code and moved it to squeaksource. Our ajax framework demo was available at http://axdemo.seasidehosting.st/.
For a quick comparison: AXAnnouncements is bloated and has lower code quality than Announcements, but it implements more features, like suspension and interception of announcements, weak subscriptions and allows different base class for the announcements hierarchy per announcer.
Cheers, Levente
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo- project
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
-- Best regards, Igor Stasenko AKA sig.
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
-- Best regards, Igor Stasenko AKA sig.
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
In current core image, Announcements is quite small (just around 10 methods totally) and i doubt it provides enough flexibility which would not require adding & reinventing additional useful stuff on top of it.
I have used these announcements in many large projects and I never needed to add anything. In fact, I would even vote to remove AnnouncementSet as I never used it or saw it used anywhere. Initially, I found it cool because the same trick is applied in the Exception hierarchy. Major projects like OmniBrowser (and to some extent also Seaside) use an even smaller subset of the functionality provided in the core package. The only thing that is maybe missing are weak announcements. I guess that could be useful, if Pharo provided a solid implementation of weak objects. Lukas -- Lukas Renggli http://www.lukas-renggli.ch
2009/11/1 Lukas Renggli <renggli@gmail.com>:
In current core image, Announcements is quite small (just around 10 methods totally) and i doubt it provides enough flexibility which would not require adding & reinventing additional useful stuff on top of it.
I have used these announcements in many large projects and I never needed to add anything. In fact, I would even vote to remove AnnouncementSet as I never used it or saw it used anywhere. Initially, I found it cool because the same trick is applied in the Exception hierarchy. Major projects like OmniBrowser (and to some extent also Seaside) use an even smaller subset of the functionality provided in the core package.
The only thing that is maybe missing are weak announcements. I guess that could be useful, if Pharo provided a solid implementation of weak objects.
Announcements is just another implementation of observer pattern. And given that its quite simple to (re)implement by own, obviously, the question is, why anyone would want to use Announcements instead of making own? If Announcements provides more wide functionality in addition to observer pattern - then yes, you could say: it is better because in addition you have this and that. But if it so stripped to bare-bones, then where the benefits to use exactly Announcements?
Lukas
-- Lukas Renggli http://www.lukas-renggli.ch
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
-- Best regards, Igor Stasenko AKA sig.
But if it so stripped to bare-bones, then where the benefits to use exactly Announcements?
I would rather like to hear what this "more wide functionality" is all about? So far you only argued that big is better. I don't buy that. This is old, but "Small is the new big" ;-) A smaller infrastructure also means: - easier to learn - less code that rots - less code to maintain - less code duplication - less code to test - loose coupling - smaller image Cheers, Lukas -- Lukas Renggli http://www.lukas-renggli.ch
2009/11/1 Lukas Renggli <renggli@gmail.com>:
But if it so stripped to bare-bones, then where the benefits to use exactly Announcements?
I would rather like to hear what this "more wide functionality" is all about?
i don't know. I just not buying 'use this' because its good. I need to know why its so good :) As far as i can see, it is as good as any other observer pattern implementation. But alone, this pattern is nothing, so we should analyze, how well it fits for use in different scenarios. And so, what if such implementation doesn't play well with all scenarios, would you still insist to use Announcements instead of making own, given that cost of implementation is quite small (10 or even less methods)?
So far you only argued that big is better. I don't buy that.
In contrary. An annoucements implies to use separate (sub)classes for different event kinds. While i can simply use field in the event to identify its kind. Lets say you having 50 event kinds. So what is bigger - single class + 1 field, or 50 classes? Or we not counting classes as a code? So, as you can see, announcements, in some cases could lead to 'bigger' code bloat. And i would like to know, why it is still good to use them, despite the costs of such potential bloat.
This is old, but "Small is the new big" ;-)
A smaller infrastructure also means:
- easier to learn - less code that rots - less code to maintain - less code duplication - less code to test - loose coupling - smaller image
yes, good software is one where nothing left to remove, instead nothing left to add.
Cheers, Lukas
-- Lukas Renggli http://www.lukas-renggli.ch
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
-- Best regards, Igor Stasenko AKA sig.
2009/11/1 Igor Stasenko <siguctua@gmail.com>:
2009/11/1 Lukas Renggli <renggli@gmail.com>:
But if it so stripped to bare-bones, then where the benefits to use exactly Announcements?
I would rather like to hear what this "more wide functionality" is all about?
i don't know. I just not buying 'use this' because its good. I need to know why its so good :) As far as i can see, it is as good as any other observer pattern implementation. But alone, this pattern is nothing, so we should analyze, how well it fits for use in different scenarios. And so, what if such implementation doesn't play well with all scenarios, would you still insist to use Announcements instead of making own, given that cost of implementation is quite small (10 or even less methods)?
So far you only argued that big is better. I don't buy that.
In contrary. An annoucements implies to use separate (sub)classes for different event kinds. While i can simply use field in the event to identify its kind. Lets say you having 50 event kinds. So what is bigger - single class + 1 field, or 50 classes? Or we not counting classes as a code?
So, as you can see, announcements, in some cases could lead to 'bigger' code bloat. And i would like to know, why it is still good to use them, despite the costs of such potential bloat.
Just a bit more arguing. :) Suppose i bought the idea, and created a 50 subclasses. They form some kind of tree (such as AbstractEvent subclasses). So far so good. But now i want some of those event kinds to be logged, while some of them are not. What annoucements framework could propose for this scenario? Okay, i can create a new announcement subclass: Announcement subclass: #LoggedAnnouncement ... so then any , who would like to subcscibe to logged announcement could simply do something like: annoucer on: LoggedAnnouncement do: [:ann | Transcript show: ann message ]. But how i suppose to wire it up with the tree above? Obviously i can't. Because if i make all of the tree to be a subclass of LoggedAnnouncement, then all of them will be logged, while i want only some of them.
This is old, but "Small is the new big" ;-)
A smaller infrastructure also means:
- easier to learn - less code that rots - less code to maintain - less code duplication - less code to test - loose coupling - smaller image
yes, good software is one where nothing left to remove, instead nothing left to add.
Cheers, Lukas
-- Lukas Renggli http://www.lukas-renggli.ch
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
-- Best regards, Igor Stasenko AKA sig.
-- Best regards, Igor Stasenko AKA sig.
Obviously i can't. Because if i make all of the tree to be a subclass of LoggedAnnouncement, then all of them will be logged, while i want only some of them.
You are missing the point of announcements: they are not supposed to do anything, they are only supposed to notify interested parties about something. It is the sole responsibility of the interested party to register for announcements. If somebody is interested logging some announcement, then this interested party should declare that wish. The announcement itself shouldn't care. Lukas -- Lukas Renggli http://www.lukas-renggli.ch
Indeed, the main and only goal of Announcement is to provide an object- oriented (Exception-like) way to handle notifications. I have used the Announcements implementation of Lukas on several occasions and I did not feel the need for anything else. You indeed should subclass Announcement for any specific announcement, but that is not a drawback, it is a nice feature. If you want to have an announcement that you want to identify by a special single field, you are free to implement that in one announcement class on top. Cheers, Doru On 1 Nov 2009, at 17:08, Lukas Renggli wrote:
Obviously i can't. Because if i make all of the tree to be a subclass of LoggedAnnouncement, then all of them will be logged, while i want only some of them.
You are missing the point of announcements: they are not supposed to do anything, they are only supposed to notify interested parties about something. It is the sole responsibility of the interested party to register for announcements. If somebody is interested logging some announcement, then this interested party should declare that wish. The announcement itself shouldn't care.
Lukas
-- Lukas Renggli http://www.lukas-renggli.ch
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
-- www.tudorgirba.com "Some battles are better lost than fought."
2009/11/1 Tudor Girba <tudor.girba@gmail.com>:
Indeed, the main and only goal of Announcement is to provide an object- oriented (Exception-like) way to handle notifications.
I have used the Announcements implementation of Lukas on several occasions and I did not feel the need for anything else.
You indeed should subclass Announcement for any specific announcement, but that is not a drawback, it is a nice feature. If you want to have an announcement that you want to identify by a special single field, you are free to implement that in one announcement class on top.
Thanks Doru. Indeed, its a feature, but not a rule which everyone should follow. In other thread, I had proposed to use field to identify an event type instead of class, and someone said that i'm doing it wrong. While i thinking that the way how the framework identifies events kinds (by default) not always best one, and as i illustrated its not good for everything.
Cheers, Doru
On 1 Nov 2009, at 17:08, Lukas Renggli wrote:
Obviously i can't. Because if i make all of the tree to be a subclass of LoggedAnnouncement, then all of them will be logged, while i want only some of them.
You are missing the point of announcements: they are not supposed to do anything, they are only supposed to notify interested parties about something. It is the sole responsibility of the interested party to register for announcements. If somebody is interested logging some announcement, then this interested party should declare that wish. The announcement itself shouldn't care.
Lukas
-- Lukas Renggli http://www.lukas-renggli.ch
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
-- www.tudorgirba.com
"Some battles are better lost than fought."
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
-- Best regards, Igor Stasenko AKA sig.
Igor Stasenko wrote:
2009/11/1 Tudor Girba <tudor.girba@gmail.com>:
Indeed, the main and only goal of Announcement is to provide an object- oriented (Exception-like) way to handle notifications.
I have used the Announcements implementation of Lukas on several occasions and I did not feel the need for anything else.
You indeed should subclass Announcement for any specific announcement, but that is not a drawback, it is a nice feature. If you want to have an announcement that you want to identify by a special single field, you are free to implement that in one announcement class on top.
Thanks Doru. Indeed, its a feature, but not a rule which everyone should follow.
Hi Igor and all, just reading this interesting thread...
In other thread, I had proposed to use field to identify an event type instead of class, and someone said that i'm doing it wrong.
I guess you speak about my remark in the "ClassOrganizer oddities" thread. Here is what I said: -------------------------------------
You defined a set of announcement classes, each one is for a particular kind of event. So, no need for #changeKind and #parameters dictionary instance variable (please no!). -------- end----------
just to be clear, the "please no!" was for the dictionary because it can make the code difficult to maintain (Morph properties ...). why not the #changeKind variable even I prefer expressing them by subclasses.
While i thinking that the way how the framework identifies events kinds (by default) not always best one, and as i illustrated its not good for everything.
yes and having a well defined announce hierarchy is not so easy. Cheers Alain
2009/11/2 Alain Plantec <alain.plantec@free.fr>:
Igor Stasenko wrote:
2009/11/1 Tudor Girba <tudor.girba@gmail.com>:
Indeed, the main and only goal of Announcement is to provide an object- oriented (Exception-like) way to handle notifications.
I have used the Announcements implementation of Lukas on several occasions and I did not feel the need for anything else.
You indeed should subclass Announcement for any specific announcement, but that is not a drawback, it is a nice feature. If you want to have an announcement that you want to identify by a special single field, you are free to implement that in one announcement class on top.
Thanks Doru. Indeed, its a feature, but not a rule which everyone should follow.
Hi Igor and all, just reading this interesting thread...
In other thread, I had proposed to use field to identify an event type instead of class, and someone said that i'm doing it wrong.
I guess you speak about my remark in the "ClassOrganizer oddities" thread. Here is what I said: -------------------------------------
You defined a set of announcement classes, each one is for a particular kind of event. So, no need for #changeKind and #parameters dictionary instance variable (please no!). -------- end----------
just to be clear, the "please no!" was for the dictionary because it can make the code difficult to maintain (Morph properties ...). why not the #changeKind variable even I prefer expressing them by subclasses.
(see the end of this post)
While i thinking that the way how the framework identifies events kinds (by default) not always best one, and as i illustrated its not good for everything.
yes and having a well defined announce hierarchy is not so easy.
that's why for sketching purposes, i'm using dictionary of arguments, not keyword messages and not building a class hierarchy of different change kinds. At this stage it is unclear what follows what, what is the final set of arguments for each change kind, and so i prefer to generate events using less 'early-bound' way.
Cheers Alain
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
-- Best regards, Igor Stasenko AKA sig.
I just uploaded the modified announcer code + new tests. Please check the http://www.squeaksource.com/PharoInbox/Announcements-Slice-Igor_Stasenko.1.m... and send a feedback -- Best regards, Igor Stasenko AKA sig.
2009/11/3 Igor Stasenko <siguctua@gmail.com>:
I just uploaded the modified announcer code + new tests. Please check the
http://www.squeaksource.com/PharoInbox/Announcements-Slice-Igor_Stasenko.1.m...
and send a feedback
oh.. for those who interested , but too lazy (or busy) to check it out.. - added a generic #subscribe: form of subscription. - added weak subscriptions support (except block subscriptions). Also, unsubscribing is allowed during handling an announcements, as well as nested announcements (these two features should work ok, but i didn't covered them with tests).
-- Best regards, Igor Stasenko AKA sig.
-- Best regards, Igor Stasenko AKA sig.
2009/11/1 Lukas Renggli <renggli@gmail.com>:
Obviously i can't. Because if i make all of the tree to be a subclass of LoggedAnnouncement, then all of them will be logged, while i want only some of them.
You are missing the point of announcements: they are not supposed to do anything, they are only supposed to notify interested parties about something. It is the sole responsibility of the interested party to register for announcements. If somebody is interested logging some announcement, then this interested party should declare that wish. The announcement itself shouldn't care.
Hmm.. i don't think that i'm missing the point. Where in this code: annoucer on: LoggedAnnouncement do: [:ann | Transcript show: ann message ]. you see that i'm putting a responsibility for handling the announcement on announcement, instead of subscriber? Subscriber provides a block, and given that LoggedAnnouncement implements #message , it simply using it. But subscriber is free to do anything he likes to in the handler block, so again, i don't see where i putting any responsibility on announcement instead of subscriber. Oh, wait.. you mean that if i want, say 35 out of 50 announcement kinds to be logged, then i need to do something like: logblock := [:announcement | ... ]. announcer on: AnnouncementKind1 do: logblock. announcer on: AnnouncementKind2 do: logblock. .... announcer on: AnnouncementKind35 do: logblock. ? Do you agree that this is far from being short and elegant? Moreover it imposes dependency from various kinds of events, instead of just one (LoggedAnnouncement), and, if i going to change them somehow, i would need to revisit this code again.. and again. I used this case to illustrate, that single inheritance , which used in Annoucements framework not always sufficient. In this case, it would need to overrride Announcement class>>handles: anAnnouncementClass ^ anAnnouncementClass isKindOf: self in LoggedAnnouncement , to something like: LoggedAnnouncement class>>handles: anAnnouncementClass ^ anAnnouncementClass isLoggedAnnouncement and provide a default #isLoggedAnnouncement implementation in Announcement class. as well as in any my own classes, override it to answer true. So, to implement this scenario i need substantional efforts to be taken. And already will need to extend Announcement class.
Lukas
-- Lukas Renggli http://www.lukas-renggli.ch
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
-- Best regards, Igor Stasenko AKA sig.
Oh, wait.. you mean that if i want, say 35 out of 50 announcement kinds to be logged, then i need to do something like:
logblock := [:announcement | ... ]. announcer on: AnnouncementKind1 do: logblock. announcer on: AnnouncementKind2 do: logblock. .... announcer on: AnnouncementKind35 do: logblock.
? Do you agree that this is far from being short and elegant? Moreover it imposes dependency from various kinds of events, instead of just one (LoggedAnnouncement), and, if i going to change them somehow, i would need to revisit this code again.. and again.
announcer on: AnnouncementKind1 , AnnouncementKind2 , ... AnnouncementKind35 do: logblock -- Lukas Renggli http://www.lukas-renggli.ch
you see you find a use of Set :) Stef On Nov 1, 2009, at 6:17 PM, Lukas Renggli wrote:
Oh, wait.. you mean that if i want, say 35 out of 50 announcement kinds to be logged, then i need to do something like:
logblock := [:announcement | ... ]. announcer on: AnnouncementKind1 do: logblock. announcer on: AnnouncementKind2 do: logblock. .... announcer on: AnnouncementKind35 do: logblock.
? Do you agree that this is far from being short and elegant? Moreover it imposes dependency from various kinds of events, instead of just one (LoggedAnnouncement), and, if i going to change them somehow, i would need to revisit this code again.. and again.
announcer on: AnnouncementKind1 , AnnouncementKind2 , ... AnnouncementKind35 do: logblock
-- Lukas Renggli http://www.lukas-renggli.ch
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
2009/11/1 Stéphane Ducasse <stephane.ducasse@inria.fr>:
you see you find a use of Set :)
IMO, this is a find where you should not use Set :)
Stef
On Nov 1, 2009, at 6:17 PM, Lukas Renggli wrote:
Oh, wait.. you mean that if i want, say 35 out of 50 announcement kinds to be logged, then i need to do something like:
logblock := [:announcement | ... ]. announcer on: AnnouncementKind1 do: logblock. announcer on: AnnouncementKind2 do: logblock. .... announcer on: AnnouncementKind35 do: logblock.
? Do you agree that this is far from being short and elegant? Moreover it imposes dependency from various kinds of events, instead of just one (LoggedAnnouncement), and, if i going to change them somehow, i would need to revisit this code again.. and again.
  announcer     on: AnnouncementKind1 , AnnouncementKind2 , ... AnnouncementKind35     do: logblock
-- Lukas Renggli http://www.lukas-renggli.ch
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
-- Best regards, Igor Stasenko AKA sig.
2009/11/1 Lukas Renggli <renggli@gmail.com>:
Oh, wait.. you mean that if i want, say 35 out of 50 announcement kinds to be logged, then i need to do something like:
logblock := [:announcement | ... ]. announcer on: AnnouncementKind1 do: logblock. announcer on: AnnouncementKind2 do: logblock. .... announcer on: AnnouncementKind35 do: logblock.
? Do you agree that this is far from being short and elegant? Moreover it imposes dependency from various kinds of events, instead of just one (LoggedAnnouncement), and, if i going to change them somehow, i would need to revisit this code again.. and again.
  announcer     on: AnnouncementKind1 , AnnouncementKind2 , ... AnnouncementKind35     do: logblock
good catch. Still dependency on 35 classes .. while my intent is to subscribe to all announcements which can be logged. If i load new package, it could provide more announcements which can be logged. But i will not be able to see them if i'm going to enumerate them in such way :(
-- Lukas Renggli http://www.lukas-renggli.ch
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
-- Best regards, Igor Stasenko AKA sig.
At Sun, 1 Nov 2009 19:35:57 +0200, Igor Stasenko wrote:
2009/11/1 Lukas Renggli <renggli@gmail.com>:
Oh, wait.. you mean that if i want, say 35 out of 50 announcement kinds to be logged, then i need to do something like:
logblock := [:announcement | ... ]. announcer on: AnnouncementKind1 do: logblock. announcer on: AnnouncementKind2 do: logblock. .... announcer on: AnnouncementKind35 do: logblock.
? Do you agree that this is far from being short and elegant? Moreover it imposes dependency from various kinds of events, instead of just one (LoggedAnnouncement), and, if i going to change them somehow, i would need to revisit this code again.. and again.
  announcer     on: AnnouncementKind1 , AnnouncementKind2 , ... AnnouncementKind35     do: logblock
good catch. Still dependency on 35 classes .. while my intent is to subscribe to all announcements which can be logged. If i load new package, it could provide more announcements which can be logged. But i will not be able to see them if i'm going to enumerate them in such way :(
If "can be logged" means to have #canBeLogged method that returns true, you could also say (given that you provide a default implementation of #canBeLogged at a/the root): logblock := [:announcement | announcement canBeLogged ifTrue: [... ]]. announcer on: Announcement do: logblock. Loading a package with new subclasses of Announcement is not a problem. And, a recipient ignoring an announcement that it doesn't handle is somewhat common, when I used my own implementation for my projects. If you implement an observer pattern to accommodate the new package loading requirement, what would be the strategy to implement it? -- Yoshiki
2009/11/1 Yoshiki Ohshima <yoshiki@vpri.org>:
At Sun, 1 Nov 2009 19:35:57 +0200, Igor Stasenko wrote:
2009/11/1 Lukas Renggli <renggli@gmail.com>:
Oh, wait.. you mean that if i want, say 35 out of 50 announcement kinds to be logged, then i need to do something like:
logblock := [:announcement | ... ]. announcer on: AnnouncementKind1 do: logblock. announcer on: AnnouncementKind2 do: logblock. .... announcer on: AnnouncementKind35 do: logblock.
? Do you agree that this is far from being short and elegant? Moreover it imposes dependency from various kinds of events, instead of just one (LoggedAnnouncement), and, if i going to change them somehow, i would need to revisit this code again.. and again.
  announcer     on: AnnouncementKind1 , AnnouncementKind2 , ... AnnouncementKind35     do: logblock
good catch. Still dependency on 35 classes .. while my intent is to subscribe to all announcements which can be logged. If i load new package, it could provide more announcements which can be logged. But i will not be able to see them if i'm going to enumerate them in such way :(
 If "can be logged" means to have #canBeLogged method that returns true, you could also say (given that you provide a default implementation of #canBeLogged at a/the root):
logblock := [:announcement | announcement canBeLogged ifTrue: [... ]]. announcer on: Announcement do: logblock.
i dont want to nitpick , but since you subscribing to the Announcement class, this means that you need to put an extension method #canBeLogged into it. And we started this discussion from question: is Announcements framework is generic enough and won't require more coding. But extending it is already means 'more code' in base.
Loading a package with new subclasses of Announcement is not a problem. Â And, a recipient ignoring an announcement that it doesn't handle is somewhat common, when I used my own implementation for my projects.
 If you implement an observer pattern to accommodate the new package loading requirement, what would be the strategy to implement it?
Not necessarily a new package. The problem is, that i don't want to modify multiple places in system if i reconsider whether something can be logged or not, as well as i want to be sure that my code will handle all and any potential changes in future without the need of any modifications in my code. I think that this part of discussion can be closed. Another question , which Stephane noted already, is the overhead of broadcasting. In Announcer>>announce: it iterating over all subscriptions to determine which one may want to receive an announcement or not. subscriptions keysAndValuesDo: [ :class :actions | (class handles: announcement) ifTrue: [ actions valueWithArguments: (Array with: announcement) ] ]. but if we can't avoid iteration, then why ASKING but not TELLING to handle it: subscriptions do: [ :subscriber | subscriber handle: announcement ]. (subscriptions collection can be just a Set in this case) and then , a particular subscriber could decide whether he interested in given announcement or not, based on own criteria (such as #canBeLogged etc). And surely, we can provide a subscriber class, which can use the same logic, to determine if it interested in particular announcement, based on announcement class. This could make the whole thing more flexible.
-- Yoshiki
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
-- Best regards, Igor Stasenko AKA sig.
Another question , which Stephane noted already, is the overhead of broadcasting.
First of all, announcements are magnitudes faster than the ancient change-update and trigger frameworks. The problem of broadcasting does not apply to announcements, because the observer only registers and receives events he is interested in. Please read the blog posts of Vassily. Lukas -- Lukas Renggli http://www.lukas-renggli.ch
Yes after writing that I thought that it was already based on on:send: so you only broadcast to the person that register.
Another question , which Stephane noted already, is the overhead of broadcasting.
First of all, announcements are magnitudes faster than the ancient change-update and trigger frameworks.
In VW I would have problem to see why this was that slow especially since they clean the update:/changed: to have exactly on:send:....
The problem of broadcasting does not apply to announcements, because the observer only registers and receives events he is interested in.
Please read the blog posts of Vassily.
Lukas
-- Lukas Renggli http://www.lukas-renggli.ch
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
2009/11/1 Lukas Renggli <renggli@gmail.com>:
Another question , which Stephane noted already, is the overhead of broadcasting.
First of all, announcements are magnitudes faster than the ancient change-update and trigger frameworks.
i having zero interest in ancient stuff. This topic is about announcements.
The problem of broadcasting does not apply to announcements, because the observer only registers and receives events he is interested in.
nope. this problem applies to announcements as well. As soon as you having multiple subscribers listening for same event, sending this event to all of them is called broadcasting. Please tell me if this definition is wrong. But in addition, announcer also iterates even over those subscribers who would never want to receive some announcements. I thought that Stephane talking about this overhead, not about some dusty, ancient code which i never seen.
Please read the blog posts of Vassily.
Thanks, i'm already read his blog.
Lukas
-- Lukas Renggli http://www.lukas-renggli.ch
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
-- Best regards, Igor Stasenko AKA sig.
2009/11/1 Igor Stasenko <siguctua@gmail.com>:
2009/11/1 Lukas Renggli <renggli@gmail.com>:
Another question , which Stephane noted already, is the overhead of broadcasting.
First of all, announcements are magnitudes faster than the ancient change-update and trigger frameworks.
i having zero interest in ancient stuff. This topic is about announcements.
The problem of broadcasting does not apply to announcements, because the observer only registers and receives events he is interested in.
nope. this problem applies to announcements as well. As soon as you having multiple subscribers listening for same event, sending this event to all of them is called broadcasting. Please tell me if this definition is wrong.
But in addition, announcer also iterates even over those subscribers who would never want to receive some announcements. I thought that Stephane talking about this overhead, not about some dusty, ancient code which i never seen.
Igor, even if you open a shiny new Pharo image, I'm afraid you'll have to contemplate plenty of ancient code. Note sure the most ancient the most dusty though ;). FIY, st80 MVC was broadcasting to 99% of ignorers with a long chain of this kind: self changed: aSymbol SENT FROM THE MODEL -> self changed:with: --> self changed:with:from: ---> update:with:from: BROADCAST IN EACH dependents (each subview was potentially) --> update:with: -> update: I hope we don't replicate this scheme, I had understood Announcements did not thanks to explicit subscription. Anyway, a bit of archeology is always helpfull when cleaning Smalltalk... Nicolas
Please read the blog posts of Vassily.
Thanks, i'm already read his blog.
Lukas
-- Lukas Renggli http://www.lukas-renggli.ch
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
-- Best regards, Igor Stasenko AKA sig.
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
2009/11/2 Nicolas Cellier <nicolas.cellier.aka.nice@gmail.com>:
2009/11/1 Igor Stasenko <siguctua@gmail.com>:
2009/11/1 Lukas Renggli <renggli@gmail.com>:
Another question , which Stephane noted already, is the overhead of broadcasting.
First of all, announcements are magnitudes faster than the ancient change-update and trigger frameworks.
i having zero interest in ancient stuff. This topic is about announcements.
The problem of broadcasting does not apply to announcements, because the observer only registers and receives events he is interested in.
nope. this problem applies to announcements as well. As soon as you having multiple subscribers listening for same event, sending this event to all of them is called broadcasting. Please tell me if this definition is wrong.
But in addition, announcer also iterates even over those subscribers who would never want to receive some announcements. I thought that Stephane talking about this overhead, not about some dusty, ancient code which i never seen.
Igor, even if you open a shiny new Pharo image, I'm afraid you'll have to contemplate plenty of ancient code. Note sure the most ancient the most dusty though ;).
FIY, st80 MVC was broadcasting to 99% of ignorers with a long chain of this kind: self changed: aSymbol SENT FROM THE MODEL -> self changed:with: --> self changed:with:from: ---> update:with:from: BROADCAST IN EACH dependents (each subview was potentially) --> update:with: -> update:
Oh yeah, i seen that code, and Dependents class var in Object class, which is a dictionary of dictionaries... This model, as well as morphic extensions, takes roots from Self's morphic, where you can easily extend any object state by adding new slots to it. In smalltalk we don't have dynamic named slots, and thus we having such ugly crutches :)
I hope we don't replicate this scheme, I had understood Announcements did not thanks to explicit subscription. Anyway, a bit of archeology is always helpfull when cleaning Smalltalk...
It is strange, i have a feeling that people think i am being short-sighted or don't understand things, while i'm trying to show the potentional bottlenecks of Announcements framework itself...
Nicolas
-- Best regards, Igor Stasenko AKA sig.
Oh yeah, i seen that code, and Dependents class var in Object class, which is a dictionary of dictionaries... This model, as well as morphic extensions, takes roots from Self's morphic, where you can easily extend any object state by adding new slots to it. In smalltalk we don't have dynamic named slots, and thus we having such ugly crutches :)
No it was before that. It was because any object could have a dependent (even if model was favored) so for object the registration was stored in a large table.
I hope we don't replicate this scheme, I had understood Announcements did not thanks to explicit subscription. Anyway, a bit of archeology is always helpfull when cleaning Smalltalk...
It is strange, i have a feeling that people think i am being short-sighted or don't understand things, while i'm trying to show the potentional bottlenecks of Announcements framework itself...
no continue I like to see arguments. Before consensus arise I like discussions because even lukas can be wrong ;D
2009/11/2 Stéphane Ducasse <stephane.ducasse@inria.fr>:
Oh yeah, i seen that code, and Dependents class var in Object class, which is a dictionary of dictionaries... This model, as well as morphic extensions, takes roots from Self's morphic, where you can easily extend any object state by adding new slots to it. In smalltalk we don't have dynamic named slots, and thus we having such ugly crutches :)
No it was before that. It was because any object could have a dependent (even if model was favored) so for object the registration was stored in a large table.
I hope we don't replicate this scheme, I had understood Announcements did not thanks to explicit subscription. Anyway, a bit of archeology is always helpfull when cleaning Smalltalk...
It is strange, i have a feeling that people think i am being short-sighted or don't understand things, while i'm trying to show the potentional bottlenecks of Announcements framework itself...
no continue I like to see arguments. Before consensus arise I like discussions because even lukas can be wrong ;D
I implemented a new announcer, which covers all functionality of the original one (all tests is green) but in addition enables you to subscribe directly via #subscribe: and receive #handle: message in case of announcements. Of course, the decision whether to handle or ignore announcement is up to subscriber. Next thing, which i tried to do is to add weak subscriptions. The syntax, i suggest is simple. As usual, for strong subscription you writing: announcer on: Announce do: [:ann | ... ]. (or any other message pattern) and for weak ones you writing: announcer weak on: Announce do: [:ann | ... ]. so, difference is in #weak keyword standing between announcer and subscription message. I think this is short and elegant, and doesn't forcing developer to learn or use different messages to subscribe weakly. The most powerful thing with weak subscriptions is, that we don't care about unsubscribing - the framework will automatically wipe the subscription entry, once subscriber becomes garbage. But there is a problem with an implementation of block based subscriptions (such as #on:do:). since, in block-based subscriptions, the real subscriber is a block receiver (a 'self' in block's home context) but not a block itself. So, we need to reference the block subscription strongly only if receiver of block is reachable by other means (not via subscription itself). The only way how we could do that withotut much hassle is to use ephemerons, but unfortunately, Squeak VM doesn't supports ephemerons, so support of weak block-based subscriptions is not possible without ugly hacks , like getting inside a block closure and patch its home context state (to get rid of receiver reference).. which is quite awful and error prone.. :(
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
-- Best regards, Igor Stasenko AKA sig.
On Monday, November 2, 2009, Igor Stasenko <siguctua@gmail.com> wrote:
2009/11/2 Stéphane Ducasse <stephane.ducasse@inria.fr>:
Oh yeah, i seen that code, and Dependents class var in Object class, which is a dictionary of dictionaries... This model, as well as morphic extensions, takes roots from Self's morphic, where you can easily extend any object state by adding new slots to it. In smalltalk we don't have dynamic named slots, and thus we having such ugly crutches :)
No it was before that. It was because any object could have a dependent (even if model was favored) so for object the registration was stored in a large table.
I hope we don't replicate this scheme, I had understood Announcements did not thanks to explicit subscription. Anyway, a bit of archeology is always helpfull when cleaning Smalltalk...
It is strange, i have a feeling that people think i am being short-sighted or don't understand things, while i'm trying to show the potentional bottlenecks of Announcements framework itself...
no continue I like to see arguments. Before consensus arise I like discussions because even lukas can be wrong ;D
I implemented a new announcer, which covers all functionality of the original one (all tests is green) but in addition enables you to subscribe directly via #subscribe: and receive #handle: message in case of announcements. Of course, the decision whether to handle or ignore announcement is up to subscriber.
Can you give an example? I don't get it.
Next thing, which i tried to do is to add weak subscriptions.
That's cool, however I would never use (or even provide) functionality depending on broken features. One can easily kill images with weak references on arbitrary objects like subscribers.
The syntax, i suggest is simple. As usual, for strong subscription you writing:
announcer on: Announce do: [:ann | ... Â ]. (or any other message pattern)
and for weak ones you writing:
announcer weak on: Announce do: [:ann | ... Â ].
so, difference is in #weak keyword standing between announcer and subscription message. I think this is short and elegant, and doesn't forcing developer to learn or use different messages to subscribe weakly.
The most powerful thing with weak subscriptions is, that we don't care about unsubscribing - the framework will automatically wipe the subscription entry, once subscriber becomes garbage.
But there is a problem with an implementation of block based subscriptions (such as #on:do:). since, in block-based subscriptions, the real subscriber is a block receiver (a 'self' in block's home context) but not a block itself.
So, we need to reference the block subscription strongly only if receiver of block is reachable by other means (not via subscription itself). The only way how we could do that withotut much hassle is to use ephemerons, but unfortunately, Squeak VM doesn't supports ephemerons, so support of weak block-based subscriptions is not possible without ugly hacks , like getting inside a block closure and patch its home context state (to get rid of receiver reference).. which is quite awful and error prone.. :(
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
-- Best regards, Igor Stasenko AKA sig.
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
-- Lukas Renggli http://www.lukas-renggli.ch
2009/11/2 Lukas Renggli <renggli@gmail.com>:
On Monday, November 2, 2009, Igor Stasenko <siguctua@gmail.com> wrote:
2009/11/2 Stéphane Ducasse <stephane.ducasse@inria.fr>:
Oh yeah, i seen that code, and Dependents class var in Object class, which is a dictionary of dictionaries... This model, as well as morphic extensions, takes roots from Self's morphic, where you can easily extend any object state by adding new slots to it. In smalltalk we don't have dynamic named slots, and thus we having such ugly crutches :)
No it was before that. It was because any object could have a dependent (even if model was favored) so for object the registration was stored in a large table.
I hope we don't replicate this scheme, I had understood Announcements did not thanks to explicit subscription. Anyway, a bit of archeology is always helpfull when cleaning Smalltalk...
It is strange, i have a feeling that people think i am being short-sighted or don't understand things, while i'm trying to show the potentional bottlenecks of Announcements framework itself...
no continue I like to see arguments. Before consensus arise I like discussions because even lukas can be wrong ;D
I implemented a new announcer, which covers all functionality of the original one (all tests is green) but in addition enables you to subscribe directly via #subscribe: and receive #handle: message in case of announcements. Of course, the decision whether to handle or ignore announcement is up to subscriber.
Can you give an example? I don't get it.
you can subscribe using: announcer subscribe: object. and unsubscribe using: announcer unsubscribe: object. the argument 'object' should be responsible for implementing #handle: message which will receive all announcements from announcer, unfiltered. The rest of Announcer protocol (used by Announcements framework) built on top of it, as a superset.
Next thing, which i tried to do is to add weak subscriptions.
That's cool, however I would never use (or even provide) functionality depending on broken features.
Please, can you elaborate, what you consider 'broken features' and why? I am also not a fan of using flawed stuff. That's why i talking about limitations of weak block subscriptions. While weak message subscriptions is easy to provide, using WeakMessageSend.
One can easily kill images with weak references on arbitrary objects like subscribers.
true, as well as zillion other ways how you can shoot yourself in own foot. Nobody forcing one to use weak subscriptions, right? And if he does, its his own responsibility to make sure it working ok, not mine.
The syntax, i suggest is simple. As usual, for strong subscription you writing:
announcer on: Announce do: [:ann | ... Â ]. (or any other message pattern)
and for weak ones you writing:
announcer weak on: Announce do: [:ann | ... Â ].
so, difference is in #weak keyword standing between announcer and subscription message. I think this is short and elegant, and doesn't forcing developer to learn or use different messages to subscribe weakly.
The most powerful thing with weak subscriptions is, that we don't care about unsubscribing - the framework will automatically wipe the subscription entry, once subscriber becomes garbage.
But there is a problem with an implementation of block based subscriptions (such as #on:do:). since, in block-based subscriptions, the real subscriber is a block receiver (a 'self' in block's home context) but not a block itself.
So, we need to reference the block subscription strongly only if receiver of block is reachable by other means (not via subscription itself). The only way how we could do that withotut much hassle is to use ephemerons, but unfortunately, Squeak VM doesn't supports ephemerons, so support of weak block-based subscriptions is not possible without ugly hacks , like getting inside a block closure and patch its home context state (to get rid of receiver reference).. which is quite awful and error prone.. :(
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
-- Best regards, Igor Stasenko AKA sig.
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
-- Lukas Renggli http://www.lukas-renggli.ch
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
-- Best regards, Igor Stasenko AKA sig.
I implemented a new announcer, which covers all functionality of the original one (all tests is green) but in addition enables you to subscribe directly via #subscribe: and receive #handle: message in case of announcements. Of course, the decision whether to handle or ignore announcement is up to subscriber.
Can you give an example? I don't get it.
you can subscribe using:
announcer subscribe: object.
and unsubscribe using:
announcer unsubscribe: object.
Ok, now I get it. I wonder why this would be useful? Also it looks to me like very bad programming style, as the specification of what to handle and the handler itself are merged. You can do that also with the original API, but it is less encouraging because you have to hand in twice the same object into #on:do:. Also, have a look at the Exception API. Announcements solve a similar problem and provide a similar API. It would be a pity to break that similarity. I've never seen a single project that extended the exception API, there the simple message #on:do: is enough for everybody.
Please, can you elaborate, what you consider 'broken features' and why? I am also not a fan of using flawed stuff.
Weak objects are flawed in Pharo and Squeak. If you have an unbounded number of weak references it can quickly happen that the system spends 95% or more of the CPU cleaning up the weak references. For Seaside 2.8 we spent quite some time in getting rid of all weak references, afterwards we had a cleaner, easier to understand and much faster solution.
That's why i talking about limitations of weak block subscriptions. While weak message subscriptions is easy to provide, using WeakMessageSend.
I guess you could copy the BlockClosure, no? Lukas -- Lukas Renggli http://www.lukas-renggli.ch
2009/11/2 Lukas Renggli <renggli@gmail.com>:
I implemented a new announcer, which covers all functionality of the original one (all tests is green) but in addition enables you to subscribe directly via #subscribe: and receive #handle: message in case of announcements. Of course, the decision whether to handle or ignore announcement is up to subscriber.
Can you give an example? I don't get it.
you can subscribe using:
announcer subscribe: object.
and unsubscribe using:
announcer unsubscribe: object.
Ok, now I get it.
I wonder why this would be useful?
Also it looks to me like very bad programming style, as the specification of what to handle and the handler itself are merged.
there is no specification what to handle, because in my implementation the Announcer doesn't having any knowledge about nature of subscriptions. Its only task is to broadcast the announcement to all subscribers without any extraneous logic - consider an observer pattern in its purest form. Then there are a special kind of subscription, which handling announcements in style which were originally made for Announcer. And finally, i could turn your own argument back to you: why its Announcement deciding whether subscriber interested in it or not, by implementing checks in #handles: method at class side? Isn't this a mixing of 'what to handle' and 'handler' roles?
You can do that also with the original API, but it is less encouraging because you have to hand in twice the same object into #on:do:.
passing twice? I think you meant passing once, i.e.: announcer on: Announcement do: self which can be a roughly equivalent to announcer subcscribe: self. except that this case you will need to implement own #valueWithArguments: and #receiver methods while in my variant - #handle: , and except that current framework will do unnecessary #isKindOf: checks before delivering announcement to such handler.
Also, have a look at the Exception API. Announcements solve a similar problem and provide a similar API. It would be a pity to break that similarity. I've never seen a single project that extended the exception API, there the simple message #on:do: is enough for everybody.
but there is #on:do:! So, if one think its enough for him - no problem just use it, and forget about #subscribe:. How it breaks the similarity (which i find good myself btw), when it providing same functionality as current one? By enabling more generic form of subscription? Oh cmon...
Please, can you elaborate, what you consider 'broken features' and why? I am also not a fan of using flawed stuff.
Weak objects are flawed in Pharo and Squeak. If you have an unbounded number of weak references it can quickly happen that the system spends 95% or more of the CPU cleaning up the weak references. For Seaside 2.8 we spent quite some time in getting rid of all weak references, afterwards we had a cleaner, easier to understand and much faster solution.
i don't expect too many subscribers to a single announcer (do you?), and the number of weak ones could be even less than that. I think that if announcer keeps more than 10-20 subscribers, it will already a signal that you start abusing framework. :) So i don't think that cleaning it up will be an issue or bottleneck in this case. And of course i am aware of potential pitfalls of weak finalization in squeak. But hey: we don't care about managing memory in smalltalk, why we should abandon idea to have an automatically managed weak subscriptions? Since you usually never send #dispose/#free for each corresponding #new, it is logical to have an option to never send #unsubscribe: for each corresponding #subscribe: , isnt? It imples some discipline? Yeah. As well as #new does, because if you attempt to allocate memory in a run-away fashion, you will end-up with memory overflow.
That's why i talking about limitations of weak block subscriptions. While weak message subscriptions is easy to provide, using WeakMessageSend.
I guess you could copy the BlockClosure, no?
This will give nothing. The problem that BlockClosure holding all references strongly, as well as any context object. And even worse - the real subscriber (our object of interest) is not held directly by a closure, but by its home context object. And there is no guarantees that given context's state keeps reference to subscriber only in 'receiver' slot. It could be kept in temps or temps could reference the receiver etc etc. And you can't hold a BlockClosure weakly, because it will vanish once you exit from #on:do: method. So, the only solution is to keep it strongly as long as receiver are referenced strongly by something outside the BlockClosure references subgraph. This is what ephemeron does, but its impossible to implement using weak refs.
Lukas
-- Lukas Renggli http://www.lukas-renggli.ch
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
-- Best regards, Igor Stasenko AKA sig.
At Mon, 2 Nov 2009 19:18:09 +0100, Lukas Renggli wrote:
Please, can you elaborate, what you consider 'broken features' and why? I am also not a fan of using flawed stuff.
Weak objects are flawed in Pharo and Squeak. If you have an unbounded number of weak references it can quickly happen that the system spends 95% or more of the CPU cleaning up the weak references. For Seaside 2.8 we spent quite some time in getting rid of all weak references, afterwards we had a cleaner, easier to understand and much faster solution.
Just to be clear. Is it because the need to process the dictionary that registers the objects needs to be finalized, right? For this case, these subscriptions objects don't have to be finalized, I think. The subscriber holds onto a WeakArray of size one, and the element just becomes nil. And when announcing something, you can just skip (and remove) subscription objects who have nil subscribers. Or, is there actually a problem just having weak arrays? -- Yoshiki
2009/11/2 Yoshiki Ohshima <yoshiki@vpri.org>:
At Mon, 2 Nov 2009 19:18:09 +0100, Lukas Renggli wrote:
Please, can you elaborate, what you consider 'broken features' and why? I am also not a fan of using flawed stuff.
Weak objects are flawed in Pharo and Squeak. If you have an unbounded number of weak references it can quickly happen that the system spends 95% or more of the CPU cleaning up the weak references. For Seaside 2.8 we spent quite some time in getting rid of all weak references, afterwards we had a cleaner, easier to understand and much faster solution.
 Just to be clear.  Is it because the need to process the dictionary that registers the objects needs to be finalized, right?  For this case, these subscriptions objects don't have to be finalized, I think.  The subscriber holds onto a WeakArray of size one, and the element just becomes nil.  And when announcing something, you can just skip (and remove) subscription objects who have nil subscribers.
Yes.. i came to same conclusion and started implementing it, but then backstabbed with impossibility to make block-based subscriptions weak. :) Since we expect that eventually there will be a new announcement, we could wipe weak entries during this cycle. Keeping a garbage entries until new announcement will come don't seem to be a big problem.
 Or, is there actually a problem just having weak arrays?
No, i think the main issue is an overhead of squeak's finalization logic.
-- Yoshiki
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
-- Best regards, Igor Stasenko AKA sig.
Igor, even if you open a shiny new Pharo image, I'm afraid you'll have to contemplate plenty of ancient code. Note sure the most ancient the most dusty though ;).
FIY, st80 MVC was broadcasting to 99% of ignorers with a long chain of this kind: self changed: aSymbol SENT FROM THE MODEL -> self changed:with: --> self changed:with:from: ---> update:with:from: BROADCAST IN EACH dependents (each subview was potentially) --> update:with: -> update:
I hope we don't replicate this scheme, I had understood Announcements did not thanks to explicit subscription.
as did the later versions in VW. SOrry that I raised this question. Typing too fast
Anyway, a bit of archeology is always helpfull when cleaning Smalltalk...
On Sun, Nov 01, 2009 at 10:07:59PM +0100, Lukas Renggli wrote:
Another question , which Stephane noted already, is the overhead of broadcasting.
First of all, announcements are magnitudes faster than the ancient change-update and trigger frameworks.
Is this true? I would expect announcements to be magnitudes faster than the trigger framework, and similar in performance to change-update. Dave
At Sun, 1 Nov 2009 20:22:48 +0200, Igor Stasenko wrote:
 If "can be logged" means to have #canBeLogged method that returns true, you could also say (given that you provide a default implementation of #canBeLogged at a/the root):
logblock := [:announcement | announcement canBeLogged ifTrue: [... ]]. announcer on: Announcement do: logblock.
i dont want to nitpick , but since you subscribing to the Announcement class, this means that you need to put an extension method #canBeLogged into it.
And we started this discussion from question: is Announcements framework is generic enough and won't require more coding. But extending it is already means 'more code' in base.
Well, I said "if". And if you really don't want to have an extension method in the base, you can say something like: (announcement instVarNames includes: 'canBeLogged') ifTrue: [...] or any other ways that don't require an extension method in the core. The point was that you don't have to have all 35 classes listed upfront.
Loading a package with new subclasses of Announcement is not a problem. Â And, a recipient ignoring an announcement that it doesn't handle is somewhat common, when I used my own implementation for my projects.
 If you implement an observer pattern to accommodate the new package loading requirement, what would be the strategy to implement it?
Not necessarily a new package. The problem is, that i don't want to modify multiple places in system if i reconsider whether something can be logged or not, as well as i want to be sure that my code will handle all and any potential changes in future without the need of any modifications in my code.
Ok... But announcement or not, you need a way to tell a notification "can be logged".
Another question , which Stephane noted already, is the overhead of broadcasting.
In Announcer>>announce: it iterating over all subscriptions to determine which one may want to receive an announcement or not.
subscriptions keysAndValuesDo: [ :class :actions | (class handles: announcement) ifTrue: [ actions valueWithArguments: (Array with: announcement) ] ].
but if we can't avoid iteration, then why ASKING but not TELLING to handle it:
subscriptions do: [ :subscriber | subscriber handle: announcement ].
(subscriptions collection can be just a Set in this case) and then , a particular subscriber could decide whether he interested in given announcement or not, based on own criteria (such as #canBeLogged etc).
And surely, we can provide a subscriber class, which can use the same logic, to determine if it interested in particular announcement, based on announcement class. This could make the whole thing more flexible.
But the client side code will be more messy. An object will have only one implementation of #handle:, and whenever you want to add a new thing to be handled by the object, it ends up with adding a new if clauses inside it. (Something more flexible and loose-coupling than Announcement would be really good, I agree.) -- Yoshiki
2009/11/2 Yoshiki Ohshima <yoshiki@vpri.org>:
At Sun, 1 Nov 2009 20:22:48 +0200, Igor Stasenko wrote:
 If "can be logged" means to have #canBeLogged method that returns true, you could also say (given that you provide a default implementation of #canBeLogged at a/the root):
logblock := [:announcement | announcement canBeLogged ifTrue: [... ]]. announcer on: Announcement do: logblock.
i dont want to nitpick , but since you subscribing to the Announcement class, this means that you need to put an extension method #canBeLogged into it.
And we started this discussion from question: is Announcements framework is generic enough and won't require more coding. But extending it is already means 'more code' Â in base.
 Well, I said "if".  And if you really don't want to have an extension method in the base, you can say something like:
 (announcement instVarNames includes: 'canBeLogged') ifTrue: [...]
or any other ways that don't require an extension method in the core. The point was that you don't have to have all 35 classes listed upfront.
yes.
Loading a package with new subclasses of Announcement is not a problem. Â And, a recipient ignoring an announcement that it doesn't handle is somewhat common, when I used my own implementation for my projects.
 If you implement an observer pattern to accommodate the new package loading requirement, what would be the strategy to implement it?
Not necessarily a new package. The problem is, that i don't want to modify multiple places in system if i reconsider whether something can be logged or not, as well as i want to be sure that my code will handle all and any potential changes in future without the need of any modifications in my code.
 Ok... But announcement or not, you need a way to tell a notification "can be logged".
Sure thing.
Another question , which Stephane noted already, is the overhead of broadcasting.
In Announcer>>announce: it iterating over all subscriptions to determine which one may want to receive an announcement or not.
   subscriptions keysAndValuesDo: [ :class :actions |        (class handles: announcement)            ifTrue: [ actions valueWithArguments: (Array with: announcement) ] ].
but if we can't avoid iteration, then why ASKING but not TELLING to handle it:
   subscriptions do: [ :subscriber | subscriber handle: announcement ].
(subscriptions collection can be just a Set in this case) and then , a particular subscriber could decide whether he interested in given announcement or not, based on own criteria (such as #canBeLogged etc).
And surely, we can provide a subscriber class, which can use the same logic, to determine if it interested in particular announcement, based on announcement class. This could make the whole thing more flexible.
 But the client side code will be more messy.  An object will have only one implementation of #handle:, and whenever you want to add a new thing to be handled by the object, it ends up with adding a new if clauses inside it.
the #handle: is an entry point, where subscriber could decide what to do with announcement. And of course, you can introduce messy testing code if you need. But its up to you, not up to Announcement framework. See the difference? My point is, that #isKindOf: test is not always single one or best one, which can be used to test the relevance of announcement to subscriber. We having a Traits, right? Now imagine that i could control, whether announcement can be logged or not, by simply using or not using a trait in my announcement subclasses. It can be even a trait with no methods, but i can use this information to check if given announcement is relevant to my subscriber. And as result: zero new methods, no extensions to core and very convenient way to promote announcement to be a logged one. Just one requirement: give me a way to define own means to check the relevance to subscriber :)
 (Something more flexible and loose-coupling than Announcement would be really good, I agree.)
-- Yoshiki
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
-- Best regards, Igor Stasenko AKA sig.
Yes for weak, I agree for set may be some people use that. Now I would like to hear levente usage of announcement. And igor having a simple but COMMON infrastructure is important so we need the core. Now I would also like to know the cost of always broadcasting. I do not remember correctly but in vassili'blog there were some points to avoid that. Because in the past, in Smalltalk the dependency where broadcasting to all the dependents and this was inadequate and after they introduce on:when:..... to get only the right listener updated. Stef On Oct 31, 2009, at 11:18 PM, Lukas Renggli wrote:
In current core image, Announcements is quite small (just around 10 methods totally) and i doubt it provides enough flexibility which would not require adding & reinventing additional useful stuff on top of it.
I have used these announcements in many large projects and I never needed to add anything. In fact, I would even vote to remove AnnouncementSet as I never used it or saw it used anywhere. Initially, I found it cool because the same trick is applied in the Exception hierarchy. Major projects like OmniBrowser (and to some extent also Seaside) use an even smaller subset of the functionality provided in the core package.
The only thing that is maybe missing are weak announcements. I guess that could be useful, if Pharo provided a solid implementation of weak objects.
Lukas
-- Lukas Renggli http://www.lukas-renggli.ch
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
Now I would also like to know the cost of always broadcasting. I do not remember correctly but in vassili'blog there were some points to avoid that. Because in the past, in Smalltalk the dependency where broadcasting to all the dependents and this was inadequate and after they introduce on:when:..... to get only the right listener updated.
Yes, broadcasting was the reason why OBPackageBrowser was slow before we refactored it. Mondrian and OBPackageBrowser are happy with the current Announcement infrastructure. Cheers, Alexandre
On Oct 31, 2009, at 11:18 PM, Lukas Renggli wrote:
In current core image, Announcements is quite small (just around 10 methods totally) and i doubt it provides enough flexibility which would not require adding & reinventing additional useful stuff on top of it.
I have used these announcements in many large projects and I never needed to add anything. In fact, I would even vote to remove AnnouncementSet as I never used it or saw it used anywhere. Initially, I found it cool because the same trick is applied in the Exception hierarchy. Major projects like OmniBrowser (and to some extent also Seaside) use an even smaller subset of the functionality provided in the core package.
The only thing that is maybe missing are weak announcements. I guess that could be useful, if Pharo provided a solid implementation of weak objects.
Lukas
-- Lukas Renggli http://www.lukas-renggli.ch
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
-- _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: Alexandre Bergel http://www.bergel.eu ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.
Now I would also like to know the cost of always broadcasting. I do not remember correctly but in vassili'blog there were some points to avoid that.
Yes, broadcasting was the reason why OBPackageBrowser was slow before we refactored it.
Actually, the sloppiness came from the handlers associated to events. They generated way too many refreshes. Broadcasting events did not appear to be that slow. Users of an event mechanism have the tendencies to broadcast events more than it should be. Alexandre
On Oct 31, 2009, at 11:18 PM, Lukas Renggli wrote:
In current core image, Announcements is quite small (just around 10 methods totally) and i doubt it provides enough flexibility which would not require adding & reinventing additional useful stuff on top of it.
I have used these announcements in many large projects and I never needed to add anything. In fact, I would even vote to remove AnnouncementSet as I never used it or saw it used anywhere. Initially, I found it cool because the same trick is applied in the Exception hierarchy. Major projects like OmniBrowser (and to some extent also Seaside) use an even smaller subset of the functionality provided in the core package.
The only thing that is maybe missing are weak announcements. I guess that could be useful, if Pharo provided a solid implementation of weak objects.
Lukas
-- Lukas Renggli http://www.lukas-renggli.ch
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
-- _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: Alexandre Bergel http://www.bergel.eu ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.
-- _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: Alexandre Bergel http://www.bergel.eu ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.
participants (12)
-
Alain Plantec -
Alexandre Bergel -
Cédrick Béler -
David T. Lewis -
François Tanguy -
Igor Stasenko -
Levente Uzonyi -
Lukas Renggli -
Nicolas Cellier -
Stéphane Ducasse -
Tudor Girba -
Yoshiki Ohshima