On Mon Sep 9 03:18 PM, Nikita Popov wrote:
> > I created an RFC and preliminary implementation for named parameters:
> >
> > https://wiki.php.net/rfc/named_params
> >
>
Awesome work!
>
> Let only special functions accept named params
> -
>
Proposal makes sense though there's still the
>
> > interface foo {
> > function formatUseCases(...$options); }
> > - Advantage: No dependency on a class / object
> > - Disadvantage: doesn't document what options are available, no
> > default parameters
> >
>
>
> This is totally not a use case for variadic functions. The arguments of a
>
On Mon Sep 2 08:52 AM, Sebastian Krebs wrote:
> 2013/9/2 Pierre Joye
>
> > >
> > > Any comments or feedback on the RFCs and the code are welcome,
> > > especially pointing out the cases where it may not work (which means
> > > we need more phpt's there :)
> >
> > Using default instead of ,,, is i
On Wed Aug 28 11:47 AM, Nikita Popov wrote:
>
> https://wiki.php.net/rfc/variadics
Interesting idea, expanding on:
function log($message, ...$options) {}
It would seem convenient to allow ...$options to be passed as a key-value array
of arguments as well:
function logA($message, ...$optio
>I agree the use-cases are slightly weak. This is a draft RFC. It's supposed to
>help identify
> the areas where we can improve it. Help identify use-cases. Help dig it out.
I think Ralph has the right idea:
register_compatible_types($yourType, $myType);
A better name might be (only for interfa
> I'm right now oblivious to what is being voted or not in this case,
> but ignoring a defined 2/3 rule is clearly wrong. Either remove rules or
> follow them otherwise they become useless noise.
As far as I understand the RFC is a process to accept or reject features.
The question that falls
