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
