Packaging the programming tools

[stéphane ducasse]

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 at gmx.de>
> Date: 17 juillet 2005 19:31:35 GMT+02:00
> To: The general-purpose Squeak developers list <squeak- 
> dev at 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
>
>
>
>