Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:101713
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: pass (pb1.pair.com: domain gmail.com designates 74.125.82.54 as permitted sender)
To: internals@lists.php.net
References: <517F0F7B-CD01-4F35-9021-8336B7BA06E1@cschneid.com>
Message-ID: <4d699e5d-3fa9-8de3-ba97-26d1460be7fc@gmail.com>
Date: Sat, 27 Jan 2018 14:14:04 +0000
User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:52.0) Gecko/20100101
 Thunderbird/52.5.2
MIME-Version: 1.0
In-Reply-To: <517F0F7B-CD01-4F35-9021-8336B7BA06E1@cschneid.com>
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Transfer-Encoding: 8bit
Content-Language: en-GB
Subject: Re: [PHP-DEV] Shorthand proposal for associative arrays
From: rowan.collins@gmail.com (Rowan Collins)

Hi!

On 26/01/2018 18:16, Christian Schneider wrote:
> Hi there,
> I have a proposal for a shorthand notation of associative arrays borrowed from another language:
> 	:$foo
> would be equivalent to
> 	'foo' => $foo
> and would work with array, list or []

I'm always a little suspicious of features that give meaning to the name 
of a variable, because I consider variable names to be an important part 
of the readability of code, and the encapsulation of an implementation. 
As such, I want to be able to rename local variables as part of tweaking 
how a particular function is written. For instance, I'm not in favour of 
introducing named parameters based on existing function signatures, 
because it makes names which were previously local into part of the 
function's public signature.

While this particular proposal doesn't prevent refactoring in the way 
named parameters would, it adds one more thing to trip up on: when 
renaming $foo to $bar, [:$foo] needs to be changed to ['foo' => $bar].


> 1) Emulating named parameters with associative arrays like
> 	html::img([ 'src' => $src, 'alt' => $alt ]);
>     could be written as
> 	html::img([ :$src, :$alt ]);
>     which encourages consistent naming of variables and parameters

This smells of bad code to me: it either means your functions are very 
closely coupled, and the variables have exactly the same meaning in both 
scopes; or that one or other name is poorly chosen, and doesn't reflect 
its meaning in the scope where it's used.

In this example, $alt would probably have come from some other string, 
which could more appropriately be labelled $productName, or $bookTitle, 
or whatever the image is showing. If the values are constructed just for 
this function call, I would prefer to read:

     html::img([
          'src' => $imageDomain . $coverImagePath,
          'alt' => "$bookTitle by $authorName"
     ]);

as opposed to:

    $src = $coverImagePath . $coverImagePath;
    $alt = "$bookTitle by $authorName";
    html::img([ :$src, :$alt ]);



> 2) Simplifying list destructuring with non-integer keys, example taking from http://php.net/manual/en/migration71.new-features.php#migration71.new-features.support-for-keys-in-list
> 	foreach ($data as ["id" => $id, "name" => $name]) {
>     becomes
> 	foreach ($data as [ :$id, :$name ]) {
>     which reduces redundancy.


This example feels a bit more compelling, but again it assumes that you 
want the local name to match the array key, rather than having a name 
appropriate to the current task. For instance, you might well be dealing 
with other things which have IDs and names, and want to differentiate:

    foreach( $bookList as ["id" => $bookId, "name" => $bookName ] ) {


I'm not dead against this proposal, but it's not one I'd be using often 
myself, and personally I think it would lead to more bad code than good.

Regards,

-- 
Rowan Collins
[IMSoP]