Newsgroups: php.internals Path: news.php.net Xref: news.php.net php.internals:92828 Return-Path: Mailing-List: contact internals-help@lists.php.net; run by ezmlm Delivered-To: mailing list internals@lists.php.net Received: (qmail 64000 invoked from network); 27 Apr 2016 00:14:01 -0000 Received: from unknown (HELO lists.php.net) (127.0.0.1) by localhost with SMTP; 27 Apr 2016 00:14:01 -0000 Authentication-Results: pb1.pair.com header.from=codekestrel@googlemail.com; sender-id=pass Authentication-Results: pb1.pair.com smtp.mail=codekestrel@googlemail.com; spf=pass; sender-id=pass Received-SPF: pass (pb1.pair.com: domain googlemail.com designates 74.125.82.66 as permitted sender) X-PHP-List-Original-Sender: codekestrel@googlemail.com X-Host-Fingerprint: 74.125.82.66 mail-wm0-f66.google.com Received: from [74.125.82.66] ([74.125.82.66:35201] helo=mail-wm0-f66.google.com) by pb1.pair.com (ecelerity 2.1.1.9-wez r(12769M)) with ESMTP id C6/3F-20013-64400275 for ; Tue, 26 Apr 2016 20:13:59 -0400 Received: by mail-wm0-f66.google.com with SMTP id e201so8360473wme.2 for ; Tue, 26 Apr 2016 17:13:58 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=googlemail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc; bh=AH7sHgvGXzlHl7zbVGi1SImnXbl3GCB/t6/YR43eIXs=; b=jz/7JQn3zhGhqX/+goyH9UZsRBrvKIincsh6mvoaem18aZ5oPUfxBf0I6vQCsYHiJP /OWJNBc6Qo3b7LQnkZW4SWX006xyqfsDgq+SSdT8GLOrmStOAd5fIGjWHbBDBfybEDs0 xVjW3wtmXQe19weAWUnAPLXmmpVgtysafX7n9i3Zdkklo3tH1Ka6/xK3U9pcXpv+rMuS oZ+F72b5Kg/6as1CF31L0mOV9kqmSDMHJw8OpBmcRuGxnu2Y6sre/QHcSeTKihyF7zAm aLjyf/HCj61xyFf3PvxtWD0DombpTHx2kwmhvMqxSO4+U/7IhLP4Ld3YWbr96gSqfaX6 Q1vQ== 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:date :message-id:subject:from:to:cc; bh=AH7sHgvGXzlHl7zbVGi1SImnXbl3GCB/t6/YR43eIXs=; b=KHM7mA/XK3B2n4z2VufAmqla7tqpnTL1R+F/gyRcjZJvhKjugD9Racl5ReoyKfc+tf 0Lbivw1Qkd0Ot+hU+JfrKgD8e0inR4M805g6m3Tn5ef068bwurrz9n4qQHYe8V1ZX9RH B6iEoIyncqgiRoN8Xb9bz9XyLOKLVGBR70EEgg386n9c5Wau5Z7JHOSYJ149DW63hZ+1 kwc8W5ALo3wHF0bFA0Ns6IlHUUCCI9ahYxMD7QKryq7qmZfbTKyD1drkbU4+4BnZrINI WTLCgDaZIj9S8RxLsyDMjaopcru9bSSZcGEBiGLV4JjmXqYgjRyGnd8o23GKtIeeGq45 imww== X-Gm-Message-State: AOPr4FW+Aom0xQXwzqlJkskNxFeONDC/cKXFMaZE9bvp0q4qIiU1hnmsSfMFDUgrc8jY438fkzo+7WOJZuYnig== MIME-Version: 1.0 X-Received: by 10.28.138.193 with SMTP id m184mr21801133wmd.100.1461716035581; Tue, 26 Apr 2016 17:13:55 -0700 (PDT) Received: by 10.28.140.10 with HTTP; Tue, 26 Apr 2016 17:13:55 -0700 (PDT) Received: by 10.28.140.10 with HTTP; Tue, 26 Apr 2016 17:13:55 -0700 (PDT) In-Reply-To: References: <3cc8a4c7-2640-11ae-a67b-06f909ac1e27@texthtml.net> <57173859.4080501@rochette.cc> <013101d19ff8$596b6010$0c422030$@tutteli.ch> Date: Wed, 27 Apr 2016 01:13:55 +0100 Message-ID: To: Guilherme Blanco Cc: "Ben Scholzen 'DASPRiD'" , Mathieu Rochette , Sara Golemon , Mathieu Rochette , Josh Di Fabio , Robert Stoll , PHP internals , Rasmus Schultz Content-Type: multipart/alternative; boundary=001a114422be103d0605316c49ea Subject: Re: [PHP-DEV] [RFC:generics] From: codekestrel@googlemail.com (Dominic Grostate) --001a114422be103d0605316c49ea Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable I'm also a little fussy on lower bounds use cases. One of my brain waves to eliminate the need for reflection changes was to use a C++ templates like system. In effect the generic type, becomes a template with which all use cases spawn (cachable) spooled classes with all type aliases filled in. This way reflection would be performed on the parameterized type without needing any changes to reflection at all. The upside to this would have been class names could be represented with their type arguments. The down sides would have been the loss of generic class detection at runtime, and a new method of parsing class names would need to propagate throughout the entire engine. On 26 Apr 2016 9:51 p.m., "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 {}, 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 and 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 only 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. 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 currently 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/56ec0e11e7b029c2cfdcaf6fe2323742 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, as it > > > doesn't reflect in English terms what the code is doing. As others > > > 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 room > open to define lower bounds later on (either with <: as well or with :> a= s > 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 a= n > "instance of" anything. The ":" is more neutral in that > > regard maybe? > > > > > > On Thu, Apr 21, 2016 at 10:32 AM, Josh Di Fabio > 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 against > > >> 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, as it > > > doesn't reflect in English terms what the code is doing. As others > > > 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 against > > >> 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. Likewis= e > > >> if this feature becomes approved in generics, it would make sense 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 each > > >> 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 about > > >> callable types. > > >> > > >> ---------------- > > >> > > >> This RFC currently doesn't specify in detail how reflection would > > >> 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 som= e > > >> help on this one. > > >> > > >> ----------------- > > >> > > >> Aside from these top issues on our own list, however does everyone > > >> feel about the proposal in general? > > >> As the RFC is still in draft, we will continue to make changes to it > > >> as more popular idea pop up, so please continue. > > >> > > >> Thanks. > > >> > > >> PS: I wasn't properly subscribed to the mailing list, so I missed a > > >> few important messages that were mailed directly to internals, but > > >> hopefully I've managed to fix that now. > > > > -- > > PHP Internals - PHP Runtime Development Mailing List To unsubscribe, > visit: http://www.php.net/unsub.php > > > --=20 Guilherme Blanco Lead Architect at E-Block --001a114422be103d0605316c49ea--