Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:92528
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: pass (pb1.pair.com: domain googlemail.com designates 74.125.82.47 as permitted sender)
MIME-Version: 1.0
In-Reply-To: <57173859.4080501@rochette.cc>
References: <CADqTB_gUbfu91QRm1U0KyDjai8DKw7yCE6QxgUecy60oq3Zi8Q@mail.gmail.com>
	<CAKiSzdCO83XM0zqAeFnjQEMJvbd0yBmYAFnj0H6AtDumofVbkw@mail.gmail.com>
	<CAKiSzdCCEF=7OWtvZETG3bRoByCCLqEAEjuLW_H6m7MmDtJ8_g@mail.gmail.com>
	<CAFKaYMoQUUFLqgDjOHj3W0+a63u3s=vqnU5gWMCj0zvmvXFF5Q@mail.gmail.com>
	<3cc8a4c7-2640-11ae-a67b-06f909ac1e27@texthtml.net>
	<CAESVnVqCZnrbHa+5_tSYG70VyvGfpZoDM98bEst3pg36HahYEg@mail.gmail.com>
	<57173859.4080501@rochette.cc>
Date: Wed, 20 Apr 2016 10:10:47 +0100
Message-ID: <CAFKaYMq_KFrygXwcuTd85y11X0_YMFop2tum+8jjXnkGKON6QA@mail.gmail.com>
To: Mathieu Rochette <mathieu@rochette.cc>
Cc: "Ben Scholzen 'DASPRiD'" <mail@dasprids.de>, Josh Di Fabio <joshdifabio@gmail.com>, 
	Mathieu Rochette <mathieu@texthtml.net>, Sara Golemon <pollita@php.net>, 
	PHP internals <internals@lists.php.net>, Rasmus Schultz <rasmus@mindplay.dk>
Content-Type: multipart/alternative; boundary=001a114b2d5a2272a40530e6f8c7
Subject: Re: [PHP-DEV] [RFC:generics]
From: codekestrel@googlemail.com (Dominic Grostate)

--001a114b2d5a2272a40530e6f8c7
Content-Type: text/plain; charset=UTF-8

I've made an amendment to the RFC to clarify on the Nested Types, which is
indeed supposed to be part of the feature.  Rasmus may want to reword it if
it isn't very clear.

Regarding union and intersections for upper (and maybe lower) bounds.
Would it be appropriate to exclude these from type parameters until their
respective RFCs are approved?  As including them in generics but not in
standard type hints may create an inconsistency.

In short, perhaps a generics implementation should incorporate unions (and
any future type constraints) as existing features only.  This would help
RFC Generics to focus on: Type aliasing, Introspection and Reflection.
On 20 Apr 2016 9:05 a.m., "Mathieu Rochette" <mathieu@rochette.cc> wrote:

>
>
> On 20/04/2016 00:22, Sara Golemon wrote:
>
>> On Tue, Apr 19, 2016 at 1:16 PM, Mathieu Rochette <mathieu@texthtml.net>
>> wrote:
>>
>>> about the upper bounds, have you consider another way of describing the
>>> constraints, eg:
>>>
>>> class Box<T> where T is Boxable
>>>
>>> this would allow multiple constraints, eg:
>>>
>>> class Collection<T> where T is Traversable, T is Countable
>>>
>>> IMO, this sort of problem should be solved by combining this feature
>> with union types, so you could have something like:
>>
>> class Collection<T as (Traversable | Countable)> {...
>>
>> And merely inherit the logic rules from that feature rather than
>> inventing yet another one.
>>
> obviously if the union type rfc passes we don't need another way of
> expressing this.
> that was only in the case it does not, I think having a way to have at
> least types intersection
> is useful here (and I didn't event think about <T is A & B>)
>
>>
>> can generic types be nested ?
>>>
>>> class Stuff<A, B is Something<A, string>>
>>>
>>> I can't imagine why not...
>>
> just to be clear, it's not just nested generic. the A type have to be same
> in both "subtypes"
>
>>
>> For my part, I love the concept overall.  Generics are an important
>> part of moving PHP towards comprehensive type-safety.  But then, you
>> know how I feel about Hack. :)
>>
>> -Sara
>>
>>
>

--001a114b2d5a2272a40530e6f8c7--