Re: Union Class Types (was Union Type (singular) straw man proposal)
| From: | Mike Schinkel | 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