Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:123738
X-Original-To: internals@lists.php.net
Delivered-To: internals@lists.php.net
Received: from php-smtp4.php.net (php-smtp4.php.net [45.112.84.5])
	by qa.php.net (Postfix) with ESMTPS id 215AA1A009C
	for <internals@lists.php.net>; Fri, 21 Jun 2024 16:39:27 +0000 (UTC)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=php.net; s=mail;
	t=1718988041; bh=D9iRnY6UctYMsV+fZXRJEkbxbxkl0LGvqGLN8JOAsLA=;
	h=Subject:From:In-Reply-To:Date:Cc:References:To:From;
	b=ZB7ELcObwgwVGlj6Lnt8TjLrhvOg4Mcnb44oD8L1fuIoPeAw14itTuD0A/sWNxBAb
	 CLR8xjzLfMb3LHTAPUsHwMOjFVi/O2yHLGIGgSSnImnO/38qNb60U7iLH5slpbnYmT
	 qioQ8mNfILPuU1a38CQtdf+IEW/vktmgo/iS5yVXz4aJGXRp6OF5zP1b15pmF+N3o1
	 HNxt/LckBFBNcXOGot8OlDh16jSmTNJFO4cy4v2KXsT03ntxDgXhmJPNMym5tgoS84
	 XX4gyQkyiNMbT4LPue9+T3Q9bjAcynQayhbGVCAlNCc3PHv0AcmbTgCdhgt6QP/ANA
	 rrHVPp/e+QMhw==
Received: from php-smtp4.php.net (localhost [127.0.0.1])
	by php-smtp4.php.net (Postfix) with ESMTP id 5A32D180AD1
	for <internals@lists.php.net>; Fri, 21 Jun 2024 16:40:40 +0000 (UTC)
X-Spam-Checker-Version: SpamAssassin 4.0.0 (2022-12-13) on php-smtp4.php.net
X-Spam-Level: 
X-Spam-Status: No, score=0.6 required=5.0 tests=BAYES_50,DKIM_SIGNED,
	DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,DMARC_MISSING,SPF_HELO_NONE,
	SPF_PASS,T_SCC_BODY_TEXT_LINE autolearn=no autolearn_force=no
	version=4.0.0
X-Spam-Virus: Error (Cannot connect to unix socket
	'/var/run/clamav/clamd.ctl': connect: Connection refused)
X-Envelope-From: <jbafford@zort.net>
Received: from nebula.zort.net (nebula.zort.net [96.241.205.3])
	(using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits))
	(No client certificate requested)
	by php-smtp4.php.net (Postfix) with ESMTPS
	for <internals@lists.php.net>; Fri, 21 Jun 2024 16:40:39 +0000 (UTC)
Received: from smtpclient.apple (pulsar.zort.net [96.241.205.6])
	(using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits))
	(No client certificate requested)
	by nebula.zort.net (Postfix) with ESMTPSA id 9DB7320ACBB62;
	Fri, 21 Jun 2024 12:39:24 -0400 (EDT)
DKIM-Filter: OpenDKIM Filter v2.11.0 nebula.zort.net 9DB7320ACBB62
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=zort.net; s=zort;
	t=1718987964; bh=D9iRnY6UctYMsV+fZXRJEkbxbxkl0LGvqGLN8JOAsLA=;
	h=Subject:From:In-Reply-To:Date:Cc:References:To:From;
	b=M7fSwctHHrsmKULUOoqU3K1G0IhtvlUuI9STyTYTuJM1APdrc4nizYyf2eixDe1Bw
	 iXSW8pUcP8CMgIkzBDpiCN31wSh5u7l+OIdFCFH1zWIVF5zcRsnUVgwLDJm8W0RPlN
	 ax9m8ScL4sT6Ma0yxqBdsTkRkE0aZEJ7EURgMCkY=
Content-Type: text/plain;
	charset=utf-8
Precedence: bulk
list-help: <mailto:internals+help@lists.php.net
list-unsubscribe: <mailto:internals+unsubscribe@lists.php.net>
list-post: <mailto:internals@lists.php.net>
List-Id: internals.lists.php.net
Mime-Version: 1.0 (Mac OS X Mail 16.0 \(3774.600.62\))
Subject: Re: [PHP-DEV] [Early Feedback] Pattern matching
In-Reply-To: <7d825b1d-e584-4916-9435-3561b9c54c26@gmail.com>
Date: Fri, 21 Jun 2024 12:39:14 -0400
Cc: internals@lists.php.net
Content-Transfer-Encoding: quoted-printable
Message-ID: <86692EF2-D284-45A4-8505-F284D0D1A02D@zort.net>
References: <2a6b92eb-d5e9-4a1a-9548-a068ac42ebd2@app.fastmail.com>
 <02ee8831-43a0-4857-886e-7f54fb42a99d@varteg.nz>
 <CAB-Buja2B0_idnmjZFDNiQrGSRck-z-G7M1v8dNQ6ZyCf482OQ@mail.gmail.com>
 <CAPzBOBNLFmGESU-OEfp+ZVXdzKQ_H+yBT2Ak-hcrm1ZK25kUQA@mail.gmail.com>
 <7d825b1d-e584-4916-9435-3561b9c54c26@gmail.com>
To: Niels Dossche <dossche.niels@gmail.com>
X-Mailer: Apple Mail (2.3774.600.62)
From: jbafford@zort.net (John Bafford)



> On Jun 21, 2024, at 11:42, Niels Dossche <dossche.niels@gmail.com> =
wrote:
>=20
> On 21/06/2024 14:43, Robert Landers wrote:
>> On Fri, Jun 21, 2024 at 5:08=E2=80=AFAM Andreas Hennings =
<andreas@dqxtech.net> wrote:
>>>=20
>>> E.g. should something like array<int> be added to the type system in
>>> the future, or do we leave the type system behind, and rely on the =
new
>>> "guards"?
>>> public array $values is array<int>
>>> OR
>>> public array<int> $values
>>>=20
>>> The concern here would be if in the future we plan to extend the =
type
>>> system in a way that is inconsistent or incompatible with the =
pattern
>>> matching system.
>>>=20
>>> --- Andreas
>>=20
>> I'm always surprised why arrays can't keep track of their internal
>> types. Every time an item is added to the map, just chuck in the type
>> and a count, then if it is removed, decrement the counter, and if
>> zero, remove the type. Thus checking if an array is `array<int>`
>> should be a near O(1) operation. Memory usage might be an issue (a
>> couple bytes per type in the array), but not terrible.... but then
>> again, I've been digging into the type system quite a bit over the
>> last few months.
>=20
> And every time a modification happens, directly or indirectly, you'll
> have to modify the counts too. Given how much arrays / hash tables are
> used within the PHP codebase, this will eventually add up to a lot of
> overhead. A lot of internal functions that work with arrays will need
> to be audited and updated too. Lots of potential for introducing bugs.
> It's (unfortunately) not a matter of "just" adding some counts.


This is straying a bit for this RFC's discussion, but, I'm wondering if =
a better approach to generics for arrays would be to just not do =
generics for arrays.

Instead, have generics be a class-only thing, and add new built-in types =
(along the lines of the classes/interfaces in the Data Structures =
extension) specifically to provide collection support. This would =
accomplish several things:

* Separate object types (e.g. Array, Map, OrderedMap, Set, SparseArray, =
etc) rather than one "array" type that does everything. Each could have =
underlying storage and accessors optimized for one specific use-case, =
rather than having to be efficient with several different use-cases.
* No BC breaks. array and all the existing array_* functions remain =
untouched and unchanged. Somewhere years down the line, they can be =
discouraged in favor of the new interfaces.
* Being objects, these new data types would all have a fancy OOP =
interface, which could make chaining operations easy.

The major interoperability concern in this model would be the cost of =
translating between the new types and legacy array types at API =
boundaries for legacy code. Possibly this might limit utility to =
greenfield development. But since it'd be entirely new and opt-in types, =
there's no direct BC concerns, and maybe some of the typechecking perf =
hit when you validate inserts/updates could be elided by the optimizer =
in the presence of typehints. (e.g. you have an Array<int> and you =
insert a value the compiler or optimizer can prove is an int, you don't =
need to do a runtime type check.) There'd also probably have to be =
something done to maintain the COW semantics that array has without =
having to have explicit clone operations.

-John