Hi Robert,
for named parameters, I would prefer this syntax over list():
function foo($foo, [a: string $a, b: int &$b, c: bool $c = true]) {
... work with $foo, $a, $b, $c
}
$b = 42;
foo('foo', ['a' => 'bar', 'b' => $b]);
function bar($foo, SomeClass {a: string $a, b: int &$b, c: bool $c = true}) {
... work with $foo, $a, $b, $c
}
$o = new SomeClass();
$o->a = 'bar';
$o->b = 42;
bar('foo', $o);
Regards
Thomas
Robert Stoll wrote on 20.01.2016 22:20:
> Hi Andrea
>
> I am writing you in private since I think this is rather out of scope.
>
> -----Ursprüngliche Nachricht-----
>> Von: Pierre Joye [mailto:pierre....@gmail.com]
>> Gesendet: Montag, 18. Januar 2016 05:54
>> An: Andrea Faulds
>> Cc: PHP internals
>> Betreff: Re: [PHP-DEV] [RFC] Allow specifying keys in list()
>>
>> hi Andrea,
>>
>> I very much like this proposal. Good work as usual!
>>
>> The only part where I think we should not rely on list is the future scope. I
>> can see the logic that leads to use list for named
>> arguments.
>> However I really think it is a very different topic and having to use list to
>> define arguments, it sounds like a hack to solve
>> another long due feature.
>
> I agree with Pierre on this one. Using list for named parameters seems like a
> lot of overhead on the declaration side to me (writing the name of a parameter
> twice). IMO it should not require additional effort than writing a
> function/method today and it should be available for all functions/methods and
> not only for ones with special named-paramater-syntax. I think you should
> consider further (when thinking about using the new feature for named
> parameters)
> - how can you specify optional parameters?
> - how can you specify byRef parameters?
> - what happens if one does not provide all keys? Currently this: list($a, $b)
> =
> [1]; //only produces a Warning
> - are there differences between strict mode and none strict mode? e.g., what
> if the type of the key is different?
> - would it be possible to use a type for the key as well (as for the value
> indicated in your RFC)?
> - would you allow nested destructuring for parameters?
> - how would you reduce the overhead of creating an array which is then copied
> and passed to the function?
>
> IMO destructuring parameters and named parameters are two different things
> which could be combined. Something like this:
> function foo(SomeClass $class, list("x" => $x, "y" => $y) $point = ["x"=>0,
> "y"=>0], $flagA = true, $flagB = 1) {
> }
> foo($myClass, point: [1,2], flagB: 0);
> foo($myClass, flagB: 2);
>
> yet, IMO it would hamper readability (probably in many cases) and it would be
> better to do it inside the function.
> I understand destructuring parameters just as syntactic sugar and I would
> still
> expect that PhpDocumenter would indicate that my function requires an array.
> Otherwise the same feature would suddenly also be used to declare deep
> structured data structures and at this point I am not so sure whether auto
> conversion of keys play well together with strict mode. It would certainly be
> interesting from a type safety point of view that one can define very complex
> data structures and let PHP do the work for verification. Yet, it also opens a
> door to very ugly code (well... which also exists without the feature) --
> sorry, drifting away from the topic.
>
> Some other points crossing my mind
> - how well does the feature interact with typed arrays (if they should be
> introduced at some point)?
> - how well does it interact with structural types (if they should be
> introduced
> at some point)?
>
> And now some points to the RFC:
> - I like the RFC in general
> - I am not really a fan of the naming "list" in general but I think it is
> appropriate to reuse the same syntax for this task.
> - one thing I am missing in the RFC is error handling. What happens if a key
> is
> not found? And there are surely other questions. I think you should include a
> section about error handling in the RFC.
> - I guess mixing number keys with string keys is possible, right?
> - are placeholders (something like list(_ , $a, _) = [1,2,3]) in your
> pipeline
> or do you think they make no sense in PHP?
> - already an idea how it would interact with pattern matching?
>
> Cheers,
> Robert
>
>
>
>
> --
> PHP Internals - PHP Runtime Development Mailing List
> To unsubscribe, visit: http://www.php.net/unsub.php
>
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
