Newsgroups: php.internals Path: news.php.net Xref: news.php.net php.internals:112860 Return-Path: Delivered-To: mailing list internals@lists.php.net Received: (qmail 49118 invoked from network); 13 Jan 2021 09:30:15 -0000 Received: from unknown (HELO php-smtp4.php.net) (45.112.84.5) by pb1.pair.com with SMTP; 13 Jan 2021 09:30:15 -0000 Received: from php-smtp4.php.net (localhost [127.0.0.1]) by php-smtp4.php.net (Postfix) with ESMTP id A150F1804E3 for ; Wed, 13 Jan 2021 01:08:25 -0800 (PST) X-Spam-Checker-Version: SpamAssassin 3.4.2 (2018-09-13) on php-smtp4.php.net X-Spam-Level: X-Spam-Status: No, score=-2.1 required=5.0 tests=BAYES_00,DKIM_SIGNED, DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,FREEMAIL_FROM, RCVD_IN_DNSWL_NONE,RCVD_IN_MSPIKE_H2,SPF_HELO_NONE,SPF_PASS autolearn=no autolearn_force=no version=3.4.2 X-Spam-Virus: No X-Envelope-From: Received: from mail-wr1-f48.google.com (mail-wr1-f48.google.com [209.85.221.48]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange ECDHE (P-256) server-signature RSA-PSS (4096 bits) server-digest SHA256) (No client certificate requested) by php-smtp4.php.net (Postfix) with ESMTPS for ; Wed, 13 Jan 2021 01:08:24 -0800 (PST) Received: by mail-wr1-f48.google.com with SMTP id c5so1251570wrp.6 for ; Wed, 13 Jan 2021 01:08:24 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=subject:to:references:from:message-id:date:user-agent:mime-version :in-reply-to:content-transfer-encoding:content-language; bh=M6ujquRZS2nH6Fx7Lp63e5ut2D7FjhZYMbJjOn6tXOY=; b=SvN8N5EFG0XsZ1YJHXAl+/aWAkofL+i9m2vVwcVAfk21tQJDRXdvNSRH1NlzUOJnvf DKD3k03VY6MA6+GJ2AYabYicBCKaiwaV0IRV1bH1nktVUnd+OgBEAYgRr1WtTd2BBpai UzTUIC/ab+dNFTgs/YtjmJ/Ir8N1WOzkHCUWWQz0zYW7dtKc0Z0AyDiyVDV42WXUf0sM ooLCGwcFKbN+vsywcUTU3QoQH2GJwJoQjp5ZxrMnOphsEpayDORrSNTnWQ7Ly0b3RJnV 7LyLuuFds1mDIvpnuaacjRAw0st7zEX9SeZFqJmnj/aO9WyhGD1qXO3dAm8hdrQw8o68 u9gQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:references:from:message-id:date :user-agent:mime-version:in-reply-to:content-transfer-encoding :content-language; bh=M6ujquRZS2nH6Fx7Lp63e5ut2D7FjhZYMbJjOn6tXOY=; b=ZPA9P8S5empglSqH8qVCSwPiEvDphA3dApGWBkh2AvjMd8sGhVXtoQwcfGQm9RhCxd ayPwhJHxevGL4mF8MUqAquhbQ2TfZK7W9XumGoVjU6U4ecrCIf1/1wLsW0wr0RKmKIPZ 5N99blkUpKZRxZ/qJ2Ja+5paC8KybqWdtEh+QY8OvUPlpPZXcx7juLUaY6tTNsV/x0uU BvuWZrxLzzr0wjuuPDVjxaGgxnYD+VxDVumHPRhyTMSV0kEi4dwHx8U9WdovWDeESh0p D/w1N910afkNMMqBNbA3oLYIOmbN47oD4TMsIx5gM1DWywBk3obsbmECu5e4ZSNdSQFa cqBA== X-Gm-Message-State: AOAM532LUQ7OCE5klr0YJcLpalwh0KcTk+IdNwM/ennxp/claUystWN7 vy1BpvIoWupmowbhYDXSn0qs+P8/SJpOaA== X-Google-Smtp-Source: ABdhPJy+m0CsO3c4wXswlGvbxdptZ+4vmuFov6NcEX+iE/8EhiEGMOMNDfjLURJjIK+pI2Ged0fsrQ== X-Received: by 2002:adf:ffc8:: with SMTP id x8mr1468724wrs.158.1610528898843; Wed, 13 Jan 2021 01:08:18 -0800 (PST) Received: from [192.168.0.22] (cpc104104-brig22-2-0-cust548.3-3.cable.virginm.net. [82.10.58.37]) by smtp.googlemail.com with ESMTPSA id l1sm2216383wrq.64.2021.01.13.01.08.17 for (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Wed, 13 Jan 2021 01:08:18 -0800 (PST) To: internals@lists.php.net References: Message-ID: <39ccd4f9-cb63-549f-d34e-0c5e473598a2@gmail.com> Date: Wed, 13 Jan 2021 09:08:15 +0000 User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:78.0) Gecko/20100101 Thunderbird/78.6.1 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit Content-Language: en-GB Subject: Re: [PHP-DEV] [RFC] Allow object keys in arrays From: rowan.collins@gmail.com (Rowan Tommins) On 12/01/2021 16:51, Marco Pivetta wrote: > Whether the problem can be mitigated is what should be discussed, but the > problem is objectively there. Hi all, Like others, I like the *idea* of object keys, but worry about its practical impact. A few scatter-gun thoughts on possible approaches, I don't think any of them is the solution, but maybe they'll spark someone else to further ideas: - Only allow objects that are "stringable" (i.e. implement __toString), but don't actually call it. This retains the safety of code using "(string)$key", but not code passing to a constraint of "string|int". (It also means enums will all have to have an __toString, which might be a price worth paying.) - Create a new type, which is like an array but allows object keys, with its own literal syntax. e.g. $hash = hash['foo' => 42, $someObject => 69]; assert(is_array($hash) === false); assert(is_iterable($hash) === true); - Invent a syntax for initialising a custom collection object from a literal with arbitrary keys and values, but not actually initialise it as an array. Even without generics, this would make it much more attractive to replace more arrays with specific collection types. Regards, -- Rowan Tommins [IMSoP]