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
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
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
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
Hi Lester,
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
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
On Mon, 16 Mar 2015 12:09:42 +0300, Lester Caine lester@lsces.co.uk
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
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
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?
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
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/
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:
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/