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 tha
> 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
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), o
> 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
>
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 difficu
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 Ja
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: anotherTh
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
> 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: aThir
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;
targetSelect
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,
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:
>
>
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
>
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 C
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
15 matches
Mail list logo