Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:92544
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: pass (pb1.pair.com: domain gmail.com designates 209.85.223.174 as permitted sender)
MIME-Version: 1.0
In-Reply-To: <CAFKaYMq_KFrygXwcuTd85y11X0_YMFop2tum+8jjXnkGKON6QA@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>
Date: Wed, 20 Apr 2016 10:44:06 -0400
Message-ID: <CAFp73Xu2dM+E9Ri8dN-yt9Ha6-1UmOtD0RYq+HZXbjvzcWqJwg@mail.gmail.com>
To: Dominic Grostate <codekestrel@googlemail.com>
Cc: Mathieu Rochette <mathieu@rochette.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=94eb2c0883e05c93c00530eba146
Subject: Re: [PHP-DEV] [RFC:generics]
From: guilhermeblanco@gmail.com ("guilhermeblanco@gmail.com")

--94eb2c0883e05c93c00530eba146
Content-Type: text/plain; charset=UTF-8

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

--94eb2c0883e05c93c00530eba146--