> > In this case I would suggest to use class A which leaves room
> > open to define lower bounds later on
>
> IMHO that is bordering on unreadable - all those brackets are really
> confusing and hard on the eyes.
>
I agree, it looks quite ugly :-)
Therefore another suggestion:
class A [Foo <
Yes this makes perfect sense now.
On 29 Apr 2016 6:44 p.m., "Mathieu Rochette" wrote:
>
>
> On 04/29/2016 06:02 PM, Rowan Collins wrote:
> > Hi Dominic,
> >
> > Sorry, I think this may have got sent too early by mistake; please
> > ignore the duplicate!
> >
> > Also, it's crossed in the post with
On 04/29/2016 06:02 PM, Rowan Collins wrote:
> Hi Dominic,
>
> Sorry, I think this may have got sent too early by mistake; please
> ignore the duplicate!
>
> Also, it's crossed in the post with your next message, but I'll send
> it anyway, in case it helps anyone understand.
>
>
> Dominic Grostat
Dominic Grostate wrote on 29/04/2016 17:45:
This means then that to use a subtype for the type argument, it is
safe for the function to READ the argument, but unsafe to WRITE to it.
Conversely. If the function accepted List, but was
theoretically given List, WRITING would be safe, but READI
This means then that to use a subtype for the type argument, it is safe for
the function to READ the argument, but unsafe to WRITE to it.
Conversely. If the function accepted List, but was theoretically
given List, WRITING would be safe, but READING wouldn't.
Given this, it doesn't matter how it
On Sat, Apr 30, 2016 at 12:26 AM, guilhermebla...@gmail.com <
guilhermebla...@gmail.com> wrote:
> 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 subtyp
Dominic Grostate wrote on 29/04/2016 16:59:
After reading your email again, I find myself agreeing. This is
because I don't consider List to be a subtype of List.
LinkedList would be a subtype of List, but inheritance
doesn't really extend any further beyond that, for the reason you have
i
Hi Dominic,
Sorry, I think this may have got sent too early by mistake; please
ignore the duplicate!
Also, it's crossed in the post with your next message, but I'll send it
anyway, in case it helps anyone understand.
Dominic Grostate wrote on 29/04/2016 16:45:
It's not insane, it's liskov
After reading your email again, I find myself agreeing. This is because I
don't consider List to be a subtype of List.
LinkedList would be a subtype of List, but inheritance
doesn't really extend any further beyond that, for the reason you have
illustrated.
The example you gave is similar to imp
Dominic Grostate wrote on 29/04/2016 16:45:
It's not insane, it's liskov substitution. But that is an insane
example, typical of Java to create a type that extends it's parent by
adding value constraints.. directly violating the principle.
Read the example again, and translate it into Englis
It's not insane, it's liskov substitution. But that is an insane example,
typical of Java to create a type that extends it's parent by adding value
constraints.. directly violating the principle.
On 29 Apr 2016 4:22 p.m., "Rowan Collins" wrote:
guilhermebla...@gmail.com wrote on 29/04/2016 15:26
guilhermebla...@gmail.com wrote on 29/04/2016 15:26:
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 type
>is compatible with A. So if B extends A, List is compatible with Listextends A>, and when reading items you can
gt;
>>> 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
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"
>> w
ert Stoll wrote:
>
> >
> >
> > > -Ursprüngliche Nachricht-
> > > Von: Rasmus Schultz [mailto:ras...@mindplay.dk]
> > > Gesendet: Montag, 25. April 2016 18:09
> > > An: Josh Di Fabio
> > > Cc: Dominic Grostate; Guilherme
athieu 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 re
>
>
> On Tue, Apr 26, 2016 at 4:15 PM, Robert Stoll wrote:
>>
>>
>>
>> > -Ursprüngliche Nachricht-
>> > Von: Rasmus Schultz [mailto:ras...@mindplay.dk]
>> > Gesendet: Montag, 25. April 2016 18:09
>> > An: Josh Di Fabio
>>
, 2016 at 4:15 PM, Robert Stoll wrote:
>
> >
> >
> > > -Ursprüngliche Nachricht-
> > > Von: Rasmus Schultz [mailto:ras...@mindplay.dk]
> > > Gesendet: Montag, 25. April 2016 18:09
> > > An: Josh Di Fabio
> > > Cc: Dominic Grostate
Von: Rasmus Schultz [mailto:ras...@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
> > B
, 2016 at 4:15 PM, Robert Stoll wrote:
>
>
> > -Ursprüngliche Nachricht-
> > Von: Rasmus Schultz [mailto:ras...@mindplay.dk]
> > Gesendet: Montag, 25. April 2016 18:09
> > An: Josh Di Fabio
> > Cc: Dominic Grostate; Guilherme Blanco; Mathieu Rochette; Ben
ieu
> 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'
> 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
On 4/21/16 10:43 AM, Rowan Collins wrote:
guilhermebla...@gmail.com wrote on 21/04/2016 16:25:
I understand others mentioned we could create a new interface that
wraps the other two interfaces, but that still doesn't solve the
problem where I want to extend a class AND also implement a specific
Hi all,
Am 20.04.2016 um 16:44 schrieb guilhermebla...@gmail.com:
> 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 Employ
Hi Rasmus
> Hello internals,
>
> I'd like to introduce an RFC proposing the addition of generic types and
> functions:
>
> https://wiki.php.net/rfc/generics
>
> Ben Scholzen started this RFC as a quick draft with a few code samples in
> August last year, and I have since then worked
> with
guilhermebla...@gmail.com wrote on 21/04/2016 16:25:
I understand others mentioned we could create a new interface that
wraps the other two interfaces, but that still doesn't solve the
problem where I want to extend a class AND also implement a specific
interface.
I covered this case in my pr
Nope, it pretty much made perfect sense to me the first time. But you may
get your wish in it going in with the proposal anyway as I don't think this
RFC is going to make it in time for the 7.1 window.
My crack at implementing it went bust when I realised I was adding too many
execute globals.
S
I see that some of you are confusing union types with intersecting types
here. The idea is not an OR, but an AND.
I'll repeat the same example again to try to exemplify what I mentioned:
class AA {}
interface B {}
interface C {}
class BB extends AA implements B {}
class CC extends AA implements B,
Jesse Schalken wrote on 21/04/2016 04:18:
Sticking with your example for a moment, if the type parameter is an
"int", then the only type that can /currently/ be expressed in the
type language that is a subtype of "int" is "int", so it's not very
useful /right now/. However, a possible introdu
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 t
On Thu, Apr 21, 2016 at 8:56 AM, Rowan Collins
wrote:
>
> I'm not quite sure what bounds would mean for anything other than classes
> or interfaces. A generic type that specified that its type parameter must
> be an int seems to me to be a non-generic type, because nothing other than
> an int "is
On 04/20/2016 09: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 f
On 20/04/2016 22:02, Jesse Schalken wrote:
"instanceof" implies to me that the right hand side is a class/interface
name, since that's what's expected with the "instanceof" operator, rather
than a type. If I can do "Foo>" I would expect to
be able to do "if ($t instanceof array) ...", but I can't
"instanceof" implies to me that the right hand side is a class/interface
name, since that's what's expected with the "instanceof" operator, rather
than a type. If I can do "Foo>" I would expect to
be able to do "if ($t instanceof array) ...", but I can't.
I think unless the "instanceof" operator i
On Wed, Apr 20, 2016 at 12:17 PM, Dominic Grostate
wrote:
> 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.
On Wed, Apr 20, 2016 at 1:17 PM, Dominic Grostate <
codekest...@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 {}
> cl
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"
Yes, if you have "class Box" and T is used for two
things, then "they must be of the same type, but they can be any same type
and that type must at least be Boxable". It means that Box can use a T as a
Boxable (call Boxable methods on it, etc).
On Thu, Apr 21, 2016 at 1:12 AM, Larry Garfield
wrot
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 fai
guilhermebla...@gmail.com wrote on 20/04/2016 15:44:
In a given class, I might want to only accept CacheDrivers that also
support BulkOperations. How would I achieve that?
Apologies if this has been refuted elsewhere, but AFAIK you can
implement any intersection constraint, albeit slightly mor
Larry Garfield wrote on 20/04/2016 16:12:
On 4/20/16 10:01 AM, Rowan Collins wrote:
guilhermebla...@gmail.com wrote on 20/04/2016 03:54:
1- Even though mentioned, I'd still use "extends" or "implements"
instead
of "is" (which would be a new pseudo-reserved keyword) to enforce
data type
consist
Sure, the usage of "instanceof" is an alternative to prevent declaring a
new keyword. PHP doesn't have the same problem as Java does to enforce the
first generic type information to be a class and others interfaces. So in
this:
class A {}
interface B {}
interface C {}
class Foo {}
Java required
On 4/20/16 10:01 AM, Rowan Collins wrote:
guilhermebla...@gmail.com wrote on 20/04/2016 03:54:
1- Even though mentioned, I'd still use "extends" or "implements"
instead
of "is" (which would be a new pseudo-reserved keyword) to enforce
data type
consistency and prevent developers to potentially
guilhermebla...@gmail.com wrote on 20/04/2016 03:54:
1- Even though mentioned, I'd still use "extends" or "implements" instead
of "is" (which would be a new pseudo-reserved keyword) to enforce data type
consistency and prevent developers to potentially referring to one thing
while consider anothe
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
On Wed, Apr 20, 2016 at 11: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 intersec
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 param
On 20/04/2016 00:22, Sara Golemon wrote:
On Tue, Apr 19, 2016 at 1:16 PM, Mathieu Rochette wrote:
about the upper bounds, have you consider another way of describing the
constraints, eg:
class Box where T is Boxable
this would allow multiple constraints, eg:
class Collection where T is Tra
I agree.
On Wed, Apr 20, 2016 at 2:01 PM, Sara Golemon wrote:
> On Tue, Apr 19, 2016 at 7:56 PM, Jesse Schalken
> wrote:
> >> class Collection {...
> >
> > I think the "where T is Traversable, T is Countable" syntax was intended
> to
> > represent the intersection (i.e. a "Countable Traversable
On Tue, Apr 19, 2016 at 7:56 PM, Jesse Schalken wrote:
>> class Collection {...
>
> I think the "where T is Traversable, T is Countable" syntax was intended to
> represent the intersection (i.e. a "Countable Traversable"), not the union.
>
> So you would need an intersection syntax
>
> class Colle
On Tue, Apr 19, 2016 at 7:54 PM, guilhermebla...@gmail.com
wrote:
> 1- Even though mentioned, I'd still use "extends" or "implements" instead of
> "is" (which would be a new pseudo-reserved keyword) to enforce data type
> consistency and prevent developers to potentially referring to one thing
> w
On Wed, Apr 20, 2016 at 8:22 AM, Sara Golemon wrote:
> On Tue, Apr 19, 2016 at 1:16 PM, Mathieu Rochette
> wrote:
> > about the upper bounds, have you consider another way of describing the
> > constraints, eg:
> >
> > class Box where T is Boxable
> >
> > this would allow multiple constraints, e
Hi,
Here are a couple of comments towards Generics support to PHP.
1- Even though mentioned, I'd still use "extends" or "implements" instead
of "is" (which would be a new pseudo-reserved keyword) to enforce data type
consistency and prevent developers to potentially referring to one thing
while c
On Tue, Apr 19, 2016 at 4:13 PM, Stanislav Malyshev wrote:
>> class Collection {...
>
> I am sorry if this sounds harsh, but I really hope we won't have
> something like this in PHP. Java templates are complex and weird enough,
> adding another layer on top of that to allow type expressions IMHO i
Hi!
> class Collection {...
I am sorry if this sounds harsh, but I really hope we won't have
something like this in PHP. Java templates are complex and weird enough,
adding another layer on top of that to allow type expressions IMHO is
really taking it too far.
--
Stas Malyshev
smalys...@gmail.
On Tue, Apr 19, 2016 at 1:16 PM, Mathieu Rochette wrote:
> about the upper bounds, have you consider another way of describing the
> constraints, eg:
>
> class Box where T is Boxable
>
> this would allow multiple constraints, eg:
>
> class Collection where T is Traversable, T is Countable
>
IMO, t
On 04/19/2016 06:28 PM, Dominic Grostate wrote:
> We would really like some feedback on this. We know it is a massive
> feature, but we have put in quite a lot of research in both the language
> implications and implementation challenges. Please ask any questions you
> have.
thank you all for yo
We would really like some feedback on this. We know it is a massive
feature, but we have put in quite a lot of research in both the language
implications and implementation challenges. Please ask any questions you
have.
Thanks.
On 18 Apr 2016 11:24 a.m., "Josh Di Fabio" wrote:
> On Mon, Apr 18,
On Mon, Apr 18, 2016 at 10:47 AM, Josh Di Fabio wrote:
> On Mon, Apr 18, 2016 at 6:20 AM, Rasmus Schultz wrote:
>> Hello internals,
>>
>> I'd like to introduce an RFC proposing the addition of generic types
>> and functions:
>>
>> https://wiki.php.net/rfc/generics
>>
>> Ben Scholzen started this
On Mon, Apr 18, 2016 at 6:20 AM, Rasmus Schultz wrote:
> Hello internals,
>
> I'd like to introduce an RFC proposing the addition of generic types
> and functions:
>
> https://wiki.php.net/rfc/generics
>
> Ben Scholzen started this RFC as a quick draft with a few code samples
> in August last year
Hello internals,
I'd like to introduce an RFC proposing the addition of generic types
and functions:
https://wiki.php.net/rfc/generics
Ben Scholzen started this RFC as a quick draft with a few code samples
in August last year, and I have since then worked with Dominic and
Ben towards a more comp
61 matches
Mail list logo
