Hi, On 17 Jul 2011, at 22:35, Lukas Renggli wrote:
>>> This behavior is used in OB to warn the user about an unsaved method >>> and potentially abort the announcement processing. But then again, >>> this will never work with the new Pharo announcements, because the >>> handlers are stored in an IdentitySet and are executed in random order >>> anyway. >> >> ok but if you do not say it how can we improve? >> So now we learned that using an identitySet was a bad idea. >> You see if you would have given information when you got the problems >> we would have probably fixed everything. > > The new implementation is so complicated, I only start to understand > all implications now. People were telling me how cool and how > important the new implementation is, so I thought I better take my own > 3-method/2-class implementation that does exactly what was needed. > >>> - Any UI tool that does interactions and queries through exception >>> processing: OB, users of UIManager, MenuMorph, ... >> >> OB I know but this is notification, no? > > Yes, these are notifications. > >> UIManager? really for the progressNotification? > > ProvideAnswerNotification. > > And yes, there is also ProgressInitiationException for the progress > bar, which is not a Notification. > >> MenuMorph is using Exception? > > Yes. > > Just look at the subclasses of Exception and ask yourself which one > people are commonly handling. ZeroDivide, FileDoesNotExistException, > MessageNotUnderstood, ConnectionTimedOut, ProgressInitiationException, > ... are all Exceptions, some of them are resumable. > >>> Now this is not really a big deal for me, OB works perfectly in Pharo >>> 1.3 with its own "old" announcement implementation. >> >> this is not the point. We want to make the infrastructure really good. >> So we will fix that but for that we need inputs. >> If everybody "fixes" his stuff in his corner then we should better stop >> pharo. >> >>> It is just that everybody should be aware of the problem and have its own >>> "simple" >>> announcements when using any of the frameworks above. >> >> you know that this is not the good solution. So probably it was a bad idea >> to catch >> everything and probably UnhandledError is a better choice. >> Now again without feedback we will just progress but much slower. > > IMHO, the goal of Pharo should be to provide a minimal Smalltalk > system where people Pharo can load what they need. Instead Pharo keeps > on growing. I would prefer a system where I can decide myself what > libraries and tools I want to use. I am sure that the current > Announcement implementation can be fixed, but does it really make > sense that the core team bothers about something that could be > external? I think it makes a lot of sense. I like very much what the core team is doing. I really do not see how Pharo is growing. I think it is getting more solid, and more modular every day. Yes, there are bumps along the way, but this is why feedback is so important. The Announcement system is very much internal because it is supposed to be used by the core to announce when something changes, and by the IDE to refresh. And yes, the IDE should should be in the feedback loop of the Core development, because it is a critical component. Cheers, Doru > Lukas > > -- > Lukas Renggli > www.lukas-renggli.ch > -- www.tudorgirba.com "Value is always contextual."
