Zeev,
Considering that there has not been any discussion of your final
proposal (since the last change), I think putting it to vote prior to
having the ability to test or discuss is extremely problematic.
Especially considering every time we tried to test the proposal or
discuss it before you
On Wed, 11 Mar 2015, Zeev Suraski wrote:
The vote on the Coercive Scalar Type Hints is now open for voting.
The latest version of the RFC includes changes discussed on internals@ last
week:
1. Accept string-bool and int-bool conversions (false-bool is not
supported)
2. Accept
Anthony,
While I only put in the final changes today, they're identical to what I
said was going to be done on the discussion thread a week+ ago, there was no
further feedback or discussion on these changes. The patch (minus these two
minor changes) has been available for over a week.
I think
Hi,
Derick Rethans der...@php.net writes:
On Wed, 11 Mar 2015, Zeev Suraski wrote:
The vote on the Coercive Scalar Type Hints is now open for voting.
The latest version of the RFC includes changes discussed on internals@ last
week:
1. Accept string-bool and int-bool conversions
All,
On Wed, Mar 11, 2015 at 11:52 AM, Dan Ackroyd dan...@basereality.com wrote:
Voting no due to:
i) Having conversion rules be difference in userland to internal functions.
You list 'Single Mode' as a benefit of this RFC, but it's only single
mode if you gloss over this difference. This
Johannes Ott wrote on 11/03/2015 16:46:
Am 11.03.2015 um 17:21 schrieb Rowan Collins:
My reasoning is that code that is ambiguous is hard to read. If $foo
can mean either a local variable called $foo or a property of the
current object called $foo, then you have to know which it is in order
to
-Original Message-
From: Dan Ackroyd [mailto:dan...@basereality.com]
Sent: Wednesday, March 11, 2015 5:53 PM
To: Zeev Suraski
Cc: PHP internals
Subject: Re: [PHP-DEV] [VOTE][RFC] Coercive Scalar Type Hints
Voting no due to:
i) Having conversion rules be difference in userland to
Zeev,
The vote on the Coercive Scalar Type Hints is now open for voting.
The latest version of the RFC includes changes discussed on internals@ last
week:
1. Accept string-bool and int-bool conversions (false-bool is not
supported)
2. Accept leading/trailing spaces in string-number
The vote on the Coercive Scalar Type Hints is now open for voting.
The latest version of the RFC includes changes discussed on internals@ last
week:
1. Accept string-bool and int-bool conversions (false-bool is not
supported)
2. Accept leading/trailing spaces in string-number conversions.
Johannes Ott wrote on 11/03/2015 13:36:
Am 11.03.2015 um 14:03 schrieb Rowan Collins:
Johannes Ott wrote on 10/03/2015 20:46:
okay indeed the dynamic properties are a problem I didn't think about on
my suggestion. Without the wish to hijack this thread for another
typesafety discussion, I must
-Original Message-
From: Derick Rethans [mailto:der...@php.net]
Sent: Wednesday, March 11, 2015 5:57 PM
To: Zeev Suraski
Cc: PHP internals
Subject: Re: [PHP-DEV] [VOTE][RFC] Coercive Scalar Type Hints
On Wed, 11 Mar 2015, Zeev Suraski wrote:
Aren't you supposed to leave it one
Zeev,
On Wed, Mar 11, 2015 at 4:50 PM, Zeev Suraski z...@zend.com wrote:
-Original Message-
From: Derick Rethans [mailto:der...@php.net]
Sent: Wednesday, March 11, 2015 10:37 PM
To: Zeev Suraski
Cc: Anthony Ferrara; internals@lists.php.net
Subject: RE: [PHP-DEV] RE: [VOTE][RFC]
-Original Message-
From: Zeev Suraski [mailto:z...@zend.com]
Sent: Wednesday, March 11, 2015 11:28 PM
To: 'Theodore Brown'
Cc: 'internals@lists.php.net'
Subject: RE: [VOTE][RFC] Coercive Scalar Type Hints
Yes, with strict STH you'd know that more things fail during static
analysis
Hi all,
after all, some people are not happy with the current proposals about scalar
types. So, they both still possibly may fail.
Thus, I'd like to come up with a fallback proposal in case both proposals fail:
https://wiki.php.net/rfc/basic_scalar_types
It shouldn't prevent any future
Am 11.03.2015 um 18:12 schrieb Rowan Collins:
Johannes Ott wrote on 11/03/2015 16:46:
Am 11.03.2015 um 17:21 schrieb Rowan Collins:
My reasoning is that code that is ambiguous is hard to read. If $foo
can mean either a local variable called $foo or a property of the
current object called
On Thu, Mar 12, 2015 at 12:28 AM, Bob Weinand bobw...@hotmail.com wrote:
Hi all,
after all, some people are not happy with the current proposals about
scalar types. So, they both still possibly may fail.
Thus, I'd like to come up with a fallback proposal in case both proposals
fail:
Am 11.03.2015 um 22:28 schrieb Bob Weinand:
Hi all,
after all, some people are not happy with the current proposals about scalar
types. So, they both still possibly may fail.
Thus, I'd like to come up with a fallback proposal in case both proposals
fail:
Am 11.03.2015 um 15:05 schrieb Niklas Keller:
You have to input internals@lists.php.net, that changed some time ago.
I've just updated https://wiki.php.net/rfc/howto
See
https://github.com/php/web-wiki/commit/583d2c1b39a8b88960ab94e56ba4a4608ddb2353
Regards, Niklas
Thanks that helped.
2015-03-11 6:27 GMT-03:00 Lester Caine les...@lsces.co.uk:
On 11/03/15 09:05, wp12173047-156224 wp12173047-156224 wrote:
BTW, the current PHP silent behavior should be considered even more
confusing otherwise we
wouldn't have these measurements:
Hi,
Unsafe max_execution_time and Out of Memory handling is a huge problem,
that often lead to crashes and SHM corruption.
The PoC solves the first problem.
https://github.com/php/php-src/pull/1173
Instead of throwing zend_error() from signal handler, now we just set
EG(vm_interrupt) and
On Wed, 11 Mar 2015, Zeev Suraski wrote:
From: Anthony Ferrara [mailto:ircmax...@gmail.com]
function bar(float $x)
$foo = 1;
bar($foo); // will definitely fail in strict mode
No, actually it won't fail in strict mode:
-Original Message-
From: Derick Rethans [mailto:der...@php.net]
Sent: Wednesday, March 11, 2015 10:37 PM
To: Zeev Suraski
Cc: Anthony Ferrara; internals@lists.php.net
Subject: RE: [PHP-DEV] RE: [VOTE][RFC] Coercive Scalar Type Hints
You're right, sorry. Reverse it then:
On Wednesday, March 11 2015 at 1:14 pm Zeev Suraski wrote:
I don't believe strict STH would bring any meaningful gains for static
analysis, no. Unlike the JIT/AOT advantages (on the same code) which I
believe I've proven cannot be gained, I can't prove this one - because you
can infer
The proposed coercion rules aren't clear. The first table in the RFC
implies
that string is accepted for bool hints, and the second table says this
is
unchanged. But the examples section states that foo - bool will raise
an
E_DEPRECATED error. I'm guessing this is a mistake, since you
-Original Message-
From: Theodore Brown [mailto:theodor...@outlook.com]
Sent: Wednesday, March 11, 2015 11:01 PM
To: Zeev Suraski
Cc: internals@lists.php.net
Subject: RE: [VOTE][RFC] Coercive Scalar Type Hints
On Wednesday, March 11 2015 at 1:14 pm Zeev Suraski wrote:
I don't
-Original Message-
From: Dan Ackroyd [mailto:dan...@basereality.com]
Sent: Wednesday, March 11, 2015 8:04 PM
To: Zeev Suraski
Cc: PHP internals
Subject: Re: [PHP-DEV] [VOTE][RFC] Coercive Scalar Type Hints
On 11 March 2015 at 16:45, Zeev Suraski z...@zend.com wrote:
I think that
It was actually Anthony who proposed that I do that. He also proposed that
if they both pass, we'll have a vote to choose between them.
For a lot of people, the dual mode and coercive STH RFCs aren't a zero sum
game. They just want ONE of them to pass to have some sort of scalar type
hinting,
Hi,
You are making a very huge mistake, IMHO. By having 2 conflicting RFC,
you are taking the risk they both fail. And it won't do any good to the
language.
While you could have either proposed yours after the STH one if it
would have failed, or create a new RFC to make the STH one evolve
if it
On 11 March 2015 at 16:45, Zeev Suraski z...@zend.com wrote:
I think that going through a transition period ... that ultimately results
in one, consistent language behavior
This RFC is explicitly saying that there is stuff that will be need to
be changed in the future. Why would anyone upgrade
Zeev,
You also stated above that false-bool is not supported (I'm guessing
you
meant float-bool). So users would be able to pass 4.3 to a bool
typehint,
but not 4.3? This behavior seems very arbitrary and confusing.
It may be confusing, but only academically so. Again, this approach tries
Hi,
2015-03-11 11:49 GMT-03:00 Nikita Popov nikita@gmail.com:
On Mon, Mar 9, 2015 at 6:47 AM, Marcio Almada marcio.w...@gmail.com
wrote:
Hi,
Just passing by to announce I already have a working version of the new
patch: https://github.com/php/php-src/pull/1158
The patch is 100%
On Mar 12, 2015 2:10 AM, Zeev Suraski z...@zend.com wrote:
The vote on the Coercive Scalar Type Hints is now open for voting.
The latest version of the RFC includes changes discussed on internals@
last
week:
1. Accept string-bool and int-bool conversions (false-bool is not
supported)
On 11 March 2015 at 18:46, Eli e...@eliw.com wrote:
Benoit ... actually Anthony's original proposal specifically was
designed to be live at the same time as this alternative proposal. And
it's even mentioned in the proposal (stating that it would stay open
until the 13th or when the
Benoit ... actually Anthony's original proposal specifically was
designed to be live at the same time as this alternative proposal. And
it's even mentioned in the proposal (stating that it would stay open
until the 13th or when the alternative proposal voting ended - whichever
was later)
So this
-Original Message-
From: Anthony Ferrara [mailto:ircmax...@gmail.com]
Sent: Wednesday, March 11, 2015 8:28 PM
To: Zeev Suraski
Cc: Theodore Brown; internals@lists.php.net
Subject: Re: [PHP-DEV] RE: [VOTE][RFC] Coercive Scalar Type Hints
Zeev,
You also stated above that
On Wed, Mar 11, 2015 at 5:49 PM, Nikita Popov nikita@gmail.com wrote:
On Mon, Mar 9, 2015 at 6:47 AM, Marcio Almada marcio.w...@gmail.com
wrote:
Hi,
Just passing by to announce I already have a working version of the new
patch: https://github.com/php/php-src/pull/1158
The patch
Hi!
Instead of throwing zend_error() from signal handler, now we just set
EG(vm_interrupt) and EG(timed_out) flags. PHP VM checks EG(vm_interrupt)
flag on each JMPx instruction (potential loop iteration) and then throws
That looks very nice but makes timeouts much less powerful. I think
On Mar 12, 2015 8:30 AM, Bob Weinand bobw...@hotmail.com wrote:
Hi all,
after all, some people are not happy with the current proposals about
scalar types. So, they both still possibly may fail.
Thus, I'd like to come up with a fallback proposal in case both proposals
fail:
On Thu, Mar 12, 2015 at 1:23 AM, Stanislav Malyshev smalys...@gmail.com
wrote:
Hi!
Instead of throwing zend_error() from signal handler, now we just set
EG(vm_interrupt) and EG(timed_out) flags. PHP VM checks EG(vm_interrupt)
flag on each JMPx instruction (potential loop iteration) and
Am 11.03.2015 um 23:29 schrieb Pavel Kouřil pajou...@gmail.com:
It shouldn't prevent any future improvements and still give use all the
advantages of scalar types.
Besides what I think of proposing yet another RFC, -1 because it is
basically what the initial idea from the opponents of
On Thu, Mar 12, 2015 at 1:46 AM, Stanislav Malyshev smalys...@gmail.com
wrote:
Hi!
I think, after max_execution_time is exceeded, we may start another
hard_timeout, and in case the EG(vm_interrupt) wasn't handled
safely, kill the process.
I remember such proposal floating on the list
On 11/03/2015 23:21, Johannes Ott wrote:
So now I want to do my first own proposal for a new function in PHP and
I hope doing it right with starting a discussion here first.
The purpose of this suggestion is to introduce a static constructor,
which is called before the first call to class
Hi
2015-03-11 6:50 GMT-03:00 Patrick ALLAERT patrickalla...@php.net:
Le mar. 10 mars 2015 à 21:04, Marcio Almada marcio.w...@gmail.com a
écrit :
2015-03-10 12:31 GMT-03:00 Patrick ALLAERT patrickalla...@php.net:
Hello,
Le lun. 2 mars 2015 à 00:03, Marcio Almada marcio.w...@gmail.com a
It shouldn't prevent any future improvements and still give use all the
advantages of scalar types.
Besides what I think of proposing yet another RFC, -1 because it is
basically what the initial idea from the opponents of optional strict mode
wanted before they go with the latest one. It
Am 12.03.2015 um 00:30 schrieb Marco Pivetta:
Hey Johannes,
Why can't this be done at autoloading time?
In my opinion this should not be done on autoloading time, but as a own
method inside the class for two reasons.
1. Not every class is loaded with autoload-functions, but although
directly
On 11 March 2015 at 14:28, Bob Weinand bobw...@hotmail.com wrote:
after all, some people are not happy with the current proposals about scalar
types. So, they both still possibly may fail.
Thus, I'd like to come up with a fallback proposal in case both proposals
fail:
On Wednesday, March 11, 2015, Bob Weinand bobw...@hotmail.com wrote:
Am 11.03.2015 um 23:29 schrieb Pavel Kouřil pajou...@gmail.com:
It shouldn't prevent any future improvements and still give use all the
advantages of scalar types.
Besides what I think of proposing yet another RFC, -1
Dmitry,
I tend to disagree with many people wanting this over nothing. It's a big
enough topic,
that raised waives in the community, to be treated properly and not just
throw it in before
feature freeze, so I agree with Nikita on this one.
My view on it is that if both RFC's fail, the feature
On 12 March 2015 at 00:21, Johannes Ott m...@deroetzi.de wrote:
The purpose of this suggestion is to introduce a static constructor,
which is called before the first call to class either static or
non-static to initialize some static properties which are needed by the
class.
Hey Johannes,
Hi Rowan,
On Wed, Mar 11, 2015 at 9:32 PM, Rowan Collins rowan.coll...@gmail.com
wrote:
Lester Caine wrote on 10/03/2015 21:12:
On 10/03/15 20:44, Yasuo Ohgaki wrote:
YES there is room to create a more consistent procedural interface, but
my original question still applies consistent with
So now I want to do my first own proposal for a new function in PHP and
I hope doing it right with starting a discussion here first.
The purpose of this suggestion is to introduce a static constructor,
which is called before the first call to class either static or
non-static to initialize some
On 10/03/2015 03:10, Yasuo Ohgaki wrote:
Hi Mike,
On Mon, Mar 9, 2015 at 9:45 PM, Michael Wallner m...@php.net wrote:
Hi, I’d like to start vote on RFC:continue_ob — any objections?
https://wiki.php.net/rfc/continue_ob https://wiki.php.net/rfc/continue_ob
+1
I don't mind at all even if
Hi all!
On 11 03 2015, at 08:26, Matteo Beccati p...@beccati.com wrote:
On 10/03/2015 03:10, Yasuo Ohgaki wrote:
Hi Mike,
On Mon, Mar 9, 2015 at 9:45 PM, Michael Wallner m...@php.net wrote:
Hi, I’d like to start vote on RFC:continue_ob — any objections?
Hi
2015-03-11 1:49 GMT-03:00 Stanislav Malyshev smalys...@gmail.com:
Hi!
related to the proposed RFC. *But* after some heuristics it was
noticeable that most warnings had a common cause. I parsed the output
It doesn't matter if it has common cause or not. If I have a system of
Le lun. 9 mars 2015 à 13:45, Michael Wallner m...@php.net a écrit :
Hi, I’d like to start vote on RFC:continue_ob — any objections?
https://wiki.php.net/rfc/continue_ob https://wiki.php.net/rfc/continue_ob
Regards,
Mike
No objections.
It didn't really require an RFC IMO, but it doesn't
Isn’t this already implemented in the SPL library?
http://php.net/manual/en/spl.datastructures.php
--
Met vriendelijke groet,
Camilo Sperberg
Sent with Airmail
On 11 Mar 2015 at 10:15:11, Ludovic Urbain (m...@ludovicurbain.com) wrote:
Hello,
I've been working with PHP for a while and
Hi Phil.
I really like this feature and am keen to see it go in. Developers
often create classes (which are typically new files) just to extend and
implement a small method. This feature could see codebases become much
lighter. So a massive thanks for your and Joe’s efforts on this.
I have
On 11/03/15 09:05, wp12173047-156224 wp12173047-156224 wrote:
BTW, the current PHP silent behavior should be considered even more
confusing otherwise we
wouldn't have these measurements:
https://wiki.php.net/rfc/strict_argcount#bc_breaks_on_the_real_world
I'm not sure how these
That's a good question, I never tried the SPL library.
But if we're to stick to whatever information is readily available, it's
not good enough, as Spl seems to be 15-30% faster when I'm looking for 10x
faster - however I'm looking at a really specific portion of performance
which would probably
Le mar. 10 mars 2015 à 19:29, Marcio Almada marcio.w...@gmail.com a
écrit :
Hi,
2015-03-10 11:39 GMT-03:00 Patrick ALLAERT patrickalla...@php.net:
Hello,
Le ven. 6 mars 2015 à 00:44, Marcio Almada marcio.w...@gmail.com a
écrit :
You are right about this. I'll setup a yes/no vote + a
Hello,
I've been working with PHP for a while and it's always sad to see array()'s
performance being so terrible, in so many cases where a simple list would
have done the trick without any slowdown.
So why don't we add a basic list type to PHP ? There's nothing to lose,
everything to gain, and
Hi Stas,
Stanislav Malyshev smalys...@gmail.com hat am 11. März 2015 um 05:49
geschrieben:
Hi!
related to the proposed RFC. *But* after some heuristics it was
noticeable that most warnings had a common cause. I parsed the output
It doesn't matter if it has common cause or not. If
Johannes Ott wrote on 10/03/2015 20:46:
okay indeed the dynamic properties are a problem I didn't think about on
my suggestion. Without the wish to hijack this thread for another
typesafety discussion, I must say again that PHP needs a less dynamic
and more declaratively properties concept in my
On Wed, Mar 11, 2015 at 12:09 PM, Patrick ALLAERT patrickalla...@php.net
wrote:
Le lun. 9 mars 2015 à 13:45, Michael Wallner m...@php.net a écrit :
Hi, I’d like to start vote on RFC:continue_ob — any objections?
https://wiki.php.net/rfc/continue_ob
https://wiki.php.net/rfc/continue_ob
Johannes Ott wrote:
BTW:
I'm trying to register a wiki account. But somehow it does not work.
When posting the formular the page is reloading, but nothing else
happens. No success or no error message is shown.
Maybe I'm doing something wrong?!
Maybe you have not filled out the fourth
Lester Caine wrote on 10/03/2015 21:12:
On 10/03/15 20:44, Yasuo Ohgaki wrote:
YES there is room to create a more consistent procedural interface, but
my original question still applies consistent with what rules?
It's possible choice.
I agree that names without _ looks more consistent.
On 11/03/15 12:32, Rowan Collins wrote:
Lester Caine wrote on 10/03/2015 21:12:
On 10/03/15 20:44, Yasuo Ohgaki wrote:
YES there is room to create a more consistent procedural interface,
but
my original question still applies consistent with what rules?
It's possible choice.
I agree that
Hi!
Instead of throwing zend_error() from signal handler, now we just set
EG(vm_interrupt) and EG(timed_out) flags. PHP VM checks EG(vm_interrupt)
flag on each JMPx instruction (potential loop iteration) and then throws
JMPs are not the only operations that can transfer control and thus
Am 11.03.2015 um 23:23 schrieb Pierre Joye pierre@gmail.com:
On Mar 12, 2015 8:30 AM, Bob Weinand bobw...@hotmail.com
mailto:bobw...@hotmail.com wrote:
Hi all,
after all, some people are not happy with the current proposals about
scalar types. So, they both still possibly may
Hi!
I think, after max_execution_time is exceeded, we may start another
hard_timeout, and in case the EG(vm_interrupt) wasn't handled
safely, kill the process.
I remember such proposal floating on the list recently, with two-stage
timeouts. But wouldn't killing the process run the same risk
On Wed, Mar 11, 2015 at 10:28 PM, Bob Weinand bobw...@hotmail.com wrote:
Hi all,
after all, some people are not happy with the current proposals about
scalar types. So, they both still possibly may fail.
Thus, I'd like to come up with a fallback proposal in case both proposals
fail:
On Thu, Mar 12, 2015 at 1:53 AM, Nikita Popov nikita@gmail.com wrote:
On Wed, Mar 11, 2015 at 10:28 PM, Bob Weinand bobw...@hotmail.com wrote:
Hi all,
after all, some people are not happy with the current proposals about
scalar types. So, they both still possibly may fail.
Thus,
On Wed, Mar 11, 2015 at 6:10 PM, Rowan Collins rowan.coll...@gmail.com wrote:
On 11/03/2015 23:21, Johannes Ott wrote:
So now I want to do my first own proposal for a new function in PHP and
I hope doing it right with starting a discussion here first.
The purpose of this suggestion is to
On Mon, Mar 9, 2015 at 6:47 AM, Marcio Almada marcio.w...@gmail.com wrote:
Hi,
Just passing by to announce I already have a working version of the new
patch: https://github.com/php/php-src/pull/1158
The patch is 100% compatible with the proposed one with the advantages:
- Has no
Am 11.03.2015 um 14:25 schrieb Christoph Becker:
Johannes Ott wrote:
BTW:
I'm trying to register a wiki account. But somehow it does not work.
When posting the formular the page is reloading, but nothing else
happens. No success or no error message is shown.
Maybe I'm doing something
On 3/11/2015 8:08 PM, Lester Caine wrote:
Personally I just want to keep the current name set and so the sheer
volume of changes proposed is a big kick in the face to me.
YES!
The time to make such a change to the names is about 1998 or maybe 2000.
Every person who learns the current names
On Mar 11, 2015 7:01 PM, Stas Malyshev smalys...@gmail.com wrote:
Hi!
Instead of throwing zend_error() from signal handler, now we just set
EG(vm_interrupt) and EG(timed_out) flags. PHP VM checks EG(vm_interrupt)
flag on each JMPx instruction (potential loop iteration) and then throws
On 11/03/15 22:44, Yasuo Ohgaki wrote:
Having namespace for internals would bring much flexibility for API changes,
both
OO and procedural API. I may try my best to have consensus.
I think you also like to have OO style API for basic
variables(int/float/array) as I am.
Unless we have
78 matches
Mail list logo
