Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:101675
Return-Path: <me@kelunik.com>
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Delivered-To: mailing list internals@lists.php.net
Received: (qmail 88476 invoked from network); 25 Jan 2018 20:40:00 -0000
Received: from unknown (HELO lists.php.net) (127.0.0.1)
  by localhost with SMTP; 25 Jan 2018 20:40:00 -0000
Authentication-Results: pb1.pair.com header.from=me@kelunik.com; sender-id=unknown
Authentication-Results: pb1.pair.com smtp.mail=me@kelunik.com; spf=permerror; sender-id=unknown
Received-SPF: error (pb1.pair.com: domain kelunik.com from 81.169.146.221 cause and error)
X-PHP-List-Original-Sender: me@kelunik.com
X-Host-Fingerprint: 81.169.146.221 mo4-p00-ob.smtp.rzone.de  
Received: from [81.169.146.221] ([81.169.146.221:20321] helo=mo4-p00-ob.smtp.rzone.de)
	by pb1.pair.com (ecelerity 2.1.1.9-wez r(12769M)) with ESMTP
	id 83/A4-61119-3904A6A5 for <internals@lists.php.net>; Thu, 25 Jan 2018 15:39:50 -0500
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; t=1516912785;
	s=strato-dkim-0002; d=kelunik.com;
	h=Content-Type:Cc:To:Subject:Message-ID:Date:From:In-Reply-To:
	References:X-RZG-CLASS-ID:X-RZG-AUTH;
	bh=9BGIo60bRcvF9xiaw1ZIGc2nTFldJUZ66Y9gRfaLV6Q=;
	b=szHz69KYEvL9M9IV+inpkxAd700NLB0Z6nBkBk33dI3X2zUNTulZ/bLHozkIPcFl+r
	IxAj7wArHaNmKL6m7OsCAwmI5Aq0+aPYZTykZsAbLPKoz8/EMhf2koZ3qxYKD7zIRLb6
	rqitcr+5HOcUDI1SuuLgw4ttslf9fUju4/XKPow7B4hXRCX3TykEBM0KqpOS5mZ95dyl
	WMEgBoPlWawGmj6gCCto9AzIKZIAVK4auT7+SNMSdVhMxnryIxP+H1M5jV/cSzNWh2B2
	R4+n5Xm0NcSO25n84lCzZPEI1E7qirazOHdZTHPT2+V/bhuhTrF2NTuIA6vRm9BoKCXs
	r0PA==
X-RZG-AUTH: :IWkkfkWkbvHsXQGmRYmUo9mlsGbEv0XHBzMIJSS+jKTzde5mDb8DayQcEfe5lw==
X-RZG-CLASS-ID: mo00
Received: by mail-wr0-f175.google.com with SMTP id i56so297687wra.7
        for <internals@lists.php.net>; Thu, 25 Jan 2018 12:39:44 -0800 (PST)
X-Gm-Message-State: AKwxyteTL7u55OZ1riPZRc1665IMYs9nq9GqAXC5J6F3MoCzW3ELTup1
	GzwNDVxMmmHXbNm4TKChaecNBNDpcHvCBhD2nKY=
X-Google-Smtp-Source: AH8x227HLUJz9Ss4ILGGMGa8LIFHnkFkIItA/fKo4oUUERiEA0r0DQP8B7nW+Xb1SWzVF5z4JChxOaRhJA2LYw7WuyQ=
X-Received: by 10.223.158.195 with SMTP id b3mr9601018wrf.236.1516912784762;
 Thu, 25 Jan 2018 12:39:44 -0800 (PST)
MIME-Version: 1.0
References: <CAEUnE0cRR6jtU2GoeiP4SDLJejF4+6zY=fT1FiTKPe6aKwoFqg@mail.gmail.com>
 <alpine.DEB.2.21.1801251441310.24989@singlemalt.home.derickrethans.nl>
 <9b12b0e2-185e-86fb-0e0b-c4f24bfbd661@gmail.com> <CAEUnE0fBE2eGbfimWw+AhPG+ZZ8WRNDLB+i1wE14NF_HARbQHQ@mail.gmail.com>
In-Reply-To: <CAEUnE0fBE2eGbfimWw+AhPG+ZZ8WRNDLB+i1wE14NF_HARbQHQ@mail.gmail.com>
Date: Thu, 25 Jan 2018 20:39:33 +0000
X-Gmail-Original-Message-ID: <CANUQDChnG6fzFTr-RWixscg7pRy+dgqhwvUetRzjDxifmSiXHw@mail.gmail.com>
Message-ID: <CANUQDChnG6fzFTr-RWixscg7pRy+dgqhwvUetRzjDxifmSiXHw@mail.gmail.com>
To: Michael Morris <tendoaki@gmail.com>
Cc: PHP internals <internals@lists.php.net>
Content-Type: multipart/alternative; boundary="089e0820b818b0eddb05639fc76f"
Subject: Re: [PHP-DEV][RFC][DISCUSSION] Collection Inspection
From: me@kelunik.com (Niklas Keller)

--089e0820b818b0eddb05639fc76f
Content-Type: text/plain; charset="UTF-8"

Michael Morris <tendoaki@gmail.com> schrieb am Do., 25. Jan. 2018, 21:19:

> 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.
>

That should be a function, not an operator, unless you can bring up very
good arguments to make it an operator.

Regards, Niklas

>

--089e0820b818b0eddb05639fc76f--