Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:92852
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: error (pb1.pair.com: domain mindplay.dk from 209.85.218.66 cause and error)
MIME-Version: 1.0
In-Reply-To: <013101d19ff8$596b6010$0c422030$@tutteli.ch>
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>
	<CAFKaYMpWN+9uBqJ_p6-p14ZqYm0cm+q3LHkY3o9q7EvFCBS9Bg@mail.gmail.com>
	<CAFKaYMo5rtXeV+uE85yuQ_xOpREiKF-zVdQN6T-vDET8WhFvzg@mail.gmail.com>
	<CAKiSzdARnKM9=KwRhXJ1-2v44ueMAtBge+EywzDOT3+qkJ9xJg@mail.gmail.com>
	<CADqTB_jrfEBAesWTjDjzqTw5GnNQskgRfd_y8tOUyPF-e46ujA@mail.gmail.com>
	<013101d19ff8$596b6010$0c422030$@tutteli.ch>
Date: Wed, 27 Apr 2016 23:21:00 +0200
Message-ID: <CADqTB_jUV9Mxh7Hrw=N2ut2_RJC73Dviz8xSP=PmJR7Y+KE37A@mail.gmail.com>
To: Robert Stoll <php@tutteli.ch>
Cc: Josh Di Fabio <joshdifabio@gmail.com>, Dominic Grostate <codekestrel@googlemail.com>, 
	Guilherme Blanco <guilhermeblanco@gmail.com>, Mathieu Rochette <mathieu@texthtml.net>, 
	"Ben Scholzen 'DASPRiD'" <mail@dasprids.de>, Sara Golemon <pollita@php.net>, 
	PHP internals <internals@lists.php.net>, Mathieu Rochette <mathieu@rochette.cc>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
Subject: Re: [PHP-DEV] [RFC:generics]
From: rasmus@mindplay.dk (Rasmus Schultz)

> In this case I would suggest to use class A<T <: T1> which leaves room op=
en to define lower bounds later on

IMHO that is bordering on unreadable - all those brackets are really confus=
ing
and hard on the eyes.

Either way, using : does not prevent us from adding lower bounds later
on - but even
then, upper bound is the 99% use case, so I don't think it makes sense to d=
esign
the syntax around a possible future upper bound.

If we do support it in the future, I don't think anyone's going to
care what it looks like,
as it's unlikely most people will ever encounter it or need it.


On Tue, Apr 26, 2016 at 10:15 PM, Robert Stoll <php@tutteli.ch> 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<T : T1> { ... }
>
> In this case I would suggest to use class A<T <: T1> which leaves room op=
en 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 t=
he 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
>> > <codekestrel@googlemail.com> 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<T as Bar> {}
>> >> class Foo<T instanceof Bar> {}
>> >>
>> >> 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
>> > <codekestrel@googlemail.com> 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<T as Bar> {}
>> >> class Foo<T instanceof Bar> {}
>> >>
>> >> 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.  Likewise
>> >> 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<Foo, Bar> $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<string>".
>> >> However to ease the implementation it was decided that should be a se=
parate 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 classe=
s 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 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, vis=
it: http://www.php.net/unsub.php
>
>