Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:92554
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: pass (pb1.pair.com: domain googlemail.com designates 74.125.82.44 as permitted sender)
MIME-Version: 1.0
In-Reply-To: <CAFp73Xu2dM+E9Ri8dN-yt9Ha6-1UmOtD0RYq+HZXbjvzcWqJwg@mail.gmail.com>
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>
	<CAFKaYMq_KFrygXwcuTd85y11X0_YMFop2tum+8jjXnkGKON6QA@mail.gmail.com>
	<CAFp73Xu2dM+E9Ri8dN-yt9Ha6-1UmOtD0RYq+HZXbjvzcWqJwg@mail.gmail.com>
Date: Wed, 20 Apr 2016 16:43:40 +0100
Message-ID: <CAFKaYMpWN+9uBqJ_p6-p14ZqYm0cm+q3LHkY3o9q7EvFCBS9Bg@mail.gmail.com>
To: guilhermeblanco@gmail.com
Cc: Mathieu Rochette <mathieu@texthtml.net>, Josh Di Fabio <joshdifabio@gmail.com>, 
	"Ben Scholzen 'DASPRiD'" <mail@dasprids.de>, Sara Golemon <pollita@php.net>, 
	PHP internals <internals@lists.php.net>, Rasmus Schultz <rasmus@mindplay.dk>, 
	Mathieu Rochette <mathieu@rochette.cc>
Content-Type: multipart/alternative; boundary=001a1130cd7c3393c00530ec755a
Subject: Re: [PHP-DEV] [RFC:generics]
From: codekestrel@googlemail.com (Dominic Grostate)

--001a1130cd7c3393c00530ec755a
Content-Type: text/plain; charset=UTF-8

I agree on both points (technically).  It would allow you to apply that
restriction.  I only advise against it to reduce the impact the initial
implementation would have on the codebase, provided it is preferable to
implement it in phases.

As for inference. Rasmus and I have argued over that a fair bit, as I was
in favour of using 'new Entry<>' or just 'new Entry' to be a parameterised
type with no type constraints (any value).
On 20 Apr 2016 3:44 p.m., "guilhermeblanco@gmail.com" <
guilhermeblanco@gmail.com> wrote:

> I don't know if mid-thread answering may lead to top-posting, but if it
> does, I'm sorry... =\
>
> Answer inline:
>
> On Wed, Apr 20, 2016 at 5:10 AM, Dominic Grostate <
> codekestrel@googlemail.com> wrote:
>
>> 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.
>>
>
> Unions and Intersections are required anyway, and I don't see how you can
> implement generics without supporting them.
> Let's say I'm implementing a cache library that segregate the interface of
> BulkOperations from the basic operations named CacheDriver.
> In a given class, I might want to only accept CacheDrivers that also
> support BulkOperations. How would I achieve that?
>
> The same happens to upper bounds that someone asked for an example
> privately.
> If I want to hire/move a person to a department that is registered in the
> system, but is not a 3rd party company person, how would you achieve that
> considering the following class structure?
>
> class Person {}
> class Employee extends Person {}
> class AssociateEmployee extends Employee {}
> class Manager extends Employee {}
>
> Considering your function:
>
> function assignToDepartment<T>(T $person) : bool;
>
> Generic type "T" in the function prototype needs to accept Person (new
> hire), Employee and Manager (transfer), but not AssociateEmployee.
> Considering upper bounds support only, your best bet is "T extends Person",
> but that would accept AssociateEmployee to be provided, which contradicts
> the business rule. Accepting anything lower in the hierarchy prevents new
> hires.
> That's when lower bounds comes into play. If you define as "T super
> Manager", all Person, Employee and Manager gets accepted, but not the
> AssociatedEmployee, matching properly the business rule.
>
>
> Also, someone else asked about type inference over my comment #4 in this
> example:
>
> class Foo<A> {
>     public function __construct<B>(B $b) {}
> }
>
> $foo = new Foo<string>(1);
>
> The question asked is if that "string" was an inference over A or B. The
> correct answer is A, because generic type B is inferred from the parameter
> (integer) provided. That is exactly why class generic type definition
> should never be inferred from the constructor arguments, because you make
> it impossible to support both constructor generic types AND class generic
> type definitions at the same time.
>
>
>
>> 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
>> >>
>> >>
>> >
>>
>
>
>
> --
> Guilherme Blanco
> Lead Architect at E-Block
>

--001a1130cd7c3393c00530ec755a--