Re: [Pharo-users] Use cases for methods with optional parameters
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
> 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
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
> 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
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
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
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
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
> 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
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
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 > >
Re: [Pharo-users] Use cases for methods with optional parameters
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
2016-01-20 14:01 GMT-03:00 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, > 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
Re: [Pharo-users] Use cases for methods with optional parameters
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
[Pharo-users] 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