On 18 juil. 05, at 19:58, Andreas Raab wrote:
[*1] Try browsing the sender of some message or a class - you will very quickly notice why I don't like the usage of "AppRegistry default" since it raises completely needless errors when for example trying to browse a class -- compare this with the notifier you get when trying to browse a selector which uses ToolSet's interpretation of "proper" AppRegistry behavior.
So we will have to fix that.
Actually, the above note related to a message that I sent to Squeak- dev about the general use of AppRegistry but it seems like the list is dead for now. I'm attaching it for reference.
There are too much other lists. I would prefer to have only one mailing-list instead of packages,.... because it gives a wrong feeling that nothing is happening.
http://www.impara.de/~andreas/iSqueak/3.8/PlusTools-ar.16.mcz [300k]
Ok so you already did it ;). So I would suggest that we only use this one. :)
Well, there are a few things missing and originally I needed the PlusTools to figure out how to go about unloading and dealing with the regular tools. The PlusTools *definitely* need some more work, what I've done covers the basics but there are plenty of things that still need to be fixed.
I thought that there was a version of MC UI was relying on ToolBuilder.
Yes, there is. I'm planning to use it for Tweak.
- Refactoring of ChangeSet and ChangeSorter - all of the actual
I do not have the time right now to look at it but did you change the notification mechanism? I'm curious to see how the decoupling offered by the notification mechanism helps.
I simply separated the functionality of dealing with changes from the user interface (ChangeSorter). Mostly it meant moving class methods from ChangeSorter to ChangeSet and then fix patterns like "ChangeSorter changeSetNamed: ..." to use "ChangeSet named: ...".
Cheers,
- Andreas
From: Andreas Raab andreas.raab@gmx.de Date: 17 juillet 2005 19:31:35 GMT+02:00 To: The general-purpose Squeak developers list <squeak- dev@lists.squeakfoundation.org> Subject: On AppRegistry and its use
Folks,
I have started to use AppRegistry for a significantly sized project and found and stumbled across a few odditities which I'd like to see addressed.
Most importantly, AppRegistry typically does not provide a user with even a hint about the interface that's expected. If you look at MailSender you can see its interface but for most of the others this is not true. That's problematic since we cannot simply create a new kind of app but rather need to find the original and faithfully copy its interface. If the original's interface changes (such as just happened for MailSender) it breaks other apps (MAPIClient for example) without even so much as a hint that the expected interface for that app has changed.
Secondly, AppRegistry has an obnoxiuous habit of telling the user every time anyone asks that there are "no applications registered". It is possible to ask for the default without that but then the client needs to handle the default choice itself. Thus instead of
(WebBrowser default ifNil: [^self]) doSomething.
(resulting in the obnoxious "no webbrowsers registered") one would need to write:
(WebBrowser defaultOrNil == nil and:[WebBrowser
registeredClasses isEmpty]) ifTrue:[^self]. WebBrowser default doSomething.
It seems to me that AppRegistry would be more useful if it weren't used at all with the above "AppRegistry default" pattern but rather by, e.g.,
AppRegistry doSomething.
(without the "default") This serves the following purposes:
a) We are required to state the expected protocol for the app so if anyone else wants to implement a new kind of app she knows what is expected.
b) An application can implement the action appropriately depending on what is specifically requested in one of the following ways:
- silently substitute a suitable default if possible, e.g.,
WebBrowser class>>openOn: url self default ifNil:[ ^(StringHolder new contents: url retrieveContents) openLabel: url asString. ]. self default openOn: url.
- Give the user information about the fact it is missing, e.g.,
WebBrowser class>>openOn: url self default ifNil:[^self inform: 'No WebBrowser present']. self default openOn: url.
- raise an error if the requested service is crucial
WebBrowser class>>openUn: url self default ifNil:[^self error: 'Where is the web browser']. self default openOn: url.
c) There is no reason for AppRegistry>>default to give any warning whatsoever. Client code can use "AppRegistry default" to bypass the error handling provided the specific application and therefore the user need not be bothered with all of these notifications.
I had the need for pretty much all of the above and would like to see AppRegistry fixed in the way described above.
Comments?
Cheers,
- Andreas