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 challenge
On Mon Sep 2 08:52 AM, Sebastian Krebs wrote:
2013/9/2 Pierre Joye pierre@gmail.com
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 ,,,
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
variadic
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,
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
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 in
