it would certainly save time from navigating through methods that more or less do the same thing. And of course dummy methods that they are there just to facilitate for less arguments.
On Wed, Jan 20, 2016 at 7:42 PM Cyril Ferlicot D. <cyril.ferli...@gmail.com> wrote: > Le 20/01/2016 16:08, Damien Cassou a écrit : > > Hi, > > > > I would like to study the impact of adding optional parameters to > > keyword methods in Pharo. The goal of optional parameters is to > > facilitate the implementation of methods where some parameters are > > optional. For example, Seaside has: > > > > WAComponent>>request: aRequestString label: aLabelString > > default: aDefaultString onAnswer: aBlock > > > > ... > > > > This method of 4 arguments has only 1 required argument (aRequestString) > > and 3 optional ones. In the current implementation, this results in 7 > > additional methods that only delegate directly or indirectly to the one > > above: > > > > - request: > > - request:default: > > - request:default:onAnswer: > > - request:label: > > - request:label:default: > > - request:label:onAnswer: > > - request:onAnswer: > > > > Before starting to implement anything, I need to know if it makes sense. > > If you want to help me, please send me all the use cases you have by > > giving me: > > > > - the library name (and URL if not in Catalog), or "pharo" if it's in > > Pharo > > - the class where this happens > > - the range of selectors that make sense > > > > For the example above, this would be: > > > > - Seaside > > - WAComponent > > - request:* > > > > > > Thank you very much > > > > Hi Damien, > > There is a lot of optional parameters in the UIManager. > > Package: UIManager (pharo) > > Classes: UIManager and subclasses > > Selectors: > > - chooseFrom:* > - reguest:* > - … > > Almost all the methods have optional parameters. > > -- > Cyril Ferlicot > > http://www.synectique.eu > > 165 Avenue Bretagne > Lille 59000 France > >
