Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:101673
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: pass (pb1.pair.com: domain gmail.com designates 209.85.213.180 as permitted sender)
MIME-Version: 1.0
In-Reply-To: <9b12b0e2-185e-86fb-0e0b-c4f24bfbd661@gmail.com>
References: <CAEUnE0cRR6jtU2GoeiP4SDLJejF4+6zY=fT1FiTKPe6aKwoFqg@mail.gmail.com>
 <alpine.DEB.2.21.1801251441310.24989@singlemalt.home.derickrethans.nl> <9b12b0e2-185e-86fb-0e0b-c4f24bfbd661@gmail.com>
Date: Thu, 25 Jan 2018 14:19:38 -0600
Message-ID: <CAEUnE0fBE2eGbfimWw+AhPG+ZZ8WRNDLB+i1wE14NF_HARbQHQ@mail.gmail.com>
To: PHP internals <internals@lists.php.net>
Content-Type: multipart/alternative; boundary="001a113bddf4d57e2505639f7f0e"
Subject: Re: [PHP-DEV][RFC][DISCUSSION] Collection Inspection
From: tendoaki@gmail.com (Michael Morris)

--001a113bddf4d57e2505639f7f0e
Content-Type: text/plain; charset="UTF-8"

On Thu, Jan 25, 2018 at 2:10 PM, Rowan Collins <rowan.collins@gmail.com>
wrote:

> On 25/01/2018 14:52, Derick Rethans wrote:
>
>> IMO, it makes a lot more sense to check integrity when creating the
>> "array" structure. Instead, I would suggest to add a native Collection
>> type, that takes a "type" as argument. They aren't quite full generics,
>> but it does 1. fix something; 2. isn't really complicated.
>>
>> What I am suggesting is to add a new syntax "Collection<$type>",
>> mimicking a class, but having a type as "argument":
>>
>> $a = new Collection<integer>;
>>
>
> So would I be right in thinking this would mean adding basic support for
> generics to the engine, but not letting new ones be defined in userland?
> So, a bit like how internal or extension classes have the ability to do
> more overloading of casts and operators than userland classes?
>
> If so, I like the concept, but wonder whether the parts of the
> implementation it would need are the easy parts of the hard ones. I guess
> not being able to inherit from the generic would get rid of a bunch of
> complexity, but don't really know where else the challenge lies.
>

He's getting the syntax from Java.  Java collections allow you to specify
the type they are constrained to in <> after the class name.  Type Script
does something similar.  The problem is that Java already has the policing
mechanics present in the runtime to police insertions into the collection
and guarantee they are of the correct type.  PHP has no such mechanism in
place and in previous discussion threads the primary maintainers have
underscored that adding such is highly difficult.

It is also completely tangential to and a distraction from what I propose
and would like to focus on here.  Regardless of whether PHP ever gets a
core class or construct for type uniform collections, the ability to verify
that variables are a "collection of something" will remain.  That is the
issue I want to discuss and address here - verifying that existing
variables are a given collection type, not debating pie-in-the-sky, may
never be implementable classes that self insure their own integrity.

So, given `$a collectionof string` the operator returns whether or not $a
is, at that time, a collection of strings (be it an array or other
iterable). It doesn't insure $a will stay that way - it's just a check of
the variables status at a given moment, which is the best that can be hoped
for in PHP.

--001a113bddf4d57e2505639f7f0e--