The RFC is very consistent.
It proposes only a part of the desired type-hinting features, but this part
is not questionable for me.
+1
The implementation has some minor issues.
Levi, if you won't object, I would like to play with implementation a bit,
right before commit (if it accepted).
Dmitry
On 16 October 2014 08:44, Dmitry Stogov dmi...@zend.com wrote:
The RFC is very consistent.
It proposes only a part of the desired type-hinting features, but this part
is not questionable for me.
May I enquire what it misses out according to your ideal desired
feature set? Just so that
On Thu, Oct 16, 2014 at 6:39 AM, Levi Morrison levi_morri...@byu.edu
wrote:
Dear Internals,
I finally have a working implementation for return types RFC[1] built
on top of master. There are a few notes in the PR[2] about the
implementation. I invite you all to review the PR and provide
On 16 Oct 2014, at 05:39, Levi Morrison levi_morri...@byu.edu wrote:
- There is a new section about disallowing return types on certain
methods[4].
Perhaps, along the same lines, we could error if you use a nonsensical type
hint for magic methods?
For example, allow this:
class
On Fri, Jun 15, 2012 at 3:01 AM, Anthony Ferrara ircmax...@gmail.com
wrote:
Hello all,
I raised this topic on list over a year ago (
http://marc.info/?l=php-internalsm=130417646507744w=2 ). It was
determined that it wasn't time yet to disable prepared statement
emulation for MySQL yet.
Hi Chris,
I meant scalar type hinting, nullable type hinting, may be even mixed type
hinting...
But, lets go by small steps to get all this finally accepted.
Thanks. Dmitry.
On Thu, Oct 16, 2014 at 1:35 PM, Chris Wright c...@daverandom.com wrote:
Dmitry
On 16 October 2014 08:44, Dmitry
I think the patch already does it (may be not for all magic methods).
Thanks. Dmitry.
On Thu, Oct 16, 2014 at 2:58 PM, Andrea Faulds a...@ajf.me wrote:
On 16 Oct 2014, at 05:39, Levi Morrison levi_morri...@byu.edu wrote:
- There is a new section about disallowing return types on certain
On 10/16/2014 09:44 AM, Dmitry Stogov wrote:
The RFC is very consistent.
It proposes only a part of the desired type-hinting features, but this part
is not questionable for me.
+1
I second that emotion; +1.
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit:
I very much like this — though I would say it was dependent on the nullable
types RFC (like splat and variadics were codependent).
While I would like to see the introduction of a void type, I understand and
respect the limitations on the RFC.
However, one thing that I do think is missing, is the
On Thu, 16 Oct 2014 18:39:06 +0400, Davey Shafik da...@php.net wrote:
I very much like this — though I would say it was dependent on the
nullable
types RFC (like splat and variadics were codependent).
While I would like to see the introduction of a void type, I understand
and
respect the
Hi Levi,
This RFC is pretty consistent, small and focused on a specific part of the
overall previously desired support.
I do think many more subsequent RFCs would come up after this one to expand
return typehint support, but as it stands right now is extremely good. Any
further inclusion would
On 10/16/2014 04:27 AM, Ferenc Kovacs wrote:
On Fri, Jun 15, 2012 at 3:01 AM, Anthony Ferrara ircmax...@gmail.com
wrote:
Hello all,
I raised this topic on list over a year ago (
http://marc.info/?l=php-internalsm=130417646507744w=2 ). It was
determined that it wasn't time yet to disable
On Thu, Oct 16, 2014 at 5:47 PM, Rasmus Lerdorf ras...@lerdorf.com wrote:
On 10/16/2014 04:27 AM, Ferenc Kovacs wrote:
On Fri, Jun 15, 2012 at 3:01 AM, Anthony Ferrara ircmax...@gmail.com
wrote:
Hello all,
I raised this topic on list over a year ago (
Hello,
I think that Rowan is right: PHP users need to manipulate grapheme clusters
first (and code points in some rare situations). The fact that most of us
live in a world were NFC composes all our characters only hides this
reality.
A typical use case is a template engine: nearly all string
Le jeudi 16 octobre 2014 à 18:10 +0200, Ferenc Kovacs a écrit :
On Thu, Oct 16, 2014 at 5:47 PM, Rasmus Lerdorf ras...@lerdorf.com wrote:
On 10/16/2014 04:27 AM, Ferenc Kovacs wrote:
On Fri, Jun 15, 2012 at 3:01 AM, Anthony Ferrara ircmax...@gmail.com
wrote:
Hello all,
I
On 10/16/14, 8:47 AM, Rasmus Lerdorf wrote:
On 10/16/2014 04:27 AM, Ferenc Kovacs wrote:
On Fri, Jun 15, 2012 at 3:01 AM, Anthony Ferrara ircmax...@gmail.com
wrote:
Hello all,
I raised this topic on list over a year ago (
http://marc.info/?l=php-internalsm=130417646507744w=2 ). It was
On 16 October 2014 18:39:57 GMT+01:00, Olivier Bonvalet
php-dev.l...@daevel.net wrote:
Le jeudi 16 octobre 2014 à 18:10 +0200, Ferenc Kovacs a écrit :
On Thu, Oct 16, 2014 at 5:47 PM, Rasmus Lerdorf ras...@lerdorf.com
wrote:
On 10/16/2014 04:27 AM, Ferenc Kovacs wrote:
On Fri, Jun 15,
Hello!
The PHP development team announces the immediate availability of PHP
5.6.2.
Four security-related bugs were fixed in this release, including fixes for
CVE-2014-3668, CVE-2014-3669 and CVE-2014-3670.
All PHP 5.6 users are encouraged to upgrade to this version.
For source downloads of PHP
On 10/16/2014 02:38 PM, Morgan Tocker wrote:
The more clear cases would be:
- The prepared statement is reused enough times that the initial extra round
trip can be amortized.
- If large place-holder values can be sent direct to the server without
having to be escaped or parsed. For
Hello!
The PHP development team announces the immediate availability of PHP
5.4.34.
6 security-related bugs were fixed in this release, including fixes for
CVE-2014-3668,
CVE-2014-3669 and CVE-2014-3670.
Also, a fix for OpenSSL which produced regressions was reverted.
All PHP 5.4 users are
On 10/16/2014 09:10 AM, Ferenc Kovacs wrote:
I don't think we should remove the option, just change the defaults, and
most people would be fine switching back to the emulation, but it should
be their conscious decision imo.
Currently many people aren't aware that they are using client side
21 matches
Mail list logo
