Everything
php
Learn Community Releases The PHP Project
Home » Project » Newsgroups » php.internals » [RFC][VOTE] In Operator »

[RFC][VOTE] In Operator

php.internals

Niklas Keller

11 years ago
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

Dan Ackroyd

11 years ago
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

Marco Pivetta

11 years ago
Hi Niklas, On 15 March 2015 at 19:31, Niklas Keller <me@kelunik.com> wrote:
> 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/

Lester Caine

11 years ago
On 16/03/15 00:16, Marco Pivetta wrote:
> 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

Marco Pivetta

11 years ago
Hi Lester, On 16 March 2015 at 08:04, Lester Caine <lester@lsces.co.uk> wrote:
> On 16/03/15 00:16, Marco Pivetta wrote: > > 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? >
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/

Lester Caine

11 years ago
On 16/03/15 08:55, Marco Pivetta wrote:
> 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

Nikita

11 years ago
On Mon, 16 Mar 2015 12:09:42 +0300, Lester Caine <lester@lsces.co.uk> wrote:
> On 16/03/15 08:55, Marco Pivetta wrote: >> 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? >
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

Lester Caine

11 years ago
On 16/03/15 09:14, Nikita Nefedov wrote:
> 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

Leigh

11 years ago
On 16 March 2015 at 08:04, Lester Caine <lester@lsces.co.uk> wrote:
> > 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?

Lester Caine

11 years ago
On 16/03/15 08:59, Leigh wrote:
> 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

Pascal MARTIN

11 years ago
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/

Niklas Keller

11 years ago
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 <mailing@pascal-martin.fr>: