Re: Union Class Types (was Union Type (singular) straw man proposal)

From: Date: Fri, 06 Sep 2019 05:32:55 +0000
Subject: Re: Union Class Types (was Union Type (singular) straw man proposal)
References: 1 2 3 4  Groups: php.internals 
Request: Send a blank email to internals+get-106887@lists.php.net to get a copy of this message
Hi Kalle, Thank you so much for your feedback. I am not sure of the list etiquette. Should I respond to all your points here and possibly generate a lot of emails, or ask that we move the comments to my Gist? -Mike > On Sep 6, 2019, at 1:20 AM, Kalle Sommer Nielsen <kalle@php.net> wrote: > > Hi > > Den fre. 6. sep. 2019 kl. 07.22 skrev Mike Schinkel <mike@newclarity.net>: >> Thank you very much for your feedback. You illustrated perfectly why I should not have >> produced that proposal in haste. >> >> Your confusion was due to my first draft errors, which thanks to your feedback I have >> hopefully had a chance to correct. I effectively rewrote and extended the proposal which you should >> be able to find at the same URL: >> >> >> https://gist.github.com/mikeschinkel/50aec7094f5643223d28674639f9f117 >> <https://gist.github.com/mikeschinkel/50aec7094f5643223d28674639f9f117> >> >> I would be greatly appreciative if you could give is a second look. >> >> >>> All in all I do not understand the benefits of this approach compared to Nikita’s >>> RFC. >> >> I have moved the benefits to the beginning of the document and expanded the list I >> elaborate on. >> >> Hopefully they will be clear now? >> >> >> -Mike Schinkel > > > I read both versions of this and it strikes me more as a partical > interface that is half baked by using keywords, that is not really in > line with how the rest of PHP is designed. This sounds more like > something that could be implemented on top of Nikita's RFC if it > passes in userland, but anyway, here goes with my comments to this: > > -- New magical methods that appear out of nowhere without an > interface, e.g. ::type(), ::value(), ::setValue(), ::toXZY(). if these > magical methods suddenly appear with may be varadic based on the value > of the types setting, this is inconsistent to the rest of PHP. > -- There is no mention of what happens if there is multiple > types in > a definition. > -- Why is the syntax using | as a separator where all other decls is > using a comma separated list? > -- Nitpick The "types" decl doesn't use an ending semicolon in any of > your examples > -- Nitpick: Your examples in the "Accepting params into a union > instance" section uses $this in a procedural function > -- In the "Named Union equivalence to anonymous union" section I fail > to see how Building2 can magically accept Building, this is based on > properties and there is there is no mention of the ability to have (or > not to have) multiple named unions as property types. > -- Is this designed to be only meant for mutability (You are > publically exposing setValue())? > -- What happens if the class is extended? > -- Why is it desired to implement a namespaced class instance return? > If you are working on the object, you should already have access to > this information it provides, no? > -- Why is ::types() apart of the union instead of leaving that to > reflection? No other part of PHP exposes such as a method over > procedural functions (like get_object_vars()). > > (Bear in mind I wrote this as the first in the morning) > > -- > regards, > > Kalle Sommer Nielsen > kalle@php.net

« previous php.internals (#106887) next »