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., "guilhermebla...@gmail.com" <
guilhermebla...@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 <
> codekest...@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" <math...@rochette.cc> wrote:
>>
>> >
>> >
>> > On 20/04/2016 00:22, Sara Golemon wrote:
>> >
>> >> On Tue, Apr 19, 2016 at 1:16 PM, Mathieu Rochette <
>> math...@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
>
