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 phil@highoctane.be <phil@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 <emaringolo@gmail.com> wrote:
2016-01-21 8:38 GMT-03:00 Henrik Johansen <henrik.s.johansen@veloxit.no>:
>
>> On 20 Jan 2016, at 6:14 , Esteban A. Maringolo <emaringolo@gmail.com> 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