Re: [Pharo-users] Use cases for methods with optional parameters

[Damien Pollet]

On 30 January 2016 at 00:29, David Allouche  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.

Re: [Pharo-users] Use cases for methods with optional parameters

[David Allouche]

> On 28 Jan 2016, at 21:55, stepharo  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"?

Re: [Pharo-users] 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  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

Re: [Pharo-users] Use cases for methods with optional parameters

[David Allouche]

> On 20 Jan 2016, at 16:08, Damien Cassou  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.

Re: [Pharo-users] Use cases for methods with optional parameters

[p...@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 
wrote:

> 2016-01-21 8:38 GMT-03:00 Henrik Johansen :
> >
> >> On 20 Jan 2016, at 6:14 , Esteban A. Maringolo 
> 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
> > 
> > 
> > ->
> > 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
>
>
>

Re: [Pharo-users] 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 p...@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 <
> emaring...@gmail.com> wrote:
>
>> 2016-01-21 8:38 GMT-03:00 Henrik Johansen :
>> >
>> >> On 20 Jan 2016, at 6:14 , Esteban A. Maringolo 
>> 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
>> > 
>> > 
>> > ->
>> > 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
>>
>>
>>
>

Re: [Pharo-users] Use cases for methods with optional parameters

[Henrik Johansen]

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


->
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
Description: Message signed with OpenPGP using GPGMail

Re: [Pharo-users] Use cases for methods with optional parameters

[Dimitris Chloupis]

how about syntax like this

openFile: aPath (optionalArgumentA: anArgument optionalArgumentB:
anArghument)

On Thu, Jan 21, 2016 at 1:39 PM Henrik Johansen <
henrik.s.johan...@veloxit.no> wrote:

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

Re: [Pharo-users] Use cases for methods with optional parameters

[Esteban A. Maringolo]

2016-01-21 8:38 GMT-03:00 Henrik Johansen :
>
>> On 20 Jan 2016, at 6:14 , Esteban A. Maringolo  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
> 
> 
> ->
> 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

Re: [Pharo-users] Use cases for methods with optional parameters

[Cyril Ferlicot D.]

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
Description: OpenPGP digital signature

Re: [Pharo-users] Use cases for methods with optional parameters

[Offray Vladimir Luna Cárdenas]

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

Re: [Pharo-users] Use cases for methods with optional parameters

[Hernán Morales Durand]

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 :

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

Re: [Pharo-users] Use cases for methods with optional parameters

[Dimitris Chloupis]

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