ions) that have been posted since.
Please note this is *my* personal opinion, and doesn't necessarily
reflect the opinion of any organization I am affiliated with.
Pascal.
--
Pascal MARTIN
http://blog.pascal-martin.fr
@pascal_martin
--
PHP Internals - PHP Runtime Development Mailing List
To
or not his
code is OK. With warnings and/or notices, it will be more clear that
things are not just OK.
Thanks!
--
Pascal MARTIN
http://blog.pascal-martin.fr/
@pascal_martin
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
ers instead of floats?
If so and if using GMP would be a good/better idea, a note about that on
intdiv()'s manual page might prove useful for end-users?
--
Pascal MARTIN
http://blog.pascal-martin.fr/
@pascal_martin
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
rge right now and improve things later,
* While others would prefer to improve things now and merge only after.
In any case, we all agree there is still a lot to be done before
reaching PHP 7 ;-)
--
Pascal MARTIN
http://blog.pascal-martin.fr
@pascal_martin
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
nice
improvement.
It should help us getting some syntax options that were impossible
before, and there is not too much impact for developers and their
existing applications.
So, basically: +1
--
Pascal MARTIN
http://blog.pascal-martin.fr/
@pascal_martin
--
PHP Internals - PHP Ru
construct doesn't
make much sense -- and should cause a syntax error for PHP 7.
An E_DEPRECATED warning for PHP 5.7 is also nice for end-users, as it
will help anticipating the migration to PHP 7.
So, basically, +1
--
Pascal MARTIN
http://blog.pascal-martin.fr
@pascal_martin
--
PHP
it's about edge-cases for bitwise
shifts, which were already giving different results depending on the
platform, and odd casts) -- and PHP 7 (major version) feels like the
right time to fix this.
--
Pascal MARTIN
http://blog.pascal-martin.fr/
@pascal_martin
--
PHP Internals - PHP Ru
help too.
So, basically, +1 ;-)
--
Pascal MARTIN
http://blog.pascal-martin.fr/
@pascal_martin
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
these breaks should not be too hard and can, at
least in part, be automated.
--
Pascal MARTIN
http://blog.pascal-martin.fr/
@pascal_martin
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
:
either all, or nothing, but not half.
Most of us seem to go towards "disabling in all cases" (which indeed
means BC-break for those who were using this -- probably not that many),
but it seems like no-one will be sad if things end up going the other
way around.
--
Pascal M
; is trivial enough (like,
for instance, adding a simple new function or changing the default value
of a parameter), having to vote on the "implementation" could be a too
heavy process.
--
Pascal MARTIN
http://blog.pascal-martin.fr
@pascal_martin
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
time to drop them, if the underlying libraries aren't maintained anymore.
* +1 to remove ext/mssql and ext/sybase_ct
* and +0 for ext/pdo_dblib -- we didn't reach a consensus on that one.
Thanks
--
Pascal MARTIN, AFUP - French UG
http://php-internals.afup.org/
--
PHP Internal
Le 05/02/2015 09:49, Dmitry Stogov a écrit :
The RFC is turned into voting
https://wiki.php.net/rfc/php7_foreach#proposed_voting_choices
Hi,
After discussing this RFC with other people at AFUP, it seems we are the
+1 side, on both propositions.
Thanks
--
Pascal MARTIN, AFUP - French UG
much easier when it
comes to writing comparison functions.
(Even though the RFC has been withdrawn, I thought posting this could
help, if anyone wishes to keep working on it)
--
Pascal MARTIN, AFUP - French UG
http://php-internals.afup.org/
--
PHP Internals - PHP Runtime Development Mailing
wn pace and existing code will keep working, even if
calling "strict" libraries.
The biggest concern we've had is the declare() syntax that feels a bit
weird at first. But that's not enough of a concern for us to be -1 on
the RFC as a whole.
Thanks!
--
Pascal MART
it back to vote for a day. Will close it tomorrow.
Hi,
Thanks for reviving this!
--
Pascal MARTIN, AFUP - French UG
http://php-internals.afup.org/
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
some
parameters could be useful in some situations, this approach doesn't
"feel right" and we would really prefer something like named-parameters
(even if this RFC is not incompatible with named-parameters and they
most likely won't make it for PHP 7.0).
Thanks
--
Pascal MART
UP, we would be on the
-1 side.
Basically, even if this warning can sometimes be annoying (especially in
CLI), we think having a not properly configured timezone can be bad
enough to justify keeping the warning (maybe only as E_STRICT, if one
really wants to hide it in some cases).
Thanks,
--
syntactic sugar could be helpful.
In any case, those on the +1 side agree it should be with the trailing "\".
Sorry this is probably not that helpful, and thanks for your work!
--
Pascal MARTIN, AFUP - French UG
http://php-internals.afup.org/
--
PHP Internals - PHP Runtime Development Ma
e didn't really
answer the question that was asked.
Thanks for your work!
--
Pascal MARTIN, AFUP - French UG
http://php-internals.afup.org/
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
UP, and we would
be -1.
Our reasons are probably the same as expressed here by others: updating
the (more or less "internal") error-messages doesn't feel right.
And one can already use his own error handler to log what pieces of data
are needed.
Still, thanks for your work
synced with releases of PHP -- which, in the end, is not
that interesting for end-users, we think.
In any case, thanks for your work!
--
Pascal MARTIN, AFUP - French UG
http://php-internals.afup.org/
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net
.
We would have been farther from a consensus with the "remove from PHP 7"
idea -- but going in two steps, the first one being to mark those
old-type constructors as deprecated, feels much better.
Thanks for you work!
--
Pascal MARTIN, AFUP - French UG
http://php-internals.afup.org
t help, here.
As a sidenote, an idea that was suggested a few times was that adding
some kind of __toString() method on arrays could be useful in some cases
-- but this goes a lot farther than this RFC...
Thanks,
--
Pascal MARTIN, AFUP - French UG
http://php-internals.afup.org/
--
PHP Int
RFC with other people at
AFUP, it appears we would be +1 (by a large margin !).
Thanks for your work!
--
Pascal MARTIN, AFUP - French UG
http://php-internals.afup.org/
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Le 26/02/2015 15:58, Anthony Ferrara a écrit :
I have opened voting on Scalar Type Declarations v0.5. Please cast your vote.
Hi,
We were, at AFUP, +1 for the v0.3 of this RFC, and it seems we still are
on the +1 side for this v0.5
Thanks for having re-vived this!
--
Pascal MARTIN, AFUP
end-users), we are on the +1 side for the
idea.
Thanks for your work!
--
Pascal MARTIN, AFUP - French UG
http://php-internals.afup.org/
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
elves on this matter) are +1.
Basically, adding one information that doesn't count in the iterator and
acts as some kind of final value could be interesting.
Thanks for your work!
--
Pascal MARTIN, AFUP - French UG
http://php-internals.afup.org/
--
PHP Internals - PHP Runtime Developme
any case, thanks for your work!
--
Pascal MARTIN, AFUP - French UG
http://php-internals.afup.org/
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Le 13/03/2015 20:33, Philip Sturgeon a écrit :
https://wiki.php.net/rfc/anonymous_classes
Hi,
We've discussed this with other people at AFUP, and are on the +1 side.
Thanks for this!
--
Pascal MARTIN, AFUP - French UG
http://php-internals.afup.org/
--
PHP Internals - PHP Ru
hanks!
--
Pascal MARTIN, AFUP - French UG
http://php-internals.afup.org/
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
the changes couldn't be improved.
Hi,
We at AFUP are +1 on this.
Basically, more consistency is a good thing.
Thanks!
--
Pascal MARTIN, AFUP - French UG
http://php-internals.afup.org/
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
We didn't quite reach a consensus between notices and warnings, though
-- mostly because they would *maybe* have helped detect *possible
future* bugs.
--
Pascal MARTIN, AFUP - French UG
http://php-internals.afup.org/
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
use), but those of us who did are +1.
Thanks!
--
Pascal MARTIN, AFUP - French UG
http://php-internals.afup.org/
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
fic method?
In any case, thanks for your work on this!
--
Pascal MARTIN, AFUP - French UG
http://php-internals.afup.org/
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
the right time for this
-- and those bc-breaks should not be the hardest ones to fix.
Thanks!
--
Pascal MARTIN, AFUP - French UG
http://php-internals.afup.org/
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
t;reserve more types" RFC, this will cause a few BC-breaks
here and there, but they should not be too hard to fix; and it opens
doors for the future.
Thanks!
--
Pascal MARTIN, AFUP - French UG
http://php-internals.afup.org/
--
PHP Internals - PHP Runtime Development Mailing Li
+1 for PHP 7.1 ; and -1 for PHP
5.6 and 7.0.
Thanks!
--
Pascal MARTIN, AFUP - French UG
http://php-internals.afup.org/
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
oop...or
I'm guessing this is why you voted "no" on your own RFC?
--
Pascal MARTIN, AFUP - French UG
http://php-internals.afup.org/
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
emain close to the way
unserialize() now behaves.
--
Pascal MARTIN, AFUP - French UG
http://php-internals.afup.org/
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
nctions is not quite
(for now?) the PHP way.
Not a full +1 though, mainly because these functions only feel like
half-a-step towards stronger typing.
--
Pascal MARTIN, AFUP - French UG
http://php-internals.afup.org/
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit
-12-02) and ends
in 10 days’ time next Friday (2014-12-12).
Hi,
Opinions from the community might not be the most interesting ones for
this kind of RFC, but the few members of AFUP who took part in a (short)
discussion about it would be +1.
--
Pascal MARTIN, AFUP - French UG
http://php
g with other members of AFUP, we are on the +1 side.
--
Pascal MARTIN, AFUP - French UG
http://php-internals.afup.org/
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
.
Summarizing our thoughts :
* static classes should not be encouraged
* if the goal is to have a set of utility functions, they can be set
up in a namespace -- being able to autoload functions could prove
useful, though.
--
Pascal MARTIN, AFUP - French UG
http://php-internals.afup.org
ut, considering this RFC doesn't go all the way to "objects as keys"
(especially on the "using foreach doesn't get you the object back"
part), we ended up on the -1 side.
--
Pascal MARTIN, AFUP - French UG
http://php-internals.afup.org/
--
PHP Internals - PHP Ru
* There are not that many PHP contributors -- which means having PHP
5.7 and PHP 7 more or less in parallel might slow PHP 7 down (not only
for the initial release, but also for maintenance and evolutions later).
--
Pascal MARTIN, AFUP - French UG
http://php-internals.afup.org/
--
PHP Intern
ction deprecations are left as a group.
Hi,
After some discussions with other people of AFUP, we ended up with a +1
on all points : a new major version is the right time to remove those
deprecated features (else, they'll pretty much remain in PHP forever).
--
Pascal MARTIN, AFUP - French UG
d
re-decoding it could be useful (thinking about strict comparison,
typically), even if JSON only has one "number" type.
And adding a new flag doesn't have much negative impact (as long as it's
not enabled by default, especially for a minor version of PHP).
--
Pascal MART
it to nullable types and scalar hints could
be interesting too -- if the corresponding RFCs pass, of course.
--
Pascal MARTIN, AFUP - French UG
http://php-internals.afup.org/
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
hich means child classes will
need to be updated anyway.
--
Pascal MARTIN, AFUP - French UG
http://php-internals.afup.org/
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
s -- which means we would
be +1.
--
Pascal MARTIN, AFUP - French UG
http://php-internals.afup.org/
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
extension in all
distributions. And, in this case, it comes without too much BC-break.
--
Pascal MARTIN, AFUP - French UG
http://php-internals.afup.org/
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
type and could look
a bit too similar to "->".
In any case, thanks for your work on this!
--
Pascal MARTIN, AFUP - French UG
http://php-internals.afup.org/
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
the like without exposing them publicly, would be nice!
And a bit more consistency with properties and methods cannot hurt.
Thanks for your work on this!
--
Pascal MARTIN, AFUP - French UG
http://php-internals.afup.org/
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe
your work on this, and welcome back!
--
Pascal MARTIN, AFUP - French UG
http://php-internals.afup.org/
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Le 09/12/2015 19:51, Davey Shafik a écrit :
https://wiki.php.net/rfc/curl_http2_push#vote
Voting will end in 2 weeks, closing at 13:00 UTC on Wed 2015-12-23.
Hi,
At AFUP, we would be +1 on this RFC.
(there has been no -1 at all on our list ;-) )
Thanks for your work!
--
Pascal MARTIN, AFUP
don't want that.
- Also, after a while, we would prefer time being spent on 7.x instead
of used maintaining 5.x for years.
- And, in any case, some users will never upgrade, no matter how long
5.x is maintained... that's just how it is.
Thanks
--
Pascal MARTIN, AFUP - French UG
http
out having to modify the code by hand (actually, I'm quite
surprised it's not a feature I remember seeing in any IDE).
In any case, thanks for you work on this!
--
Pascal MARTIN, AFUP - French UG
http://php-internals.afup.org/
--
PHP Internals - PHP Runtime Development Mailing Li
not a big change, consistent with what's been done for preg.
Thanks!
--
Pascal MARTIN, AFUP - French UG
http://php-internals.afup.org/
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
functions, behavior that's kind of
expected by many, useful feature; and low risk of bc-break.
Thanks for your work on this!
--
Pascal MARTIN, AFUP - French UG
http://php-internals.afup.org/
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
+1 to deprecated mcrypt
for PHP 7.1 and to remove it for PHP 8.0
Removing for PHP 7.2 doesn't feel "right" (too soon? and minor versions
should not remove features if it can be avoided).
Thanks for your work on this!
--
Pascal MARTIN, AFUP - French UG
http://php-internals.afup.or
your work on this!
--
Pascal MARTIN, AFUP - French UG
http://php-internals.afup.org/
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
s for your work on this!
--
Pascal MARTIN, AFUP - French UG
http://php-internals.afup.org/
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
this!
--
Pascal MARTIN, AFUP - French UG
http://php-internals.afup.org/
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
might help detect some
invalid usages of octal notation.
Thanks for your work on this!
--
Pascal MARTIN, AFUP - French UG
http://php-internals.afup.org/
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
re +1 for nullable
types on parameters than on return values; no deal-breaker here either.
Anyway, happy to see votes are going well and nullables types are more
than likely coming for PHP 7.1!
Thanks for you work on this!
--
Pascal MARTIN, AFUP - French UG
http://php-internals.afup.org/
of fixing this for end-users, on a minor release?
In any case, thanks for your work on this!
--
Pascal MARTIN, AFUP - French UG
http://php-intern...@afup.org
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
nion cannot hurt, I hope)
In any case, thanks for your work on this!
--
Pascal MARTIN, AFUP - French UG
http://php-internals.afup.org/
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
impact on (especially) performance.
In any case, thanks for you work on this!
--
Pascal MARTIN, AFUP - French UG
http://php-internals.afup.org/
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
ot pass, but, in any case, thanks for your work on this!
There are more "yes" than "no", so maybe it will open a path towards
something, maybe a bit different, in another future version...
--
Pascal MARTIN, AFUP - French UG
http://php-internals.afup.org/
--
PHP Intern
Le 24/06/2016 à 20:05, Aaron Piotrowski a écrit :
Voting on the Iterable RFC has opened and will remain open until 7/2/16 at
11:59 GMT.
Hi,
At AFUP, we would be a huge +1 for this RFC: it answers a need many of
us have had in the past.
Thanks for your work on this!
--
Pascal MARTIN, AFUP
Thanks for your work on this!
--
Pascal MARTIN, AFUP - French UG
http://php-intern...@afup.org
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
we at AFUP
would be on the -1 side.
Basically, our main reasons: "it feels a bit too magical" and "the
escape function is set globally" (both points being partially linked).
In any case, thanks for your work on this!
--
Pascal MARTIN, AFUP - French UG
http://php-intern
work on this!
--
Pascal MARTIN, AFUP - French UG
http://php-internals.afup.org/
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
all agree having such a function provided by PHP will
be better than trying to implement it ourselves, the day it's actually
needed -- and it's a single function without much impact or bc-break
anywhere else.
So, we would be +1.
Thanks again for your work on this!
--
Pascal MART
ually, when it does cause some,
it'll - probably - mostly be by detecting problems/bugs).
Thanks for your work on this!
--
Pascal MARTIN, AFUP - French UG
http://php-internals.afup.org/
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
76 matches
Mail list logo
