[ANN] DynamicProtocols version 28

> Hi,
>
> since the first release (10 days ago), a lot has changed in  
> DynamicProtocols. A description of DynamicProtocols is written at  
> the end of the mail.
>
> Changes:
> --------
>
> - Use Preferences Browser to set the desired protocols
> - Implement more protocols (uncommented methods, long methods,
>    duplicated...)
> - Correct lots of bugs
> - Use a progress bar to show the calculation process
> - Use a cache to avoid unnecessary calculations
> - Refactorings
> - ...
>
>
> Future work:
> ------------
>
> - Let the protocols define some new preferences (length of the  
> method to
>   be considered long for example).
> - Add a preference to enable/disable the progress bar
> - Add the required protocol (seems there is a problem in 3.9)
> - Add new protocols (give me ideas please)
>
>
> Description:
> ------------
>
> A dynamic protocol is a category (displayed in the 3rd pane of your  
> browser) whose content is computed dynamically based on the  
> currently selected class. If a dynamic protocol is empty then it is  
> not shown.
>
> This system is based on an idea of Nathanael Shärli and Andrew P.  
> Black (see 'A Browser For Incremental Programming')
>
> Here is a small list of possible dynamic protocols:
>
> - HaltUsage: displays all methods containing a call to #halt
> - Override: contains methods that are defined in the superclasses  
> and redefined in the current class
> - RecentlyModified, SuperSend...
>
> --
> Damien Cassou
>
>

> For the number of dynamic protocols, I have some ideas:
> - have a preference system to activate/desactivate the protocol you  
> want (already done)
> - separate protocols in different independent packages (one for  
> lint protocols, one for good programming style protocols...)
>
> Other ideas ?
>
> --
> Damien Cassou
>
>

>> Can you explain what is the problem with preferences ?
>
> I will try :)
>
> Putting a preference is often a lack of decision. (i'm talking about
> overuse of preferences here)
> Preferences are kind of global variables and the logic is often not that
> cool.
> They often seems to me like an easy way to avoid consistency and
> discussion to reach that point.
> So in general I would prefer a better (mean more consistent feel for
> example in the UI)
> than having a preference. Preferences on mac for examples are more for
> default information
> you fill in.
>
> But preferences are difficult because they arrive when an application is
> mature and need configuration.
> Eclipse is facing the same. So my first reaction is general is to be
> skeptical.