Smalltalk › Pharo › Pharo Smalltalk Users

Use cases for methods with optional parameters

‹ Previous Topic Next Topic ›
 
classic Classic list List threaded Threaded
♦
♦
 15 messages Options
Damien Cassou-2
Reply | Threaded
Open this post in threaded view
♦
♦
|

Use cases for methods with optional parameters

Damien Cassou-2
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

Offray
Reply | Threaded
Open this post in threaded view
♦
♦
|

Re: Use cases for methods with optional parameters

Offray
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
>


Esteban A. Maringolo
Reply | Threaded
Open this post in threaded view
♦
♦
|

Re: Use cases for methods with optional parameters

Esteban A. Maringolo
2016-01-20 14:01 GMT-03:00 Offray Vladimir Luna Cárdenas <[hidden email]>:
> 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

CyrilFerlicot
Reply | Threaded
Open this post in threaded view
♦
♦
|

Re: Use cases for methods with optional parameters

CyrilFerlicot
In reply to this post by Damien Cassou-2
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


signature.asc (836 bytes) Download Attachment
kilon.alios
Reply | Threaded
Open this post in threaded view
♦
♦
|

Re: Use cases for methods with optional parameters

kilon.alios
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. <[hidden email]> 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
hernanmd
Reply | Threaded
Open this post in threaded view
♦
♦
|

Re: Use cases for methods with optional parameters

hernanmd
In reply to this post by Damien Cassou-2
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 <[hidden email]>:
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
Henrik Sperre Johansen
Reply | Threaded
Open this post in threaded view
♦
♦
|

Re: Use cases for methods with optional parameters

Henrik Sperre Johansen
In reply to this post by Esteban A. Maringolo

> On 20 Jan 2016, at 6:14 , Esteban A. Maringolo <[hidden email]> 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

signature.asc (859 bytes) Download Attachment
kilon.alios
Reply | Threaded
Open this post in threaded view
♦
♦
|

Re: Use cases for methods with optional parameters

kilon.alios
how about syntax like this

openFile: aPath (optionalArgumentA: anArgument optionalArgumentB: anArghument)

On Thu, Jan 21, 2016 at 1:39 PM Henrik Johansen <[hidden email]> wrote:

> On 20 Jan 2016, at 6:14 , Esteban A. Maringolo <[hidden email]> 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
Esteban A. Maringolo
Reply | Threaded
Open this post in threaded view
♦
♦
|

Re: Use cases for methods with optional parameters

Esteban A. Maringolo
In reply to this post by Henrik Sperre Johansen
2016-01-21 8:38 GMT-03:00 Henrik Johansen <[hidden email]>:
>
>> On 20 Jan 2016, at 6:14 , Esteban A. Maringolo <[hidden email]> 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

philippeback
Reply | Threaded
Open this post in threaded view
♦
♦
|

Re: Use cases for methods with optional parameters

philippeback
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 <[hidden email]> wrote:
2016-01-21 8:38 GMT-03:00 Henrik Johansen <[hidden email]>:
>
>> On 20 Jan 2016, at 6:14 , Esteban A. Maringolo <[hidden email]> 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
Jose San Leandro
Reply | Threaded
Open this post in threaded view
♦
♦
|

Re: Use cases for methods with optional parameters

Jose San Leandro
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 [hidden email] <[hidden email]>:
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 <[hidden email]> wrote:
2016-01-21 8:38 GMT-03:00 Henrik Johansen <[hidden email]>:
>
>> On 20 Jan 2016, at 6:14 , Esteban A. Maringolo <[hidden email]> 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
David Allouche
Reply | Threaded
Open this post in threaded view
♦
♦
|

Re: Use cases for methods with optional parameters

David Allouche
In reply to this post by Damien Cassou-2

> On 20 Jan 2016, at 16:08, Damien Cassou <[hidden email]> 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.
stepharo
Reply | Threaded
Open this post in threaded view
♦
♦
|

Re: Use cases for methods with optional parameters

stepharo


Le 25/1/16 09:32, David Allouche a écrit :

>> On 20 Jan 2016, at 16:08, Damien Cassou <[hidden email]> 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
>


David Allouche
Reply | Threaded
Open this post in threaded view
♦
♦
|

Re: Use cases for methods with optional parameters

David Allouche
> On 28 Jan 2016, at 21:55, stepharo <[hidden email]> 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"?


Damien Pollet-2
Reply | Threaded
Open this post in threaded view
♦
♦
|

Re: Use cases for methods with optional parameters

Damien Pollet-2
On 30 January 2016 at 00:29, David Allouche <[hidden email]> 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. 
Free forum by Nabble Edit this page