Newsgroups: php.internals Path: news.php.net Xref: news.php.net php.internals:92936 Return-Path: Mailing-List: contact internals-help@lists.php.net; run by ezmlm Delivered-To: mailing list internals@lists.php.net Received: (qmail 56473 invoked from network); 29 Apr 2016 14:33:30 -0000 Received: from unknown (HELO lists.php.net) (127.0.0.1) by localhost with SMTP; 29 Apr 2016 14:33:30 -0000 Authentication-Results: pb1.pair.com smtp.mail=guilhermeblanco@gmail.com; spf=pass; sender-id=pass Authentication-Results: pb1.pair.com header.from=guilhermeblanco@gmail.com; sender-id=pass Received-SPF: pass (pb1.pair.com: domain gmail.com designates 209.85.213.177 as permitted sender) X-PHP-List-Original-Sender: guilhermeblanco@gmail.com X-Host-Fingerprint: 209.85.213.177 mail-ig0-f177.google.com Received: from [209.85.213.177] ([209.85.213.177:37558] helo=mail-ig0-f177.google.com) by pb1.pair.com (ecelerity 2.1.1.9-wez r(12769M)) with ESMTP id 98/9B-26386-7B073275 for ; Fri, 29 Apr 2016 10:33:29 -0400 Received: by mail-ig0-f177.google.com with SMTP id s8so21155980ign.0 for ; Fri, 29 Apr 2016 07:33:27 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=dDj3AEMubDjGTknkLJgmwFpOBZCBbRfaXDAxfDXznV4=; b=d5LzXwQj2zs0IytQExa1g2dEJPIWQIvvF3+dYgQTpStnA8Jb94q6cINu5NNoXid322 Nl0GdCdRLbBerqeuIoAH5+bV+UiMlBMPMkPDf3y3U5Od8uYKOVXbvJyq6kLeOEUuO5Jf RkKpTFRN6V6pGc0H741SCrd2JfAZQCsVc+Vu+nDRbjYYN/KaUcZYJLbazfz/CHiGJh05 IDn/Dtwsw9xR5dStEWRcPoX8XcR3aqzcSStOa9YVY5/DDTAgBXWY1yDEg13rzqnqtmsd JVURcJhdthuzHOtgdr+2ZFnXJovlzuJQe3AaJw8r8QerzYuahKK9P0/ubpbSnkQ47qqE JeyA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=dDj3AEMubDjGTknkLJgmwFpOBZCBbRfaXDAxfDXznV4=; b=WpRv7te3X5NBX/piDhrmkNWNUEFJy8KSC8KOs1cUPHWkv5CJz134w+MSikjAjSHwy3 mAxRw3wFDNpUobS2fKHD97zbpS3/p2W7GAxg7flOqPmLWci2R2J55p4SMXYNYrZnFGIG oUmuwRQ//7KbOAvIwZ/wK9yDQu9Rm35dcVTs+5LyNijq88/fMzt2y5wZlseUKfyq9gbc 0O1UY9w7tcqYpARDCP1s5SJYzQa6nZ3Dmgk9x1cPHiU9g1Mt3kIvCZY9f17fLPT/Kla/ Qtp9sq7164lCuKbk7nkU+S0W2fH21WylK5lpdw4NsmTHHHSY1s5y/1gZ717EcuIhsDjj wR3Q== X-Gm-Message-State: AOPr4FXZqirS2gM72109ciRcjyXu7zMy7z0yGDmlJDcTNxe/1XAv7TiO/Ljldhx/YQARGLwJ8MfiGt+2Pm5/3w== X-Received: by 10.50.123.132 with SMTP id ma4mr5047267igb.92.1461940405152; Fri, 29 Apr 2016 07:33:25 -0700 (PDT) MIME-Version: 1.0 Received: by 10.50.70.162 with HTTP; Fri, 29 Apr 2016 07:33:05 -0700 (PDT) In-Reply-To: References: <3cc8a4c7-2640-11ae-a67b-06f909ac1e27@texthtml.net> <57173859.4080501@rochette.cc> <013101d19ff8$596b6010$0c422030$@tutteli.ch> Date: Fri, 29 Apr 2016 10:33:05 -0400 Message-ID: To: Jesse Schalken Cc: Robert Stoll , Rasmus Schultz , Josh Di Fabio , Dominic Grostate , Mathieu Rochette , "Ben Scholzen 'DASPRiD'" , Sara Golemon , PHP internals , Mathieu Rochette Content-Type: multipart/alternative; boundary=001a113603be8833ce0531a086f2 Subject: Re: [PHP-DEV] [RFC:generics] From: guilhermeblanco@gmail.com ("guilhermeblanco@gmail.com") --001a113603be8833ce0531a086f2 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Sorry for top-posting... it looks like GMail top-posts everything that doesn't have a reply character right before the inherited (replied email), which i just did. On Fri, Apr 29, 2016 at 10:26 AM, guilhermeblanco@gmail.com < guilhermeblanco@gmail.com> wrote: > > > On Fri, Apr 29, 2016 at 4:55 AM, Jesse Schalken > wrote: > >> >> >> On Wed, Apr 27, 2016 at 6:50 AM, guilhermeblanco@gmail.com < >> guilhermeblanco@gmail.com> wrote: >> >>> Hi all, >>> >>> Yesterday I spent a considerable 2h talking about Generics in Doctrine >>> channel. >>> We discussed the specifics of each boundary that PHP's implementation >>> could >>> take advantage. Here are our findings, which I'll illustrate using Java >>> equivalents: >>> >>> 1- Upper bounds (T extends A) >>> >>> We all understood they're required. Whenever you mention class Foo>> A> >>> {}, we're talking that T can be A or any of its subtypes. >>> Also, we debated over intersection types. It's an edge case, and its >>> support could be done as a subsequent RFC once union and intersection >>> types >>> gets resolved. >>> >>> 2- Lower bounds (T super A) >>> >>> It was just not possible to come up with a single use case or >>> possibility. >>> It not only violates Liskov, but it also doesn't make any sense in the >>> context of PHP. >>> When we debate about Java, it does make sense because of polymorphism a= nd >>> the requirement removal of implementing multiple methods. >>> >>> 3- Unbounded wildcards (?) >>> >>> It wouldn't be necessary in the context of PHP. Why? >>> Once we introduce Generics, the difference between process(List $list) >>> and >>> process(List $list) would be none, as due to PHP's nature. >>> >>> 4- Upper bounded wildcard (? extends A) >>> >>> Again, invalid in the context of PHP. Let me explain why... >>> In Java context, whenever you declare something as List, you can onl= y >>> add As to the list, but no subtypes. When you declare List= , >>> you can add A and also any of its subtypes. >>> PHP is loose in this restriction, so there's no way of strict-ing to >>> only A >>> but not subtypes. Defining as List would be enough, and PHP wouldn't >>> support adding A and A only. >>> >> >> >> You can add subtypes of A to a List in Java. What List >> means is that the list itself may be a list of any type, provided that t= ype >> is compatible with A. So if B extends A, List is compatible with List= > extends A>, and when reading items you can assume they will be compatibl= e >> with A (since B extends A) but you can't add an A (because it's actually= a >> list of Bs). >> >> > Wrong. This is documented here > https://docs.oracle.com/javase/tutorial/java/generics/upperBounded.html > and specifically states: > > To write the method that works on lists of Number and the subtypes of >> Number, such as Integer, Double, and Float, you would specify List> extends Number>. The term List is more restrictive than List> extends Number> because the former matches a list of type Number only, >> whereas the latter matches a list of type Number or any of its >> subclasses. > > > > >> Similarly, List means it may be a list of A or some super typ= e >> of A. So if A extends C, List is compatible with List, and >> you can add an A (because A is compatible with C) but when reading items >> you can't assume they're going to be As (because it's actually a list of >> Cs). >> >> > Again wrong. The lower bound also respect the rules of upper bound > wildcard. If you return a List, you cannot add an A instance. > > >> This is my understanding of variance behaviour and notation in the three >> languages I'm most familiar with: >> >> Covariance (Foo is a subtype of Foo) >> >> Java Foo at usage Methods accepting T as parameter cannot >> be called >> Hack Foo<+T> at declaration Methods accepting T as parameter cannot >> be defined >> C# Foo at declaration Methods accepting T as parameter cannot >> be defined >> >> >> Contravariance (Foo is a subtype of Foo) >> >> Java Foo at usage Methods returning T can be called but >> return Object >> Hack Foo<-T> at declaration Methods returning T cannot be defined >> C# Foo at declaration Methods returning T cannot be defined >> >> >> Invariance (no relationship between Foo and Foo) >> >> Java Foo at usage Methods accepting T and returning T can >> both be called >> Hack Foo at declaration Methods accepting T and returning T can >> both be defined >> C# Foo at declaration Methods accepting T and returning T can >> both be defined >> >> >> (There are more general rules for method signatures when T is used as th= e >> parameter for another generic type, but I can't remember what they are.) >> >> I can't see variance mentioned in the RFC, but when I asked about it whe= n >> the RFC was posted on Reddit, Rasmus said the type parameters would alwa= ys >> be covariant, so Foo in PHP as an annotation would be equivalent to >> Foo in Java, even though this has the opposite of the >> intended effect if Foo has methods which accept a parameter of the gener= ic >> type, such as something like List::add(T $element), Callback::run(= T >> $data) or Box::setContents(T $contents). >> >> > Rasmus is purely following already defined PHP covariance definition that > currently exists for type hinting into generic types. > Java differs from that and accept covariance for type definitions, but > restricts for generic types. > > >> My view is that PHP's generics should be invariant to start with (generi= c >> arrays can still be covariant of course, since they are passed by value)= , >> maintaining type safety and matching the behaviour of Java, Hack and C# = for >> type parameters without variance annotations, and variance syntax should= be >> added later as another RFC as demand arises. >> >> >> >> 5- Lower bounded wildcard (? super A) >>> >>> Applies the same concept of #2. PHP doesn't need it as it doesn't fully >>> support polymorphism. >>> >>> 6- Reflection >>> >>> We discussed over an example I extracted from a piece of code I current= ly >>> work on. We came with several ideas, but couldn't wrap up (but we're >>> 80%) a >>> valid approach. The example we debated was this one: >>> https://gist.github.com/guilhermeblanco/56ec0e11e7b029c2cfdcaf6fe232374= 2 >>> >>> >>> >>> >>> So I'll have to say sorry for poking around of "missing implementation" >>> while in reality most of them cannot be applied in the context of PHP. >>> I've reviewed the RFC again and it mostly makes sense surrounding >>> boundaries. I still have to talk about diamond operator and constructor >>> generic type. >>> >>> >>> []s, >>> >>> >>> On Tue, Apr 26, 2016 at 4:15 PM, Robert Stoll wrote: >>> >>> > >>> > >>> > > -----Urspr=C3=BCngliche Nachricht----- >>> > > Von: Rasmus Schultz [mailto:rasmus@mindplay.dk] >>> > > Gesendet: Montag, 25. April 2016 18:09 >>> > > An: Josh Di Fabio >>> > > Cc: Dominic Grostate; Guilherme Blanco; Mathieu Rochette; Ben >>> Scholzen >>> > 'DASPRiD'; Sara Golemon; PHP internals; Mathieu >>> > > Rochette >>> > > Betreff: Re: [PHP-DEV] [RFC:generics] >>> > > >>> > > > I really don't like 'as' in this context, even if Hack uses it, a= s >>> it >>> > > > doesn't reflect in English terms what the code is doing. As other= s >>> > > > have already said, it reads as if 'T' is being aliased to 'Bar'. >>> > > >>> > > I second that. >>> > > >>> > > I hear the concerns about adding another reserved word "is" though, >>> so >>> > I'd like to suggest simply using a ":" ... as in: >>> > > >>> > > class A { ... } >>> > >>> > In this case I would suggest to use class A which leaves roo= m >>> > open to define lower bounds later on (either with <: as well or with >>> :> as >>> > in scala) >>> > >>> > > >>> > > Consistent with return type-hints, it should feel like home? >>> > > >>> > > For sure nobody wants to type out "instanceof", and (as pointed out >>> in >>> > the RFC) the instanceof operator checks the type of >>> > > an object, which is *not* what this is doing - a type argument is >>> not an >>> > "instance of" anything. The ":" is more neutral in that >>> > > regard maybe? >>> > > >>> > > >>> > > On Thu, Apr 21, 2016 at 10:32 AM, Josh Di Fabio < >>> joshdifabio@gmail.com> >>> > wrote: >>> > > > On Wed, Apr 20, 2016 at 8:17 PM, Dominic Grostate >>> > > > wrote: >>> > > >> Thanks for you're input everyone. >>> > > >> >>> > > >> So far, we have read some ideas for handling upper bounds, or >>> > > >> multiple there of. >>> > > >> The preferred keywords appear to be either "as" or "instanceof". >>> > > >> >>> > > >> class Foo {} >>> > > >> class Foo {} >>> > > >> >>> > > >> We would like to know for sure then if everyone is largely again= st >>> > > >> the addition of an "is" keyword, in favour of one of the other >>> two. >>> > > >> >>> > > > >>> > > > I really don't like 'as' in this context, even if Hack uses it, a= s >>> it >>> > > > doesn't reflect in English terms what the code is doing. As other= s >>> > > > have already said, it reads as if 'T' is being aliased to 'Bar'. >>> > > > >>> > > > On Wed, Apr 20, 2016 at 8:17 PM, Dominic Grostate >>> > > > wrote: >>> > > >> Thanks for you're input everyone. >>> > > >> >>> > > >> So far, we have read some ideas for handling upper bounds, or >>> > > >> multiple there of. >>> > > >> The preferred keywords appear to be either "as" or "instanceof". >>> > > >> >>> > > >> class Foo {} >>> > > >> class Foo {} >>> > > >> >>> > > >> We would like to know for sure then if everyone is largely again= st >>> > > >> the addition of an "is" keyword, in favour of one of the other >>> two. >>> > > >> >>> > > >> ---------------- >>> > > >> >>> > > >> There is also a desire to include unions and intersections. >>> > > >> Presently though, this feature feels tied in with >>> > > >> https://wiki.php.net/rfc/union_types meaning if union types are >>> > > >> approved, then generics would have to support them as well. >>> Likewise >>> > > >> if this feature becomes approved in generics, it would make sens= e >>> to >>> > > >> support them in regular type hints as well. >>> > > >> >>> > > >> ---------------- >>> > > >> >>> > > >> The RFC makes a reference to generic closures, which may look >>> > > >> something like >>> > > >> this: >>> > > >> >>> > > >> function my_function(callable $func) { >>> > > >> >>> > > >> } >>> > > >> >>> > > >> However, an RFC already exists which is very similar to this >>> feature >>> > > >> at https://wiki.php.net/rfc/callable-types >>> > > >> As it currently standards these RFCs appear incompatible with ea= ch >>> > > >> other (please correct me if I am wrong). >>> > > >> >>> > > >> My question about this is would you prefer the generics RFC >>> exclude >>> > > >> this part in favour of a separate or later RFC. >>> > > >> Initially the proposal included generic arrays "array". >>> > > >> However to ease the implementation it was decided that should be= a >>> > separate feature. >>> > > >> So we'd like to find out if everyone else feels the same way abo= ut >>> > > >> callable types. >>> > > >> >>> > > >> ---------------- >>> > > >> >>> > > >> This RFC currently doesn't specify in detail how reflection woul= d >>> > > >> work. We have attempted a few API designs, but due to generic >>> > classes being ... >>> > > >> generic, it is difficult to find a suitable way to glean >>> information >>> > > >> about a class in a backwards compatible manner. So we will need >>> some >>> > > >> help on this one. >>> > > >> >>> > > >> ----------------- >>> > > >> >>> > > >> Aside from these top issues on our own list, however does everyo= ne >>> > > >> feel about the proposal in general? >>> > > >> As the RFC is still in draft, we will continue to make changes t= o >>> it >>> > > >> as more popular idea pop up, so please continue. >>> > > >> >>> > > >> Thanks. >>> > > >> >>> > > >> PS: I wasn't properly subscribed to the mailing list, so I misse= d >>> a >>> > > >> few important messages that were mailed directly to internals, b= ut >>> > > >> hopefully I've managed to fix that now. >>> > > >>> > > -- >>> > > PHP Internals - PHP Runtime Development Mailing List To unsubscribe= , >>> > visit: http://www.php.net/unsub.php >>> > >>> > >>> > >>> >>> >>> -- >>> Guilherme Blanco >>> Lead Architect at E-Block >>> >> >> > > > -- > Guilherme Blanco > Lead Architect at E-Block > --=20 Guilherme Blanco Lead Architect at E-Block --001a113603be8833ce0531a086f2--