Actually I'm just so happy to see that you guys reached this conclusion - I was preparing a big post with some statistics about how hard we must work to deliver something so controversial and that it will take a HUGE toll on everyone even not using the stuff - both from point of making a compliant tool will be HARD and that tool (eg PhpStorm or CI analyzer) will be eating everyone's resources to just plug the holes in design. Phew.
Let's allow only ONE type of operator - "|" or "&" and no braces. This will allow us to have working solutions most for real-world issues. I have another proposal in the queue - on taking care making entire syntax friendly to graceful degradation, but this requires some more work... Regards, Alex On Sat, Nov 10, 2018 at 12:14 AM Matthew Brown <matthewmatt...@gmail.com> wrote: > I agree - I don’t think we want to encourage types that expand into > monstrosities once the brackets have been evaluated out. Better to disallow > (...) & C. > > On Nov 9, 2018, at 1:15 PM, Chuck Burgess <demon.g...@gmail.com> wrote: > > Ah, I had assumed they were same precedence in PHP... it's obviously been > way too long since I've seen them in code. > > I agree with following PHP here, then, as Larry described... @return A & > C | B & C > CRB > *about.me/ashnazg <http://about.me/ashnazg>* > > > On Fri, Nov 9, 2018 at 12:10 PM Larry Garfield <la...@garfieldtech.com> > wrote: > >> Honestly, I'm skeptical that we want to develop a grammar for full >> algebraic >> type definitions in docs when the language doesn't support it. That >> risks >> encouraging some very bad practices, and if PHP itself ever adds native >> algebraic types it could get weird if there's any inconsistency (which >> there >> almost certainly will be). >> >> That said, if we must support it in the doc format then follow the same >> precedence order as PHP itself: & binds higher than |. Having a >> different set >> of parse rules than PHP itself is the way to madness. :-) >> >> --Larry Garfield >> >> On Thursday, November 8, 2018 12:52:18 PM CST Chuck Burgess wrote: >> > Previous replies indicate that whitespace around operators is perfectly >> > acceptable, so that seems resolved. >> > >> > What about the issue of operator precedence when "|" and "&" are both >> > needed? >> > >> > Do we want to say one is higher order than the other, resulting in the >> > possibility of one Type being listed multiple times: @return A & C >> | B >> > & C >> > >> > Or should they be equal precedence, needing parentheses to enforce >> order: >> > @return (A | B) & C >> > >> > CRB >> > >> > On Tuesday, October 23, 2018 at 8:09:19 AM UTC-5, Chuck Burgess wrote: >> > > Having both operators at different levels would mean that combinations >> > > such as `@param (A|B)&C $test` would have to be written as `@param >> A&C|B&C >> > > $test`. >> > > >> > > I'm not against allowing whitespace around the operators, if the >> > > implementors agree it's still easy enough to parse correctly. Since >> the >> > > variable name should come between the Types and the Description, >> perhaps >> > > that's not a big deal. >> > > >> > > CRB >> > > *about.me/ashnazg <http://about.me/ashnazg>* >> > > >> > > On Sun, Oct 21, 2018 at 9:40 AM <php-...@jantvrdik.com> wrote: >> > >> Regarding the ABNF grammar, there are few things that need to be >> decided. >> > >> >> > >> (1) Priority / interaction with union and array "operators". I would >> > >> strongly recommend disallowing union and intersection on the same >> "level" >> > >> and always require brackets to explicitly declare the intention. For >> > >> consistency with union types, array and intersection should be >> allowed on >> > >> the same level with array having higher priority. This matches >> behavior >> > >> used by PHPStan and can be achieved for example with the following >> > >> grammar >> > >> >> > >> type = atomic [union / intersection] >> > >> union = 1*("|" atomic) >> > >> intersection = 1*("&" atomic) >> > >> atomic = identifier [array] / "(" type ")" [array] >> > >> array = 1*("[]") >> > >> identifier = keyword / class-name >> > >> keyword = "array" / "bool" / ... >> > >> class-name = ["\"] label *("\" label) >> > >> label = label-head *label-tail >> > >> label-head = ALPHA / "_" / %x80-FF >> > >> label-tail = ALPHA / DIGIT / "_" / %x80-FF >> > >> >> > >> >> > >> (2) Allowing horizontal whitespaces around operators. With more >> complex >> > >> types it makes sense to allow horizontal whitespaces around >> operators. It >> > >> complicates the grammar a bit, but it makes complex types a lot >> readable. >> > >> It may be better the post allowing horizontal whitespaces as a >> standalone >> > >> PR independent of intersection types. >> > >> >> > >> Regards, >> > >> Jan Tvrdík >> > >> >> > >> >> > >> >> > >> ---------- Původní e-mail ---------- >> > >> >> > >> Od: Chuck Burgess <demon.g...@gmail.com> >> > >> >> > >> Komu: php-fig@googlegroups.com >> > >> >> > >> Datum: 21. 10. 2018 3:22:06 >> > >> >> > >> Předmět: Re: [PSR-5] Intersection Types >> > >> >> > >> Yes, parentheses would be required for controlling order of >> precedence. >> > >> >> > >> In your example, I would expect: >> > >> >> > >> >> > >> >> > >> >> > >> * @param (CacheInterface&ResetableInterface)|ResetableCacheInterface >> > >> $cache >> > >> >> > >> >> > >> CRB >> > >> >> > >> >> > >> >> > >> On Sat, Oct 20, 2018, 17:43 AzJezz <sgmat...@gmail.com> wrote: >> > >> >> > >> Hi, >> > >> >> > >> i find it quite confusing myself, here's a use case mixing `&` and >> `|`. >> > >> >> > >> >> > >> ```php >> > >> >> > >> <?php >> > >> >> > >> namespace App\Foo; >> > >> >> > >> class Bar { >> > >> >> > >> /** >> > >> * in this example `Bar` constructor accepts an object that >> implement >> > >> * ( `CacheInterface` and `ResetableInterface` ) or >> > >> >> > >> `ResetableCacheInterface` >> > >> >> > >> * >> > >> * should the doc block be formatted this way : >> > >> * >> > >> * @param >> > >> >> > >> object&CacheInterface&ResetableInterface|ResetableCacheInterface >> $cache >> > >> >> > >> * >> > >> * or maybe like this ? >> > >> * >> > >> * @param >> > >> >> > >> object&ResetableCacheInterface|ResetableInterface&CacheInterface >> $cache >> > >> >> > >> * >> > >> * or maybe we can use parentheses ? ¯\_(ツ)_/¯ >> > >> * >> > >> * @param object & ( ResetableCacheInterface | ( >> ResetableInterface & >> > >> >> > >> CacheInterface ) ) $cache >> > >> >> > >> */ >> > >> public function __construct($cache) { >> > >> >> > >> // initialize cache property >> > >> >> > >> } >> > >> >> > >> } >> > >> ``` >> > >> >> > >> >> > >> >> > >> >> > >> On Sat, Oct 20, 2018 at 11:53 AM Johannes Schmitt < >> schmitt...@gmail.com> >> > >> wrote: >> > >> >> > >> Hi there, >> > >> >> > >> generally, I think the addition of `&` is a great idea. >> > >> >> > >> >> > >> One thing regarding the grammar specifically, right now you would >> support >> > >> mixing `|` with `&` like `A|B&C`. I'm not sure if mixing would be >> > >> desirable >> > >> (I don't have use-case for this at this point). Also the grammar >> > >> currently >> > >> requires `|` to be before `&`- so something like `A&B|C` would not be >> > >> supported - I'm not sure if this is intentional? Maybe it's best to >> only >> > >> either support `|` or `&`, but not allow to mix them for the moment? >> > >> >> > >> >> > >> Thanks, >> > >> Johannes >> > >> >> > >> >> > >> On Fri, Oct 19, 2018 at 2:50 PM Chuck Burgess <demon.g...@gmail.com> >> > >> wrote: >> > >> >> > >> Hello everyone, >> > >> >> > >> There is a new PR [1] from a contributor, asking for an Intersection >> Type >> > >> Operator. This appears to simply use `&` akin to how `|` is used for >> > >> Union >> > >> Types. >> > >> >> > >> >> > >> Neither Unions nor Intersections are (yet) in the language itself, >> but >> > >> `string|null` Union Typing in Tags has been in wide usage for a while >> > >> now. >> > >> In looking over RFCs on attempts to get these two Type Operators >> into the >> > >> language, it seems likely to me that the Operators chosen will be >> `|` and >> > >> `&` if they do ever get in. As such, I'm personally good with the >> choice >> > >> of `&` for Intersection Operator for Typing in Tags. >> > >> >> > >> >> > >> Please keep discussion on this request on this ML thread. >> > >> >> > >> >> > >> Chuck Burgess, Editor >> > >> >> > >> >> > >> [1] -- https://github.com/php-fig/fig-standards/pull/1104 >> >> -- >> You received this message because you are subscribed to the Google Groups >> "PHP Framework Interoperability Group" group. >> To unsubscribe from this group and stop receiving emails from it, send an >> email to php-fig+unsubscr...@googlegroups.com. >> To post to this group, send email to php-fig@googlegroups.com. >> To view this discussion on the web visit >> https://groups.google.com/d/msgid/php-fig/12147766.9nEoe5WhWs%40vulcan. >> For more options, visit https://groups.google.com/d/optout. >> > -- > You received this message because you are subscribed to a topic in the > Google Groups "PHP Framework Interoperability Group" group. > To unsubscribe from this topic, visit > https://groups.google.com/d/topic/php-fig/W1VyAtoqGQ8/unsubscribe. > To unsubscribe from this group and all its topics, send an email to > php-fig+unsubscr...@googlegroups.com. > To post to this group, send email to php-fig@googlegroups.com. > To view this discussion on the web visit > https://groups.google.com/d/msgid/php-fig/CANsgjnu%3DSbwELXrZqakXXVFBQk57cgnSroKFfuBR4nk_HqSv7Q%40mail.gmail.com > <https://groups.google.com/d/msgid/php-fig/CANsgjnu%3DSbwELXrZqakXXVFBQk57cgnSroKFfuBR4nk_HqSv7Q%40mail.gmail.com?utm_medium=email&utm_source=footer> > . > For more options, visit https://groups.google.com/d/optout. > > -- > You received this message because you are subscribed to a topic in the > Google Groups "PHP Framework Interoperability Group" group. > To unsubscribe from this topic, visit > https://groups.google.com/d/topic/php-fig/W1VyAtoqGQ8/unsubscribe. > To unsubscribe from this group and all its topics, send an email to > php-fig+unsubscr...@googlegroups.com. > To post to this group, send email to php-fig@googlegroups.com. > To view this discussion on the web visit > https://groups.google.com/d/msgid/php-fig/355591B9-E1CC-4568-8FE7-BEEAC6CC557D%40gmail.com > <https://groups.google.com/d/msgid/php-fig/355591B9-E1CC-4568-8FE7-BEEAC6CC557D%40gmail.com?utm_medium=email&utm_source=footer> > . > For more options, visit https://groups.google.com/d/optout. > -- You received this message because you are subscribed to the Google Groups "PHP Framework Interoperability Group" group. To unsubscribe from this group and stop receiving emails from it, send an email to php-fig+unsubscr...@googlegroups.com. To post to this group, send email to php-fig@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/php-fig/CAAoBt4Xm%2ByEUe4qUF%2BQ7%2BZ84T0YsuNfO22vLoZ5HWA2-Knjdjw%40mail.gmail.com. For more options, visit https://groups.google.com/d/optout.
