# [RFC][VOTE] In Operator - Thread: https://externals.io/message/84885 - Original archive: https://news-web.php.net/php.internals/84885 - Started by Niklas Keller on 2015-03-15T19:31:32+00:00 - Messages: 12 - Reply by email to internals@lists.php.net - More for agents: search with https://externals.io/search.md?q={query} · JSON API at https://externals.io/api · documentation at https://externals.io/llms.txt --- ## #84885 — Niklas Keller — 2015-03-15T19:31:32+00:00 URL: https://externals.io/message/84885#84885 Morning, I just opened the vote for the in operator, you can find the RFC here: https://wiki.php.net/rfc/in_operator Vote will be open for two weeks, counting from today. Regards, Niklas --- ## #84905 — Dan Ackroyd — 2015-03-15T20:36:01+00:00 URL: https://externals.io/message/84885#84905 · In reply to: #84885 Hi Niklas, To reiterate and explain my no vote: The RFC is still lacking one thing - any justification of why this deserves being a new piece of syntax, rather than just being a function implemented either internally, or even better in userland PHP. The equation is not just "will PHP be better with this" instead it's "will PHP so much better that it justifies the known cost of adding syntax to the language, as well as the unknown cost of blocking future use of the 'in' keyword". I'm sorry, but I just can't see that the value in adding this comes anywhere close to justifying it's addition. cheers Dan --- ## #84959 — Marco Pivetta — 2015-03-16T00:16:51+00:00 URL: https://externals.io/message/84885#84959 · In reply to: #84885 Hi Niklas, > Morning, > > I just opened the vote for the in operator, you can find the RFC here: > https://wiki.php.net/rfc/in_operator > Vote will be open for two weeks, counting from today. > > Regards, Niklas > I just wanted to clarify on my "no" vote, and the reason for it is that we have perfectly functional internal as well as userland implementations of array/Traversable search operations. Syntactic sugar won't really make things easier when adopting the language, and I don't like this sort of additional cognitive load either. In short, I stand firm on my "if you can implement it in userland, don't implement it in the language" idea. Marco Pivetta http://twitter.com/Ocramius http://ocramius.github.com/ --- ## #85000 — Lester Caine — 2015-03-16T08:04:24+00:00 URL: https://externals.io/message/84885#85000 · In reply to: #84959 > Syntactic sugar won't really make things easier when adopting the language, > and I don't like this sort of additional cognitive load either. > > In short, I stand firm on my "if you can implement it in userland, don't > implement it in the language" idea. Some of this Syntactic sugar would in the past have been developed in PEAR, but the support for 'userland' solutions via that path seems to have lost favour, with even the suggestion that PEAR should be dropped? Perhaps if PEAR contained examples of good practice in these areas it would help. I'd even perhaps go as far as suggesting that some of the more exotic developments in core would benefit from up to date demo's of their use in PEAR? -- Lester Caine - G8HFL ----------------------------- Contact - http://lsces.co.uk/wiki/?page=contact L.S.Caine Electronic Services - http://lsces.co.uk EnquirySolve - http://enquirysolve.com/ Model Engineers Digital Workshop - http://medw.co.uk Rainbow Digital Media - http://rainbowdigitalmedia.co.uk --- ## #85006 — Marco Pivetta — 2015-03-16T08:55:42+00:00 URL: https://externals.io/message/84885#85006 · In reply to: #85000 Hi Lester, > > > […] > language, > > […] > > Some of this Syntactic sugar would in the past have been developed in > PEAR, but the support for 'userland' solutions via that path seems to > have lost favour, with even the suggestion that PEAR should be dropped? > Perhaps if PEAR contained examples of good practice in these areas it > would help. I'd even perhaps go as far as suggesting that some of the > more exotic developments in core would benefit from up to date demo's of > their use in PEAR? > PEAR surely isn't where you'd look for new code nowadays: it's a legacy repository. Marco Pivetta http://twitter.com/Ocramius http://ocramius.github.com/ --- ## #85007 — Leigh — 2015-03-16T08:59:19+00:00 URL: https://externals.io/message/84885#85007 · In reply to: #85000 > > Some of this Syntactic sugar would in the past have been developed in > PEAR, but the support for 'userland' solutions via that path seems to > have lost favour, with even the suggestion that PEAR should be dropped? > Perhaps if PEAR contained examples of good practice in these areas it > would help. I'd even perhaps go as far as suggesting that some of the > more exotic developments in core would benefit from up to date demo's of > their use in PEAR? > And how do you propose the lexer/parser is extended in this manner? --- ## #85011 — Lester Caine — 2015-03-16T09:09:42+00:00 URL: https://externals.io/message/84885#85011 · In reply to: #85006 > PEAR surely isn't where you'd look for new code nowadays: it's a legacy > repository. Give me an alternative? I've had to update my own cope of PEAR so it's clean E_STRICT, but it is still essential to maintain legacy code bases which are not going anywhere soon. We NEED a modern replacement, but nothing is available? -- Lester Caine - G8HFL ----------------------------- Contact - http://lsces.co.uk/wiki/?page=contact L.S.Caine Electronic Services - http://lsces.co.uk EnquirySolve - http://enquirysolve.com/ Model Engineers Digital Workshop - http://medw.co.uk Rainbow Digital Media - http://rainbowdigitalmedia.co.uk --- ## #85012 — Nikita Nefedov — 2015-03-16T09:14:14+00:00 URL: https://externals.io/message/84885#85012 · In reply to: #85011 On Mon, 16 Mar 2015 12:09:42 +0300, Lester Caine wrote: > > > […] > > Give me an alternative? > I've had to update my own cope of PEAR so it's clean E_STRICT, but it is > still essential to maintain legacy code bases which are not going > anywhere soon. > We NEED a modern replacement, but nothing is available? > There are composer [1] and pickle [2]. Please refrain from your over-frequent comments in this mailing list before doing research on the subject, you tend to create an informational noise when you do this. [1] https://getcomposer.org [2] https://github.com/FriendsOfPHP/pickle --- ## #85013 — Lester Caine — 2015-03-16T09:16:16+00:00 URL: https://externals.io/message/84885#85013 · In reply to: #85007 > And how do you propose the lexer/parser is extended in this manner? 'Some of this Syntactic sugar' ... Things like the sort interface and other userland stuff and there are tidy ways to do 'in' with existing code. Most of the time mine has already been run in the database. But I would also include PECL in the supporting tools camp, where adding or upgrading internal code sits perfectly if the reliance on a single bundled package is relaxed. How many people ACTUALLY use the official bundle. -- Lester Caine - G8HFL ----------------------------- Contact - http://lsces.co.uk/wiki/?page=contact L.S.Caine Electronic Services - http://lsces.co.uk EnquirySolve - http://enquirysolve.com/ Model Engineers Digital Workshop - http://medw.co.uk Rainbow Digital Media - http://rainbowdigitalmedia.co.uk --- ## #85016 — Lester Caine — 2015-03-16T09:34:49+00:00 URL: https://externals.io/message/84885#85016 · In reply to: #85012 > There are composer [1] and pickle [2]. > > Please refrain from your over-frequent comments in this mailing list > before doing research on the subject, you tend to create an > informational noise when you do this. So it is now official PHP policy that we should be using third party facilities. Is FIG included in that? -- Lester Caine - G8HFL ----------------------------- Contact - http://lsces.co.uk/wiki/?page=contact L.S.Caine Electronic Services - http://lsces.co.uk EnquirySolve - http://enquirysolve.com/ Model Engineers Digital Workshop - http://medw.co.uk Rainbow Digital Media - http://rainbowdigitalmedia.co.uk --- ## #85524 — Pascal Martin — 2015-03-29T09:19:11+00:00 URL: https://externals.io/message/84885#85524 · In reply to: #84885 Le 15/03/2015 20:31, Niklas Keller a écrit : > I just opened the vote for the in operator Hi, Discussing this RFC with other people at AFUP, it seems the majority of us ended up on the +1 side. The idea of a unified syntax to find whether or not something is *in* something else seems to be interesting for many. On the other hand, some noted this new operator doesn't feel like "the PHP way" and cannot be used as a callback (as it's not a function). A few also suggested if this is accepted, maybe it could be extended for objects in the future; with new a specific method? In any case, thanks for your work on this! -- Pascal MARTIN, AFUP - French UG http://php-internals.afup.org/ --- ## #85552 — Niklas Keller — 2015-03-30T13:01:33+00:00 URL: https://externals.io/message/84885#85552 · In reply to: #85524 This RFC has been declined with 21 "Yes" votes and 26 "No" votes. Regards, Niklas 2015-03-29 11:19 GMT+02:00 Pascal Martin, AFUP : > Le 15/03/2015 20:31, Niklas Keller a écrit : > > > […] > Hi, > > Discussing this RFC with other people at AFUP, it seems the majority of us > ended up on the +1 side. > > The idea of a unified syntax to find whether or not something is *in* > something else seems to be interesting for many. > On the other hand, some noted this new operator doesn't feel like "the PHP > way" and cannot be used as a callback (as it's not a function). > > A few also suggested if this is accepted, maybe it could be extended for > objects in the future; with new a specific method? > > In any case, thanks for your work on this! > > -- > Pascal MARTIN, AFUP - French UG > http://php-internals.afup.org/