RE: [PHP-DEV] Re: [RFC] Named parameters
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 how to deal with the
'api mismatch' problem.
I'm still undecided about 'mixing' positional named arguments:
An example use case for **kwargs here:
http://www.python-requests.org/en/latest/api/
If you declare:
request($method, $url, ...$args)
Would $args collect 'method' and 'url' ?
request(method = 'post', url = 'foo/');
Renaming of parameters in signatures
-
Until now three options were discussed:
1. Throw an E_STRICT (or similar) error during signature validation if a
parameter
is renamed 2. Don't validate parameter renames in signature and just let
people
hit the runtime error when they do the call.
3. Create an ini-setting chooses either behavior 1 or 2.
class A {
public function foo($oldBar) { ... }
}
and
class B extends A {
public function foo($newBar) { ... }
}
My preference would be to only support named parameters based on the initial
declaration $oldBar (much simpler expectations).
$c = new B;
$c-foo(oldBar = 'hello');
$c-foo(newBar = 'hello'); // Warning, no named parameter 'newBar' found,
Warning first argument missing ...
Lastly, using the same syntax ... for declaring variadics and unpacking
seems odd to me.
Some ideas for a different syntax:
$params = ['oldBar' = 'hello'];
$c-foo($params...);
$c-foo((var)$params);
$c-foo((...)$params);
My preference is the third since it looks like we're casting an array to named
parameters.
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
RE: [PHP-DEV] [RFC] Skipping parameters take 2
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 ,,, is indeed much more readable.
However I still wonder what prevents to finally implement named
parameters too, it will provide the same feature while being even more
handy and easier.
And it covers an additional use-case: Self-explaning parameters like in
foo(is_strict = false) instead of foo(null, null, false).
Lots of overlap between variadic functions, this proposal named parameters.
A popular use case for library authors is to use:
interface foo {
function formatUseCases(array $options);
}
- Advantage: No dependency on a class / object
- Disadvantage: doesn't document what options are available, hard to extend
'default parameters'
interface foo {
function formatUseCases(MyOptions $options);
}
- Advantage: documents which options are available, easy to extend default
parameters
- Disadvantage: modification of the object means these 'options' are available
to any declaration using it, hard to maintain over time without big refactoring
(lots of options objects)
interface foo {
function formatUseCases(...$options);
}
- Advantage: No dependency on a class / object
- Disadvantage: doesn't document what options are available, no default
parameters
interface foo {
function formatUseCases($showGood = true, $showBad = true, $pretty = true,
$title= what are these parameters?);
}
- Advantage: Self-documenting with default parameters
- Disadvantage: Not extendable api signature (changing default parameters)
- Readability:
# array
formatUseCases(['showGood': true, 'showBad': true, 'pretty': true]);
#object
$obj-showGood = true;
$obj-showBad = true;
$obj-pretty = true;
formatUseCases($obj);
# variadic or function declaration
formatUseCases(true, true, true, what are these parameters?);
- Solution somewhat as a hybrid?
interface foo {
function formatUseCases(...$options[showGood = true, showBad = true, pretty =
true, title= what are these parameters?]);
}
formatUseCases(true, true, true, use defaults for everything else);
formatUseCases(['title': use defaults for everything else]); // more readable
Implemention wise $options could be ~ SplParameters which implements
ArrayInterface :
class bar implements foo {
function formatUseCases(...$options[]) { // api signature as $options[]
always accepted (uses default params)
echo get_class($options); // SplParameters
var_dump($options['showGood']) // true;
var_dump($options-showGood) // true;
}
}
class bar2 implements foo {
function formatUseCases(...$options[showGood = false]) { // easy to extend
default options
var_dump($options['showGood']) // false;
}
}
Why use special syntax ~ ...$options[] instead of just named parameters:
http://msdn.microsoft.com/en-us/library/dd264739.aspx
My hunch is that applying named parameters to every function would be very
costly in PHP. But as a special syntax applied to a few functions, this might
work well.
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
RE: [PHP-DEV] [RFC] Skipping parameters take 2
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 function are indexed, not named. In addition, they have the same
type (or at least they are treated the same way).
Right I'm for variadic '...$options' as proposed with indexed arguments (just
like c). Python calls this positional arguments.
I'm stretching the comparison to see if syntax could be augmented to serve
another use case (with named arguments)?
...$options[] would be more similar to **keyparam in python:
http://rosettacode.org/wiki/Named_Arguments#Python
RE: [PHP-DEV] [RFC] Syntax for variadic functions
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, ...$options[]) { echo count($options); }
logA(foo); // 0
logA(foo, 1, 2); // 2
logA(foo, array(1,2,3)); // 3
The difference here is that variadic options is declared as an optional array,
it would not support a 'typehint' forcing all arguments to be of the same type.
It could be a way to support ~ named parameters
// requires at least 1 argument named as 'level'
function logB($message, ...$options['level']) {
echo $options['level'] .' '. count($options);
}
logB(foo);// fails: 'level' argument
missing
logB(foo, 'notice'); //notice 1
logB(foo, ['level' = 'notice']); // notice 1
logB(foo, 'notice', 'extra'); // notice 2
logB(foo, ['level' = 'notice'], 'extra'); // notice 2
// requires min 2 arguments
function logC($message, ...$options['level','priority']) {
echo 'level:'. $options['level'];
echo 'priority:'. $options['priority'];
}
logC(foo, notice, 4);
logC(foo, ['level' = 'notice', 'priority' = 4]);
That would remove the need for a splat or scatter operator. The declaration
...$options[] would mean, I accept an array of arguments followed by extra
arguments
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
RE: [PHP-DEV] RFC: Protocol Type Hinting
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 interfaces):
register_instanceof($compatibleInterface, $interface);
e.g.
class ThirdParty {
static foo(LoggerInterface $log) {}
}
class Bar implements My_Logging_Inferface {}
echo (Bar instanceof LoggerInterface); // false
register_instanceof('My_Logging_Inferface', 'LoggerInterface');
echo (Bar instanceof LoggerInterface); // true
ThirdParty::foo(new Bar); // no error since 'My_Logging_Interface' is
compatible with LoggerInterface
In summary, it would allow for user-land registration of compatible interfaces
to third party libraries.
There's definitely a couple of use cases where I would have liked to use
something to this.
Advantages to wrapping the feature in a function:
- No extra syntax to support in core
- No 'new concept' for developers to learn
- It can be disabled (which OO purists might like)
disable_functions = register_instanceof
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
RE: [PHP-DEV] [VOTE] Integrating Zend Optimizer+ into the PHP distribution
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 the cracks is if a new feature can delay the release process. https://wiki.php.net/rfc/releaseprocess In this case, I think it should. Every law/rule has exceptions, PHP probably needs a dictator or appointed judge(s). -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
