>> 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? Lukas -- Lukas Renggli www.lukas-renggli.ch
