Use cases for methods with optional parameters
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 -- Damien Cassou http://damiencassou.seasidehosting.st "Success is the ability to go from one failure to another without losing enthusiasm." --Winston Churchill
Hi, As a newbie, without a clear idea of where to apply this specifically I can say that seems pretty interesting. I have methods with several parameters (may be product of my newbie code), but making them optional seems an idea worthy to explore. Cheers, Offray On 20/01/16 10:08, Damien Cassou wrote:
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
2016-01-20 14:01 GMT-03:00 Offray Vladimir Luna Cárdenas <offray@riseup.net>:
Hi,
As a newbie, without a clear idea of where to apply this specifically I can say that seems pretty interesting. I have methods with several parameters (may be product of my newbie code), but making them optional seems an idea worthy to explore.
Cheers,
In a pure object oriented approach, if you have a lot of varying parameters is a sign that you might need to reify the parameters as a first class object, i.e. "SomethingParameters" class or similar, then instead of passing 1...n objects that will work as parameters you only pass one object, aSomethingParameters. Of course it adds more friction to something that maybe the language could provide, but in Smalltalk everything is explicit. I would be interested in the use cases and how to deal with "undefined" arguments, will they be nil or other kind of undefined object? Regards! Esteban A. Maringolo
On 20 Jan 2016, at 6:14 , Esteban A. Maringolo <emaringolo@gmail.com> wrote:
I would be interested in the use cases and how to deal with "undefined" arguments, will they be nil or other kind of undefined object?
Regards!
Esteban A. Maringolo
Perhaps request: aFile with: anotherThing and: aThirdThing <optionalParameter: anotherThing "default: nil"> <optionalParameter: aThirdThing default: defaultThirdThing> -> request: aFile with: anotherThing ^self request: aFile with: anotherThing and: self defaultThirdThing request: aFile and:: aThirdThing ^self request: aFile with: nil and: self aThirdThing request: aFile ^self request: aFile with: nil and: self defaultThirdThing ? Cheers, Henry
how about syntax like this openFile: aPath (optionalArgumentA: anArgument optionalArgumentB: anArghument) On Thu, Jan 21, 2016 at 1:39 PM Henrik Johansen < henrik.s.johansen@veloxit.no> wrote:
On 20 Jan 2016, at 6:14 , Esteban A. Maringolo <emaringolo@gmail.com> wrote:
I would be interested in the use cases and how to deal with "undefined" arguments, will they be nil or other kind of undefined object?
Regards!
Esteban A. Maringolo
Perhaps
request: aFile with: anotherThing and: aThirdThing <optionalParameter: anotherThing "default: nil"> <optionalParameter: aThirdThing default: defaultThirdThing> -> request: aFile with: anotherThing ^self request: aFile with: anotherThing and: self defaultThirdThing request: aFile and:: aThirdThing ^self request: aFile with: nil and: self aThirdThing request: aFile ^self request: aFile with: nil and: self defaultThirdThing
?
Cheers, Henry
2016-01-21 8:38 GMT-03:00 Henrik Johansen <henrik.s.johansen@veloxit.no>:
On 20 Jan 2016, at 6:14 , Esteban A. Maringolo <emaringolo@gmail.com> wrote:
I would be interested in the use cases and how to deal with "undefined" arguments, will they be nil or other kind of undefined object?
Perhaps
request: aFile with: anotherThing and: aThirdThing <optionalParameter: anotherThing "default: nil"> <optionalParameter: aThirdThing default: defaultThirdThing> -> request: aFile with: anotherThing ^self request: aFile with: anotherThing and: self defaultThirdThing request: aFile and:: aThirdThing ^self request: aFile with: nil and: self aThirdThing request: aFile ^self request: aFile with: nil and: self defaultThirdThing
The pragma for the default unless it's a literal object it should be a message send. I still have to see a good use case that could justify the use of that. Because it also involves the message lookup, which AFAIK is performed by the VM. Regards, Esteban A. Maringolo
This would be nice to be able to use several different languages "ways of doing things" that would translate into message sends behind the scenes. Helvetia story... Phil On Thu, Jan 21, 2016 at 6:04 PM, Esteban A. Maringolo <emaringolo@gmail.com> wrote:
2016-01-21 8:38 GMT-03:00 Henrik Johansen <henrik.s.johansen@veloxit.no>:
On 20 Jan 2016, at 6:14 , Esteban A. Maringolo <emaringolo@gmail.com>
wrote:
I would be interested in the use cases and how to deal with "undefined" arguments, will they be nil or other kind of undefined object?
Perhaps
request: aFile with: anotherThing and: aThirdThing <optionalParameter: anotherThing "default: nil"> <optionalParameter: aThirdThing default: defaultThirdThing> -> request: aFile with: anotherThing ^self request: aFile with: anotherThing and: self defaultThirdThing request: aFile and:: aThirdThing ^self request: aFile with: nil and: self aThirdThing request: aFile ^self request: aFile with: nil and: self defaultThirdThing
The pragma for the default unless it's a literal object it should be a message send.
I still have to see a good use case that could justify the use of that. Because it also involves the message lookup, which AFAIK is performed by the VM.
Regards,
Esteban A. Maringolo
Hi, For the sake of simplifying APIs by not asking the client to provide everything, and at the same time for the sake of not constraining other clients with different use cases in which they need to provided all parameters, I've often relied on that kind of ugly overloaded style. APIs are difficult to change afterwards, so they have to be simple enough for the expected use case, but flexible enough for unexpected use cases. I'd vote +1 for optional parameters with default values. 2016-01-22 9:00 GMT+01:00 phil@highoctane.be <phil@highoctane.be>:
This would be nice to be able to use several different languages "ways of doing things" that would translate into message sends behind the scenes.
Helvetia story...
Phil
On Thu, Jan 21, 2016 at 6:04 PM, Esteban A. Maringolo < emaringolo@gmail.com> wrote:
2016-01-21 8:38 GMT-03:00 Henrik Johansen <henrik.s.johansen@veloxit.no>:
On 20 Jan 2016, at 6:14 , Esteban A. Maringolo <emaringolo@gmail.com>
wrote:
I would be interested in the use cases and how to deal with "undefined" arguments, will they be nil or other kind of undefined object?
Perhaps
request: aFile with: anotherThing and: aThirdThing <optionalParameter: anotherThing "default: nil"> <optionalParameter: aThirdThing default: defaultThirdThing> -> request: aFile with: anotherThing ^self request: aFile with: anotherThing and: self defaultThirdThing request: aFile and:: aThirdThing ^self request: aFile with: nil and: self aThirdThing request: aFile ^self request: aFile with: nil and: self defaultThirdThing
The pragma for the default unless it's a literal object it should be a message send.
I still have to see a good use case that could justify the use of that. Because it also involves the message lookup, which AFAIK is performed by the VM.
Regards,
Esteban A. Maringolo
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
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.ferlicot@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
165 Avenue Bretagne Lille 59000 France
Hi Damien, As far as I know this describes the Robert Hirschfeld's Convenience Methods pattern. I wrote a code generator package which generates this pattern through an API like this: CGStConvenienceMethods uniqueInstance setCleanTarget; parameterCount: 2; targetSelector: #cgConvEx2; addReturn; targetClassCategory: 'ConvenienceMethodsEx'; targetClass: #ConvenienceMethodsEx; generateMethods. That expression generates a class named ConvenienceMethodsEx with 3 methods: #cgConvEx2 #cgConvEx2with: #cgConvEx3with:with: where each method passes nil as default parameter to it's "subsequent" version (same selector +1 parameter). Cheers, Hernán 2016-01-20 12:08 GMT-03:00 Damien Cassou <damien.cassou@inria.fr>:
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
-- Damien Cassou http://damiencassou.seasidehosting.st
"Success is the ability to go from one failure to another without losing enthusiasm." --Winston Churchill
On 20 Jan 2016, at 16:08, Damien Cassou <damien.cassou@inria.fr> wrote:
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
- Morphic - Morph - addAlarm:*at: - addAlarm:*after: - startStepping* - subMorphNamed:* - Morphic - MenuMorph - add:*selector:* - addToggle:* - addUpdating:* Some of those might not be simplified by default arguments, and some of those may require run-time default values. At least, they make interesting edge cases.
Le 25/1/16 09:32, David Allouche a écrit : >> On 20 Jan 2016, at 16:08, Damien Cassou <damien.cassou@inria.fr> wrote: >> >> 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 > - Morphic > - Morph > - addAlarm:*at: > - addAlarm:*after: > - startStepping* > - subMorphNamed:* > > - Morphic > - MenuMorph > - add:*selector:* > - addToggle:* > - addUpdating:* > > Some of those might not be simplified by default arguments, and some of those may require run-time default values. At least, they make interesting edge cases. Tx for the examples. we should also use a fluid api and not these lengthly argument tedious list >
On 28 Jan 2016, at 21:55, stepharo <stepharo@free.fr> wrote: Le 25/1/16 09:32, David Allouche a écrit :
- Morphic - Morph - addAlarm:*at: - addAlarm:*after: - startStepping* - subMorphNamed:*
- Morphic - MenuMorph - add:*selector:* - addToggle:* - addUpdating:*
Some of those might not be simplified by default arguments, and some of those may require run-time default values. At least, they make interesting edge cases. Tx for the examples.
we should also use a fluid api and not these lengthly argument tedious list
That should probably be for another thread, but⦠I am all for avoiding lengthy tedious argument lists that break my limited short term memory. What do you mean by "fluid api"?
On 30 January 2016 at 00:29, David Allouche <david@allouche.net> wrote:
What do you mean by "fluid api"?
I suppose https://en.wikipedia.org/wiki/Fluent_interface An API that enables / encourages chaining messages in one expression. Smalltalk's message cascades and the default of returning self both help with that.
participants (12)
-
Cyril Ferlicot D. -
Damien Cassou -
Damien Pollet -
David Allouche -
Dimitris Chloupis -
Esteban A. Maringolo -
Henrik Johansen -
Hernán Morales Durand -
Jose San Leandro -
Offray Vladimir Luna Cárdenas -
phil＠highoctane.be -
stepharo