Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:112422
To: internals@lists.php.net
References: <d1c4689e-9120-4e90-837c-a1b3eac63cd6@www.fastmail.com>
 <6cdd2d8c-39ea-c3a3-5f42-e355dc601539@processus.org>
Message-ID: <12c0779e-8c90-b80a-998e-9808a3314146@fischer.name>
Date: Sat, 5 Dec 2020 12:14:33 +0100
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.15; rv:78.0)
 Gecko/20100101 Thunderbird/78.5.0
MIME-Version: 1.0
In-Reply-To: <6cdd2d8c-39ea-c3a3-5f42-e355dc601539@processus.org>
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Language: en-US
Content-Transfer-Encoding: 7bit
X-Spam_score: -2.9
X-Spam_score_int: -28
X-Spam_bar: --
X-Spam_report: Spam detection software, running on the system "scanner01.home", has
 identified this incoming email as possible spam.  The original message
 has been attached to this so you can view it (if it isn't spam) or label
 similar future email.  If you have any questions, see
 the administrator of that system for details.
 
 Content preview:  Hi, On 05.12.20 10:22, Pierre R. wrote: > I think that ::cases()
    should always return an array/iterable without > keys, and let userland write
    their own code to create hashmaps with > those when they need it. I think
    that having one case (non primitive > cases) that doesn't yield string keys
    and the other (primitive cases) > which holds string keys may create a confusion
    because behavior is > different. > > If behavior is different, this would
    mean you couldn't mix primitive and > non primitive cases on the same enum,
    which, why not couldn't we do that? [...] 
 
 Content analysis details:   (-2.9 points, 5.0 required)
 
  pts rule name              description
 ---- ---------------------- --------------------------------------------------
 -1.0 ALL_TRUSTED            Passed through trusted hosts only via SMTP
 -1.9 BAYES_00               BODY: Bayes spam probability is 0 to 1%
                             [score: 0.0000]
 -0.0 NICE_REPLY_A           Looks like a legit reply (A)
X-CMAE-Envelope: MS4wfBb3ezLcNNktf0cBXLpfcFI2I7DwFVbf2SbRr96mtEdYefvaY/Izb6yfuaR0niDmR1tPsA7xyEUKv+6RUDpqarIlnUA43wuzEbB6LqmmL+ugb3D/AjYs
 HDkaIY49INdESo/M0Mx/9WYGnzScG8RqNue+6BTaRFSpNk3cK4BIEGX2
Subject: Re: [PHP-DEV] [RFC] Enumerations
From: markus@fischer.name (Markus Fischer)

Hi,

On 05.12.20 10:22, Pierre R. wrote:
> I think that ::cases() should always return an array/iterable without 
> keys, and let userland write their own code to create hashmaps with 
> those when they need it. I think that having one case (non primitive 
> cases) that doesn't yield string keys and the other (primitive cases) 
> which holds string keys may create a confusion because behavior is 
> different.
> 
> If behavior is different, this would mean you couldn't mix primitive and 
> non primitive cases on the same enum, which, why not couldn't we do that?

I've no strong feelings and I think your idea makes sense.

But I would argue, of course without having hard facts, that the 
_majority_ will have the use-case for a 1:1, aka array with key => 
value, mapping.

Thus I would argue that having (considering your proposal being added) 
still such functionality would be useful for a very wide-audience 
without everyone having to reinvent a helper method to use the iterable.

thanks for considering,
- Markus