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
> 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:*
>> -
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
> 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
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
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
> 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:
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
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
>>
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:
>
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
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;
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,
13 matches
Mail list logo