On Wed, Jan 20, 2016 at 11:08 PM, Damien Cassou <[email protected]> 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:*
I don't have any use cases right now, but I'll keep my eyes open. But
an example (that is maybe too basic to mess with) is the
#at:ifAbsent: pattern. For example, the following would be
"deleted"
Dictionary>>.at: key
^ self at: key ifAbsent: [self errorKeyNotFound: key]
and you would only have....
Dictionary>>at: key ifAbsent: aBlock
<optional: ifAbsent default: [ self errorKeyNotFound: key]>
The big in-Image example would be...
TClass>>
subclass: aName
uses: aTraitCompositionOrArray
instanceVariableNames: someInstanceVariableNames
classVariableNames: someClassVariableNames
poolDictionaries: someSharedPoolNames
package: aCategory
<optional: uses default: {}>
<optional: instanceVariableNames default: ''>
<optional: classVariableNames default: ''>
<optional: poolDictionaries default:''>
<optional: package 'Unclassified'>
Now I wonder about senders & implementers searchability, and if
"virtual" methods are generated in all combinations of optional
parameters and show up in the system browser list, but show the "main"
method as their source. Maybe it works a little like traits.
cheers -ben
