RE: [PHP-DEV] Vote process change proposal
On Mar 18, 2015 4:01 PM, Zeev Suraski z...@zend.com wrote: -Original Message- From: Florian Anderiasch [mailto:m...@anderiasch.de] Sent: Wednesday, March 18, 2015 10:48 AM To: Stanislav Malyshev; Stelian Mocanita Cc: PHP Internals List Subject: Re: [PHP-DEV] Vote process change proposal TL;DR: I'd prefer no one actively trying to lobby anyone else to vote in their favor, but prodding people with a neutral hey, check out this I'd prefer people to express their opinions and try to convince others freely, without any allegation that doing so is somehow bad and should be prohibited. If somebody feels that he/she can not objectively vote and is easily swayed by lobbying, they could recuse themselves from voting, there's no problem with that and it is easy to do. OTOH, if they think their friends do not have informed opinions and are easily swayed by lobbying, they can refrain from calling such friends to vote. But I don't see why they should prohibit normal discussion behavior for others. I thought I said that, so yes, agreed :) Of course I don't want to limit proper discussions. I agree too, except I'm not sure there's agreement on what constitutes 'improper discussion'. Just as with the Voting RFC, I highly recommend we don't discuss that right now so close to the very heated debate/RFC we've just had. We should wait a while (weeks if not months), digest, and then discuss it - outside the context of a specific proposal. Not to mention we need to focus on getting PHP 7 actually out the door right now. Fully agreed. Let get back or continue to code. Zeev -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
RE: [PHP-DEV] Vote process change proposal
-Original Message- From: Florian Anderiasch [mailto:m...@anderiasch.de] Sent: Wednesday, March 18, 2015 10:48 AM To: Stanislav Malyshev; Stelian Mocanita Cc: PHP Internals List Subject: Re: [PHP-DEV] Vote process change proposal TL;DR: I'd prefer no one actively trying to lobby anyone else to vote in their favor, but prodding people with a neutral hey, check out this I'd prefer people to express their opinions and try to convince others freely, without any allegation that doing so is somehow bad and should be prohibited. If somebody feels that he/she can not objectively vote and is easily swayed by lobbying, they could recuse themselves from voting, there's no problem with that and it is easy to do. OTOH, if they think their friends do not have informed opinions and are easily swayed by lobbying, they can refrain from calling such friends to vote. But I don't see why they should prohibit normal discussion behavior for others. I thought I said that, so yes, agreed :) Of course I don't want to limit proper discussions. I agree too, except I'm not sure there's agreement on what constitutes 'improper discussion'. Just as with the Voting RFC, I highly recommend we don't discuss that right now so close to the very heated debate/RFC we've just had. We should wait a while (weeks if not months), digest, and then discuss it - outside the context of a specific proposal. Not to mention we need to focus on getting PHP 7 actually out the door right now. Zeev -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [RFC][Accepted] Scalar Type Declarations V0.5
On Mon, Mar 16, 2015 at 10:03 PM, Anthony Ferrara ircmax...@gmail.com wrote:
All,
Voting has been closed on the scalar type declarations v0.5 RFC:
https://wiki.php.net/rfc/scalar_type_hints_v5
At a final score of 108:48, it has been accepted for PHP 7.
Thank you.
Anthony
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Hello,
how will these examples work btw?
// a.php
?php
declare(strict_types=1);
function foo($fn) {
$fn(1);
};
// b.php
?php
require 'a.php';
foo(function (int $a) { return $a * 2; });
// c.php
?php
function foo($fn) {
$fn(1);
};
// d.php
?php
declare(strict_types=1);
require 'c.php';
foo(function (int $a) { return $a * 2; });
I can't find this in the RFC. I'd intuitively expect error in the
first example and the second one to work OK.
But at the same time, if there will be an error in the first example,
it is IMHO a huge flaw with this RFC. :/
Regards
Pavel Kouril
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [RFC][Accepted] Scalar Type Declarations V0.5
On Wed, Mar 18, 2015 at 11:01 AM, Pierre Joye pierre@gmail.com wrote:
On Mar 18, 2015 4:56 PM, Pavel Kouřil pajou...@gmail.com wrote:
On Mon, Mar 16, 2015 at 10:03 PM, Anthony Ferrara ircmax...@gmail.com
wrote:
All,
Voting has been closed on the scalar type declarations v0.5 RFC:
https://wiki.php.net/rfc/scalar_type_hints_v5
At a final score of 108:48, it has been accepted for PHP 7.
Thank you.
Anthony
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Hello,
how will these examples work btw?
// a.php
?php
declare(strict_types=1);
function foo($fn) {
$fn(1);
};
// b.php
?php
require 'a.php';
foo(function (int $a) { return $a * 2; });
// c.php
?php
function foo($fn) {
$fn(1);
};
// d.php
?php
declare(strict_types=1);
require 'c.php';
foo(function (int $a) { return $a * 2; });
I can't find this in the RFC. I'd intuitively expect error in the
first example and the second one to work OK.
But at the same time, if there will be an error in the first example,
it is IMHO a huge flaw with this RFC. :/
Git clone, compile, try, report.
It sounds pretty straight forward to me instead of asking the same questions
(in various form but it ends to the same answer).
And the patch should be applied sooner rather than later. So we can fix bugs
if there are actual ones in the current implementation.
Hello,
if I had time to set up the compilation of PHP on Windows, I'd do it -
but I don't. I wanted to try it myself via http://3v4l.org/, but it
unfortunately doesn't support multiple files.
Regards
Pavel Kouril
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [RFC][Accepted] Scalar Type Declarations V0.5
Hi,
Le 18 mars 2015 11:06, Pavel Kouřil pajou...@gmail.com a écrit :
On Wed, Mar 18, 2015 at 11:01 AM, Pierre Joye pierre@gmail.com
wrote:
On Mar 18, 2015 4:56 PM, Pavel Kouřil pajou...@gmail.com wrote:
On Mon, Mar 16, 2015 at 10:03 PM, Anthony Ferrara ircmax...@gmail.com
wrote:
All,
Voting has been closed on the scalar type declarations v0.5 RFC:
https://wiki.php.net/rfc/scalar_type_hints_v5
At a final score of 108:48, it has been accepted for PHP 7.
Thank you.
Anthony
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Hello,
how will these examples work btw?
// a.php
?php
declare(strict_types=1);
function foo($fn) {
$fn(1);
};
// b.php
?php
require 'a.php';
foo(function (int $a) { return $a * 2; });
// c.php
?php
function foo($fn) {
$fn(1);
};
// d.php
?php
declare(strict_types=1);
require 'c.php';
foo(function (int $a) { return $a * 2; });
I can't find this in the RFC. I'd intuitively expect error in the
first example and the second one to work OK.
But at the same time, if there will be an error in the first example,
it is IMHO a huge flaw with this RFC. :/
Git clone, compile, try, report.
It sounds pretty straight forward to me instead of asking the same
questions
(in various form but it ends to the same answer).
And the patch should be applied sooner rather than later. So we can fix
bugs
if there are actual ones in the current implementation.
Hello,
if I had time to set up the compilation of PHP on Windows, I'd do it -
but I don't. I wanted to try it myself via http://3v4l.org/, but it
unfortunately doesn't support multiple files.
You can emulate multiple files support by using eval().
Regards
Pavel Kouril
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Cheers,
Florian Margaine
Re: [PHP-DEV] [RFC][Accepted] Scalar Type Declarations V0.5
On Mar 18, 2015 4:56 PM, Pavel Kouřil pajou...@gmail.com wrote:
On Mon, Mar 16, 2015 at 10:03 PM, Anthony Ferrara ircmax...@gmail.com
wrote:
All,
Voting has been closed on the scalar type declarations v0.5 RFC:
https://wiki.php.net/rfc/scalar_type_hints_v5
At a final score of 108:48, it has been accepted for PHP 7.
Thank you.
Anthony
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Hello,
how will these examples work btw?
// a.php
?php
declare(strict_types=1);
function foo($fn) {
$fn(1);
};
// b.php
?php
require 'a.php';
foo(function (int $a) { return $a * 2; });
// c.php
?php
function foo($fn) {
$fn(1);
};
// d.php
?php
declare(strict_types=1);
require 'c.php';
foo(function (int $a) { return $a * 2; });
I can't find this in the RFC. I'd intuitively expect error in the
first example and the second one to work OK.
But at the same time, if there will be an error in the first example,
it is IMHO a huge flaw with this RFC. :/
Git clone, compile, try, report.
It sounds pretty straight forward to me instead of asking the same
questions (in various form but it ends to the same answer).
And the patch should be applied sooner rather than later. So we can fix
bugs if there are actual ones in the current implementation.
Re: [PHP-DEV] [RFC][Accepted] Scalar Type Declarations V0.5
Le mer. 18 mars 2015 à 10:56, Pavel Kouřil pajou...@gmail.com a écrit :
Hello,
how will these examples work btw?
// a.php
?php
declare(strict_types=1);
function foo($fn) {
$fn(1);
};
// b.php
?php
require 'a.php';
foo(function (int $a) { return $a * 2; });
// c.php
?php
function foo($fn) {
$fn(1);
};
// d.php
?php
declare(strict_types=1);
require 'c.php';
foo(function (int $a) { return $a * 2; });
I can't find this in the RFC. I'd intuitively expect error in the
first example and the second one to work OK.
Your intuition is correct.
But at the same time, if there will be an error in the first example,
it is IMHO a huge flaw with this RFC. :/
Flaw vs. design choice. This is one of the reason that this aspect, amongst
others, has been very debated.
Re: [PHP-DEV] [RFC][Accepted] Scalar Type Declarations V0.5
On 17/03/15 23:53, André Rømcke wrote: To help towards that end, can someone who understands what is wanted from the weak type hint mode actually produce a summary of that as it is very difficult to extract just what has now been agreed for that area of type hinting. A base that can be used to review some of the other discussions to put that to bed. Others might appreciate a similar summary of the 'type_error' mode as well? As a base for the documentation on the user manual updates? Not sure what is difficult to extract https://wiki.php.net/rfc/scalar_type_hints_v5#behaviour_of_weak_type_checks It's all right there... And there is nothing else in a substantial RFC that relates to weak mode? That part answers what has been agreed (or rather accepted), but not who the weak mode is for, and why. Tried to sum that up last week when there was still discussions on this: http://share.ez.no/blogs/core-development-team/php-7-sth-from-user-perspective TL;DR; weak mode is for api consumers, aka normal php users, while strict is for the actual target users of this features: api (library/framework) creators. Post also argues for why Zeev's adjustments to weak sth handling should still be done, as well as arguing for disallowing/fixing closure hint in strict mode. That is the sort of thing that will help nail down the edge cases in weak mode André ... since the bulk of the RFC spends so much time explaining why 'strict mode' is so much better? Yasuo has pointed out details which are as pointed out perfectly correct, but it is still worth documenting that this is what does happen, and therefore what needs fixing. What I am still having trouble with is just how one reworks phpeclipse and other IDE's so that they know that if the open file AND another file have declare(strict_types = 1); then the rules change. Anybody had a look at that yet for PDT? It's all very well putting it into the core and saying you don't have to use it, but all of the infrastructure now needs to know what to do :( -- 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 -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] Re: Bug #69127 session_regenerate_id(true) randomly generates a warning and loses session data
Hi all, On Sun, Mar 1, 2015 at 1:53 PM, Yasuo Ohgaki yohg...@ohgaki.net wrote: https://bugs.php.net/bug.php?id=69127 This bug is known fatal bug for session module. I proposed lazy_destroy to fix this before, but it declined. I think the name was wrong. With the proposal, session module destories session data with lazy manner, but it's actually precise manner. i.e. Session module and browser is _not_ synced, so destroy must be done async manner (~= lazy manner. For example, delete session data 60 seconds later). The reason why session_regenerate_id(true) fails is it deletes session data immediately even if session and browser is not in sync. Session and browser cannot sync because there is no means in HTTP/Cookie. Is there any other better idea for this? I would like to fix this bug transparently. i.e. User cannot detect already destroyed session that is accessible. The method is: 1. Add __SESSION_TTL__, which has TTL timestamp, to $_SESSION hash before serialization. 2. If session module finds __SESSION_TTL__ in unserialized data and TTL is past, then regenerate session ID and create new session with empty data. (Old session data is deleted actually) 3. If session is accessible by step 2, store TTL to PS(ttl) and initialize $_SESSION without __SESSION_TTL__. 4. If PS(ttl) has value greater than 0, add PS(ttl) back to session data before serialization. Note: Serialization/unserialization is done in session module. User cannot know the existence. I don't think users are using __SESSION_TTL__ key for $_SESSION, but it is possible. If there is invalid __SESSION_TTL__ in $_SESSION, raise E_NOTICE and remove the key from $_SESSION. BC happens only when __SESSION_TTL__ is used by users. I would like to fix this in released versions, but it requires addition to session module globals. Fix will be only available to PHP7. However, PS(ttl) can be added to the end of PS(). If this is OK, I'll fix this bug from PHP 5.4. Comments are appreciated. Regards, -- Yasuo Ohgaki yohg...@ohgaki.net
Re: [PHP-DEV] RE: [PHP-CVS] com php-src: Enable GCC global register variables if available: Zend/Zend.m4 Zend/zend_execute.c
Hi Dmitry,
I compiled it with gcc 4.7.2 and the bench.php performed well. Where did
you find the errors?
Albert
On Wed, Mar 18, 2015 at 12:22 AM, Dmitry Stogov dmi...@zend.com wrote:
Please also tell your GCC version.
We had problems with 4.6.3 and 4.7.0, so we disabled global variables for
GCC prior 4.8.0.
Thanks. Dmitry.
On Wed, Mar 18, 2015 at 12:36 AM, Dmitry Stogov dmi...@zend.com wrote:
Hi Caio,
Could you please run make test with and without the patch and compare
the failed tests.
The patch must not add new failures.
Thanks. Dmitry.
On Tue, Mar 17, 2015 at 10:15 PM, Caio Souza Oliveira
caio.olive...@eldorado.org.br wrote:
Hello guys!
I’ve included the optimization proposed in [1] on ppc64le machines and I
could get an outstanding performance improvement of about 69% when running
bench.php (from 2.394 sec to 1.640 sec in average). I’ve tested this on
POWER 8 machines. My patch can be seen at [2]
Thank you!
Caio Souza Oliveira
[1]
https://github.com/php/php-src/commit/fb4b7069842491eb66272587422a1f61d41eb869
[2] https://github.com/php/php-src/pull/1181
--
From: Albert Casademont Filella [mailto:albertcasadem...@gmail.com]
Sent: terça-feira, 17 de março de 2015 13:23
To: Gustavo Frederico Temple Pedrosa
Cc: Dmitry Stogov; Ard Biesheuvel; PHP Internals; Leonardo Bianconi;
Caio Souza Oliveira
Subject: Re: [PHP-DEV] RE: [PHP-CVS] com php-src: Enable GCC global
register variables if available: Zend/Zend.m4 Zend/zend_execute.c
Hi Dmitry,
I can confirm a ~10-11% reduction in execution time of the bench.php
from last month build (x64) to today's commit (from 1.154 sec to 1.010).
Amazing job!
Albert
On Tue, Mar 17, 2015 at 1:39 PM, Gustavo Frederico Temple Pedrosa
gustavo.pedr...@eldorado.org.br wrote:
Hi, Dmitry.
Thank you for contacting us.
Leonardo and Caio (in CC), they will verify.
Thank you very much. Temple.
From: Dmitry Stogov [mailto:dmi...@zend.com]
Sent: terça-feira, 17 de março de 2015 08:01
To: Ard Biesheuvel; Gustavo Frederico Temple Pedrosa
Cc: PHP Internals
Subject: Fwd: [PHP-CVS] com php-src: Enable GCC global register
variables if available: Zend/Zend.m4 Zend/zend_execute.c
Hi,
Please consider possibility of using the same optimization for ARM, PPC
and may be other platforms.
On x86(_84) it makes 2-7% speedup.
Only the similar changes in zend_execute.c and Zend.m4 are required to
enable it.
Thanks. Dmitry.
-- Forwarded message --
From: Dmitry Stogov dmi...@php.net
Date: Tue, Mar 17, 2015 at 1:51 PM
Subject: [PHP-CVS] com php-src: Enable GCC global register variables if
available: Zend/Zend.m4 Zend/zend_execute.c
To: php-...@lists.php.net
Commit:fb4b7069842491eb66272587422a1f61d41eb869
Author:Dmitry Stogov dmi...@zend.com Tue, 17 Mar 2015
13:51:02 +0300
Parents: 92bf4566ea65042b8f84cae7840298ed151a4f7a
Branches: master
Link:
http://git.php.net/?p=php-src.git;a=commitdiff;h=fb4b7069842491eb66272587422a1f61d41eb869
Log:
Enable GCC global register variables if available
Changed paths:
M Zend/Zend.m4
M Zend/zend_execute.c
Diff:
diff --git a/Zend/Zend.m4 b/Zend/Zend.m4
index 16f2d5f..e12b00d 100644
--- a/Zend/Zend.m4
+++ b/Zend/Zend.m4
@@ -409,3 +409,48 @@ else
AC_MSG_RESULT(no)
fi
fi
+
+AC_ARG_ENABLE(gcc-global-regs,
+[ --disable-gcc-global-regs
+ whether to enable GCC global register
variables],[
+ ZEND_GCC_GLOBAL_REGS=$enableval
+],[
+ ZEND_GCC_GLOBAL_REGS=yes
+])
+AC_MSG_CHECKING(for global register variables support)
+if test $ZEND_GCC_GLOBAL_REGS != no; then
+ AC_TRY_COMPILE([
+ ],[
+#if defined(__GNUC__) defined(i386)
+# define ZEND_VM_FP_GLOBAL_REG %esi
+# define ZEND_VM_IP_GLOBAL_REG %edi
+#elif defined(__GNUC__) defined(__x86_64__)
+# define ZEND_VM_FP_GLOBAL_REG %r14
+# define ZEND_VM_IP_GLOBAL_REG %r15
+#else
+# error global register variables are not supported
+#endif
+typedef int (*opcode_handler_t)(void);
+register void *FP __asm__(ZEND_VM_FP_GLOBAL_REG);
+register const opcode_handler_t *IP __asm__(ZEND_VM_IP_GLOBAL_REG);
+int emu(const opcode_handler_t *ip, void *fp) {
+ const opcode_handler_t *orig_ip = IP;
+ void *orig_fp = FP;
+ IP = ip;
+ FP = fp;
+ while ((*ip)());
+ FP = orig_fp;
+ IP = orig_ip;
+}
+ ], [
+ZEND_GCC_GLOBAL_REGS=yes
+ ], [
+ZEND_GCC_GLOBAL_REGS=no
+ ])
+fi
+if test $ZEND_GCC_GLOBAL_REGS = yes; then
+ AC_DEFINE([HAVE_GCC_GLOBAL_REGS], 1, [Define if the target system has
support for global register variables])
+else
+ HAVE_GCC_GLOBAL_REGS=no
+fi
+AC_MSG_RESULT(ZEND_GCC_GLOBAL_REGS)
diff --git a/Zend/zend_execute.c b/Zend/zend_execute.c
index b24218a..17e68dc 100644
--- a/Zend/zend_execute.c
+++ b/Zend/zend_execute.c
@@ -2049,7 +2049,7 @@ static zend_always_inline void
zend_vm_stack_extend_call_frame(zend_execute_data
}
/* }}} */
-#if
RE: [PHP-DEV] [RFC][Accepted] Scalar Type Declarations V0.5
-Original Message- From: yohg...@gmail.com [mailto:yohg...@gmail.com] On Behalf Of Yasuo Ohgaki Sent: Wednesday, March 18, 2015 6:44 AM To: Pierre Joye Cc: PHP internals; Leigh; André Rømcke; Lester Caine Subject: Re: [PHP-DEV] [RFC][Accepted] Scalar Type Declarations V0.5 Hi Pierre, On Wed, Mar 18, 2015 at 1:35 PM, Pierre Joye pierre@gmail.com wrote: On Mar 18, 2015 11:26 AM, Yasuo Ohgaki yohg...@ohgaki.net wrote: I didn't have my time to spent for the patch. So I don't verify this by myself, but it seems common sense for this RFC. So you voted against it without knowing how it actually works or aims to work? I suggest you to do it now then, before going further with this discussion :) I know we are better to play with patch before vote. I played with Zeev's patch and I was sure it's better ;) How many of voters spend enough time for both patches before vote? Apparently very few. In terms of people who actually reported their findings or explicitly said they played with it here on internals, perhaps a handful. FWIW, as someone who did play with the patch (both patches, of course), I'm not sure why people are claiming you don't understand the RFC. Your comments in the code are 100% accurate, which means you understood exactly how it works. Zeev -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
RE: [PHP-DEV] [RFC][Accepted] Scalar Type Declarations V0.5
FWIW, as someone who did play with the patch (both patches, of course), I'm not sure why people are claiming you don't understand the RFC. Your comments in the code are 100% accurate, which means you understood exactly how it works. Josh Di Fabio just pointed out to me that the code in question wasn't actually written by you but by Dennis Birkholz, so my statement was incorrect. Still, from what you said it appears to me you still understood the behavior but disagreed with it. I know that at least on my end, that was definitely the case. Zeev -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] strict_types should be renamed raise_type_error. WAS: About declare(strict_types = 1)
On Mar 18, 2015 6:42 PM, Patrick ALLAERT patrickalla...@php.net wrote: Le lun. 16 mars 2015 à 21:34, Matthew Leverton lever...@gmail.com a écrit : (Although the irony of using =1 instead of =true isn't lost on me!) Yes, I mentioned[1] that funny aspect earlier. 0 or 1 is explicitly required in order to update the boolean behind it while true/false generates a fatal error with strict_types declaration must have 0 or 1 as its value. [1] https://twitter.com/patrick_allaert/status/568167144363560961 Ok. You do not like this RFC, we get it. Now, what's about actually being constructive and if you find bug (and please under the context of this RFC and how it works) please report a bug so it can be fixed.
Re: [PHP-DEV] [RFC][Accepted] Scalar Type Declarations V0.5
On Wednesday, March 18, 2015, Patrick ALLAERT patrickalla...@php.net
wrote:
Le mer. 18 mars 2015 à 10:56, Pavel Kouřil pajou...@gmail.com a écrit :
Hello,
how will these examples work btw?
// a.php
?php
declare(strict_types=1);
function foo($fn) {
$fn(1);
};
// b.php
?php
require 'a.php';
foo(function (int $a) { return $a * 2; });
// c.php
?php
function foo($fn) {
$fn(1);
};
// d.php
?php
declare(strict_types=1);
require 'c.php';
foo(function (int $a) { return $a * 2; });
I can't find this in the RFC. I'd intuitively expect error in the
first example and the second one to work OK.
Your intuition is correct.
But at the same time, if there will be an error in the first example,
it is IMHO a huge flaw with this RFC. :/
Flaw vs. design choice. This is one of the reason that this aspect,
amongst others, has been very debated.
But if it works this way, the strict mode isn't optional and users of a
library NEED to care which mode the library uses?
Re: [PHP-DEV] strict_types should be renamed raise_type_error. WAS: About declare(strict_types = 1)
Le lun. 16 mars 2015 à 21:34, Matthew Leverton lever...@gmail.com a écrit : (Although the irony of using =1 instead of =true isn't lost on me!) Yes, I mentioned[1] that funny aspect earlier. 0 or 1 is explicitly required in order to update the boolean behind it while true/false generates a fatal error with strict_types declaration must have 0 or 1 as its value. [1] https://twitter.com/patrick_allaert/status/568167144363560961
Re: [PHP-DEV] [RFC][Accepted] Scalar Type Declarations V0.5
On Wed, Mar 18, 2015 at 1:47 PM, Anatol Belski anatol@belski.net wrote:
Pavel,
On Wed, March 18, 2015 11:05, Pavel Kouřil wrote:
On Wed, Mar 18, 2015 at 11:01 AM, Pierre Joye pierre@gmail.com
wrote:
On Mar 18, 2015 4:56 PM, Pavel Kouřil pajou...@gmail.com wrote:
On Mon, Mar 16, 2015 at 10:03 PM, Anthony Ferrara
ircmax...@gmail.com
wrote:
All,
Voting has been closed on the scalar type declarations v0.5 RFC:
https://wiki.php.net/rfc/scalar_type_hints_v5
At a final score of 108:48, it has been accepted for PHP 7.
Thank you.
Anthony
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Hello,
how will these examples work btw?
// a.php
?php
declare(strict_types=1); function foo($fn) { $fn(1);
};
// b.php
?php
require 'a.php'; foo(function (int $a) { return $a * 2; });
// c.php
?php
function foo($fn) { $fn(1);
};
// d.php
?php
declare(strict_types=1); require 'c.php'; foo(function (int $a) { return
$a * 2; });
I can't find this in the RFC. I'd intuitively expect error in the
first example and the second one to work OK.
But at the same time, if there will be an error in the first example,
it is IMHO a huge flaw with this RFC. :/
Git clone, compile, try, report.
It sounds pretty straight forward to me instead of asking the same
questions (in various form but it ends to the same answer).
And the patch should be applied sooner rather than later. So we can fix
bugs if there are actual ones in the current implementation.
Hello,
if I had time to set up the compilation of PHP on Windows, I'd do it - but
I don't. I wanted to try it myself via http://3v4l.org/, but it
unfortunately doesn't support multiple files.
for anyone needing to test on Windows, there was builds for an older RFC
version
http://windows.php.net/downloads/snaps/ostc/scalar_type_hints_2_strict_mode/
but I just made quick builds for the current as well
http://windows.php.net/downloads/snaps/ostc/scalar_type_hints_v5/
So you've got the choice.
Cheers
Anatol
Hello,
thanks a lot, I'll play with it this evening. :)
Regards
Pavel Kouril
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [RFC][Accepted] Scalar Type Declarations V0.5
Pavel,
On Wed, March 18, 2015 11:05, Pavel Kouřil wrote:
On Wed, Mar 18, 2015 at 11:01 AM, Pierre Joye pierre@gmail.com
wrote:
On Mar 18, 2015 4:56 PM, Pavel Kouřil pajou...@gmail.com wrote:
On Mon, Mar 16, 2015 at 10:03 PM, Anthony Ferrara
ircmax...@gmail.com
wrote:
All,
Voting has been closed on the scalar type declarations v0.5 RFC:
https://wiki.php.net/rfc/scalar_type_hints_v5
At a final score of 108:48, it has been accepted for PHP 7.
Thank you.
Anthony
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Hello,
how will these examples work btw?
// a.php
?php
declare(strict_types=1); function foo($fn) { $fn(1);
};
// b.php
?php
require 'a.php'; foo(function (int $a) { return $a * 2; });
// c.php
?php
function foo($fn) { $fn(1);
};
// d.php
?php
declare(strict_types=1); require 'c.php'; foo(function (int $a) { return
$a * 2; });
I can't find this in the RFC. I'd intuitively expect error in the
first example and the second one to work OK.
But at the same time, if there will be an error in the first example,
it is IMHO a huge flaw with this RFC. :/
Git clone, compile, try, report.
It sounds pretty straight forward to me instead of asking the same
questions (in various form but it ends to the same answer).
And the patch should be applied sooner rather than later. So we can fix
bugs if there are actual ones in the current implementation.
Hello,
if I had time to set up the compilation of PHP on Windows, I'd do it - but
I don't. I wanted to try it myself via http://3v4l.org/, but it
unfortunately doesn't support multiple files.
for anyone needing to test on Windows, there was builds for an older RFC
version
http://windows.php.net/downloads/snaps/ostc/scalar_type_hints_2_strict_mode/
but I just made quick builds for the current as well
http://windows.php.net/downloads/snaps/ostc/scalar_type_hints_v5/
So you've got the choice.
Cheers
Anatol
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] RE: [PHP-CVS] com php-src: Enable GCC global register variables if available: Zend/Zend.m4 Zend/zend_execute.c
bench.php worked with 4.7.0 worked fine foe me, but I saw crash on make
pharcmd and few tests related to assert().
Travis had similar crash on make pharcmd with 4.6.3.
For now I limited usage of global register variables by 4.8.0 and above.
Thanks. Dmitry.
On Wed, Mar 18, 2015 at 1:16 PM, Albert Casademont
albertcasadem...@gmail.com wrote:
Hi Dmitry,
I compiled it with gcc 4.7.2 and the bench.php performed well. Where did
you find the errors?
Albert
On Wed, Mar 18, 2015 at 12:22 AM, Dmitry Stogov dmi...@zend.com wrote:
Please also tell your GCC version.
We had problems with 4.6.3 and 4.7.0, so we disabled global variables for
GCC prior 4.8.0.
Thanks. Dmitry.
On Wed, Mar 18, 2015 at 12:36 AM, Dmitry Stogov dmi...@zend.com wrote:
Hi Caio,
Could you please run make test with and without the patch and compare
the failed tests.
The patch must not add new failures.
Thanks. Dmitry.
On Tue, Mar 17, 2015 at 10:15 PM, Caio Souza Oliveira
caio.olive...@eldorado.org.br wrote:
Hello guys!
I’ve included the optimization proposed in [1] on ppc64le machines and
I could get an outstanding performance improvement of about 69% when
running bench.php (from 2.394 sec to 1.640 sec in average). I’ve tested
this on POWER 8 machines. My patch can be seen at [2]
Thank you!
Caio Souza Oliveira
[1]
https://github.com/php/php-src/commit/fb4b7069842491eb66272587422a1f61d41eb869
[2] https://github.com/php/php-src/pull/1181
--
From: Albert Casademont Filella [mailto:albertcasadem...@gmail.com]
Sent: terça-feira, 17 de março de 2015 13:23
To: Gustavo Frederico Temple Pedrosa
Cc: Dmitry Stogov; Ard Biesheuvel; PHP Internals; Leonardo Bianconi;
Caio Souza Oliveira
Subject: Re: [PHP-DEV] RE: [PHP-CVS] com php-src: Enable GCC global
register variables if available: Zend/Zend.m4 Zend/zend_execute.c
Hi Dmitry,
I can confirm a ~10-11% reduction in execution time of the bench.php
from last month build (x64) to today's commit (from 1.154 sec to 1.010).
Amazing job!
Albert
On Tue, Mar 17, 2015 at 1:39 PM, Gustavo Frederico Temple Pedrosa
gustavo.pedr...@eldorado.org.br wrote:
Hi, Dmitry.
Thank you for contacting us.
Leonardo and Caio (in CC), they will verify.
Thank you very much. Temple.
From: Dmitry Stogov [mailto:dmi...@zend.com]
Sent: terça-feira, 17 de março de 2015 08:01
To: Ard Biesheuvel; Gustavo Frederico Temple Pedrosa
Cc: PHP Internals
Subject: Fwd: [PHP-CVS] com php-src: Enable GCC global register
variables if available: Zend/Zend.m4 Zend/zend_execute.c
Hi,
Please consider possibility of using the same optimization for ARM, PPC
and may be other platforms.
On x86(_84) it makes 2-7% speedup.
Only the similar changes in zend_execute.c and Zend.m4 are required to
enable it.
Thanks. Dmitry.
-- Forwarded message --
From: Dmitry Stogov dmi...@php.net
Date: Tue, Mar 17, 2015 at 1:51 PM
Subject: [PHP-CVS] com php-src: Enable GCC global register variables if
available: Zend/Zend.m4 Zend/zend_execute.c
To: php-...@lists.php.net
Commit:fb4b7069842491eb66272587422a1f61d41eb869
Author:Dmitry Stogov dmi...@zend.com Tue, 17 Mar 2015
13:51:02 +0300
Parents: 92bf4566ea65042b8f84cae7840298ed151a4f7a
Branches: master
Link:
http://git.php.net/?p=php-src.git;a=commitdiff;h=fb4b7069842491eb66272587422a1f61d41eb869
Log:
Enable GCC global register variables if available
Changed paths:
M Zend/Zend.m4
M Zend/zend_execute.c
Diff:
diff --git a/Zend/Zend.m4 b/Zend/Zend.m4
index 16f2d5f..e12b00d 100644
--- a/Zend/Zend.m4
+++ b/Zend/Zend.m4
@@ -409,3 +409,48 @@ else
AC_MSG_RESULT(no)
fi
fi
+
+AC_ARG_ENABLE(gcc-global-regs,
+[ --disable-gcc-global-regs
+ whether to enable GCC global register
variables],[
+ ZEND_GCC_GLOBAL_REGS=$enableval
+],[
+ ZEND_GCC_GLOBAL_REGS=yes
+])
+AC_MSG_CHECKING(for global register variables support)
+if test $ZEND_GCC_GLOBAL_REGS != no; then
+ AC_TRY_COMPILE([
+ ],[
+#if defined(__GNUC__) defined(i386)
+# define ZEND_VM_FP_GLOBAL_REG %esi
+# define ZEND_VM_IP_GLOBAL_REG %edi
+#elif defined(__GNUC__) defined(__x86_64__)
+# define ZEND_VM_FP_GLOBAL_REG %r14
+# define ZEND_VM_IP_GLOBAL_REG %r15
+#else
+# error global register variables are not supported
+#endif
+typedef int (*opcode_handler_t)(void);
+register void *FP __asm__(ZEND_VM_FP_GLOBAL_REG);
+register const opcode_handler_t *IP __asm__(ZEND_VM_IP_GLOBAL_REG);
+int emu(const opcode_handler_t *ip, void *fp) {
+ const opcode_handler_t *orig_ip = IP;
+ void *orig_fp = FP;
+ IP = ip;
+ FP = fp;
+ while ((*ip)());
+ FP = orig_fp;
+ IP = orig_ip;
+}
+ ], [
+ZEND_GCC_GLOBAL_REGS=yes
+ ], [
+ZEND_GCC_GLOBAL_REGS=no
+ ])
+fi
+if test $ZEND_GCC_GLOBAL_REGS = yes; then
+ AC_DEFINE([HAVE_GCC_GLOBAL_REGS], 1, [Define if the target system
has support for global register variables])
+else
Re: [PHP-DEV] [RFC][Accepted] Scalar Type Declarations V0.5
On Wed, Mar 18, 2015 at 1:47 PM, Anatol Belski anatol@belski.net wrote:
Pavel,
On Wed, March 18, 2015 11:05, Pavel Kouřil wrote:
On Wed, Mar 18, 2015 at 11:01 AM, Pierre Joye pierre@gmail.com
wrote:
On Mar 18, 2015 4:56 PM, Pavel Kouřil pajou...@gmail.com wrote:
On Mon, Mar 16, 2015 at 10:03 PM, Anthony Ferrara
ircmax...@gmail.com
wrote:
All,
Voting has been closed on the scalar type declarations v0.5 RFC:
https://wiki.php.net/rfc/scalar_type_hints_v5
At a final score of 108:48, it has been accepted for PHP 7.
Thank you.
Anthony
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Hello,
how will these examples work btw?
// a.php
?php
declare(strict_types=1); function foo($fn) { $fn(1);
};
// b.php
?php
require 'a.php'; foo(function (int $a) { return $a * 2; });
// c.php
?php
function foo($fn) { $fn(1);
};
// d.php
?php
declare(strict_types=1); require 'c.php'; foo(function (int $a) { return
$a * 2; });
I can't find this in the RFC. I'd intuitively expect error in the
first example and the second one to work OK.
But at the same time, if there will be an error in the first example,
it is IMHO a huge flaw with this RFC. :/
Git clone, compile, try, report.
It sounds pretty straight forward to me instead of asking the same
questions (in various form but it ends to the same answer).
And the patch should be applied sooner rather than later. So we can fix
bugs if there are actual ones in the current implementation.
Hello,
if I had time to set up the compilation of PHP on Windows, I'd do it - but
I don't. I wanted to try it myself via http://3v4l.org/, but it
unfortunately doesn't support multiple files.
for anyone needing to test on Windows, there was builds for an older RFC
version
http://windows.php.net/downloads/snaps/ostc/scalar_type_hints_2_strict_mode/
but I just made quick builds for the current as well
http://windows.php.net/downloads/snaps/ostc/scalar_type_hints_v5/
So you've got the choice.
Cheers
Anatol
Hello,
I've tried the build, and it seems like it's in the strict mode 100%
by default, and the declare statement doesn't recognize strict_types
(PHP Warning: Unsupported declare 'strict_types'). Is this
intentional?
Regards
Pavel Koruil
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [RFC][Accepted] Scalar Type Declarations V0.5
On 18 Mar 2015 15:52, Pavel Kouřil pajou...@gmail.com wrote: Hello, I made that conclusion because in the first example, the library kinda forces strict mode rules on the caller, even if he doesn't want to use strict mode - this makes the interoperability of the two modes problematic. This is incorrect, library force itself to use right types, not you. I don't see any problems here. The only thing that for sure lacks in PHP and that would make STH better is callable signature types. Also, the other possible outcome of the scenario (respecting the mode of the place where the callback is declared), is IMHO problematic as well, because it does not respect the strict mode of the place where it is called, making it inconsistent with how the dual mode RFC works in general. It doesn't matter where the callback or function was declared, it only matters where it was called. It pretty much is consistent.
Re: [PHP-DEV] RE: [PHP-CVS] com php-src: Enable GCC global register variables if available: Zend/Zend.m4 Zend/zend_execute.c
this is more then enough :) Thanks, I've committed your patch with additional limitation to GCC version. Thanks. Dmitry. On Wed, Mar 18, 2015 at 1:49 PM, Caio Souza Oliveira caio.olive...@eldorado.org.br wrote: Hello Dmitry! Sorry for my lack of details on my build process and environment. This time around, I'll try to be more descriptive about the subject. 1 - Environment I've compiled PHP, in both cases, using the following environment settings and running the following commands: export CC=/opt/at8.0/bin/gcc export CXX=/opt/at8.0/bin/g++ export CFLAGS=-g -O2 -fno-omit-frame-pointer -finline-limit=5 -mcpu=power8 -mtune=power8 -Wall export CXXFLAGS=-g -O2 -fno-omit-frame-pointer -finline-limit=5 -mcpu=power8 -mtune=power8 -Wall rm -vf configure; ./buildconf --force; ./configure --disable-libxml --disable-simplexml --disable-xml --disable-xmlreader --disable-xmlwriter --enable-sysvmsg --enable-sysvsem --enable-sysvshm --enable-shmop --disable-dom --without-pear --disable-phar --enable-bcmath --with-gmp --enable-pcntl --prefix=/opt/interpreters make clean; make; make install 2 - GCC Version Both php sources (with and without the patch) have been compiled with: gcc (GCC) 4.9.2 20141013 (Advance-Toolchain-at8.0) [ibm/gcc-4_9-branch, revision: 216164 merged from gcc-4_9-branch, revision 216151] Copyright (C) 2014 Free Software Foundation, Inc. 3 - make test results *** Before applying the proposed patch on ppc64le *** = TEST RESULT SUMMARY - Exts skipped: 49 Exts tested : 26 - Number of tests : 13562 8305 Tests skipped : 5257 ( 38.8%) Tests warned:1 ( 0.0%) ( 0.0%) Tests failed:3 ( 0.0%) ( 0.0%) Expected fail : 32 ( 0.2%) ( 0.4%) Tests passed: 8269 ( 61.0%) ( 99.6%) - Time taken : 283 seconds = *** After applying the proposed patch on ppc64le *** = TEST RESULT SUMMARY - Exts skipped: 49 Exts tested : 26 - Number of tests : 13562 8305 Tests skipped : 5257 ( 38.8%) Tests warned:1 ( 0.0%) ( 0.0%) Tests failed:3 ( 0.0%) ( 0.0%) Expected fail : 32 ( 0.2%) ( 0.4%) Tests passed: 8269 ( 61.0%) ( 99.6%) - Time taken : 282 seconds = More details can be seen in [1]: [1] https://gist.github.com/caioso/9360bd95e829c4172446 Do you need any other information? Thank you very much! Caio From: Dmitry Stogov [mailto:dmi...@zend.com] Sent: terça-feira, 17 de março de 2015 20:22 To: Caio Souza Oliveira Cc: Albert Casademont Filella; Gustavo Frederico Temple Pedrosa; Ard Biesheuvel; PHP Internals; Leonardo Bianconi Subject: Re: [PHP-DEV] RE: [PHP-CVS] com php-src: Enable GCC global register variables if available: Zend/Zend.m4 Zend/zend_execute.c Please also tell your GCC version. We had problems with 4.6.3 and 4.7.0, so we disabled global variables for GCC prior 4.8.0. Thanks. Dmitry. On Wed, Mar 18, 2015 at 12:36 AM, Dmitry Stogov dmi...@zend.com wrote: Hi Caio, Could you please run make test with and without the patch and compare the failed tests. The patch must not add new failures. Thanks. Dmitry. On Tue, Mar 17, 2015 at 10:15 PM, Caio Souza Oliveira caio.olive...@eldorado.org.br wrote: Hello guys! I’ve included the optimization proposed in [1] on ppc64le machines and I could get an outstanding performance improvement of about 69% when running bench.php (from 2.394 sec to 1.640 sec in average). I’ve tested this on POWER 8 machines. My patch can be seen at [2] Thank you! Caio Souza Oliveira [1] https://github.com/php/php-src/commit/fb4b7069842491eb66272587422a1f61d41eb869 [2] https://github.com/php/php-src/pull/1181 -- From: Albert Casademont Filella [mailto:albertcasadem...@gmail.com] Sent: terça-feira, 17 de março de 2015 13:23 To: Gustavo Frederico Temple Pedrosa Cc: Dmitry Stogov; Ard Biesheuvel; PHP Internals; Leonardo Bianconi; Caio Souza Oliveira Subject: Re: [PHP-DEV] RE: [PHP-CVS] com php-src: Enable GCC global register variables if available: Zend/Zend.m4 Zend/zend_execute.c Hi Dmitry, I can confirm a ~10-11% reduction in execution time of the bench.php from last month build (x64) to today's commit (from 1.154 sec to 1.010). Amazing job!
Re: [PHP-DEV] [RFC][Accepted] Scalar Type Declarations V0.5
On 18 Mar 2015 14:32, Pavel Kouřil pajou...@gmail.com wrote:
On Wednesday, March 18, 2015, Patrick ALLAERT patrickalla...@php.net
wrote:
Le mer. 18 mars 2015 à 10:56, Pavel Kouřil pajou...@gmail.com a écrit
:
Hello,
how will these examples work btw?
// a.php
?php
declare(strict_types=1);
function foo($fn) {
$fn(1);
};
// b.php
?php
require 'a.php';
foo(function (int $a) { return $a * 2; });
// c.php
?php
function foo($fn) {
$fn(1);
};
// d.php
?php
declare(strict_types=1);
require 'c.php';
foo(function (int $a) { return $a * 2; });
I can't find this in the RFC. I'd intuitively expect error in the
first example and the second one to work OK.
Your intuition is correct.
But at the same time, if there will be an error in the first example,
it is IMHO a huge flaw with this RFC. :/
Flaw vs. design choice. This is one of the reason that this aspect,
amongst others, has been very debated.
But if it works this way, the strict mode isn't optional and users of a
library NEED to care which mode the library uses?
If library chose to use strict mode then the odds are it will take care of
passing right types to callbacks and interfaced methods.
Saying that strict mode isn't optional is not true, I don't see why you
have made this conclusion.
RE: [PHP-DEV] [RFC][Accepted] Scalar Type Declarations V0.5
Hey Pavel,
how will these examples work btw?
// a.php
?php
declare(strict_types=1);
function foo($fn) {
$fn(1);
};
// b.php
?php
require 'a.php';
foo(function (int $a) { return $a * 2; });
Result: catchable fatal error
Reason: invocation context is in strict mode
// c.php
?php
function foo($fn) {
$fn(1);
};
// d.php
?php
declare(strict_types=1);
require 'c.php';
foo(function (int $a) { return $a * 2; });
Result: no error
Reason: invocation context is in weak mode
I can't find this in the RFC. I'd intuitively expect error in the
first example and the second one to work OK.
Correct :)
-Tom
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [RFC][Accepted] Scalar Type Declarations V0.5
On Wed, Mar 18, 2015 at 1:13 PM, Nikita Nefedov inefe...@gmail.com wrote:
On 18 Mar 2015 14:32, Pavel Kouřil pajou...@gmail.com wrote:
On Wednesday, March 18, 2015, Patrick ALLAERT patrickalla...@php.net
wrote:
Le mer. 18 mars 2015 à 10:56, Pavel Kouřil pajou...@gmail.com a écrit
:
Hello,
how will these examples work btw?
// a.php
?php
declare(strict_types=1);
function foo($fn) {
$fn(1);
};
// b.php
?php
require 'a.php';
foo(function (int $a) { return $a * 2; });
// c.php
?php
function foo($fn) {
$fn(1);
};
// d.php
?php
declare(strict_types=1);
require 'c.php';
foo(function (int $a) { return $a * 2; });
I can't find this in the RFC. I'd intuitively expect error in the
first example and the second one to work OK.
Your intuition is correct.
But at the same time, if there will be an error in the first example,
it is IMHO a huge flaw with this RFC. :/
Flaw vs. design choice. This is one of the reason that this aspect,
amongst others, has been very debated.
But if it works this way, the strict mode isn't optional and users of a
library NEED to care which mode the library uses?
If library chose to use strict mode then the odds are it will take care of
passing right types to callbacks and interfaced methods.
Saying that strict mode isn't optional is not true, I don't see why you have
made this conclusion.
Hello,
I made that conclusion because in the first example, the library kinda
forces strict mode rules on the caller, even if he doesn't want to use
strict mode - this makes the interoperability of the two modes
problematic.
Also, the other possible outcome of the scenario (respecting the mode
of the place where the callback is declared), is IMHO problematic as
well, because it does not respect the strict mode of the place where
it is called, making it inconsistent with how the dual mode RFC works
in general.
Regards
Pavel Kouril
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [RFC][Accepted] Scalar Type Declarations V0.5
On Wed, Mar 18, 2015 at 2:02 PM, Nikita Nefedov inefe...@gmail.com wrote:
On 18 Mar 2015 15:52, Pavel Kouřil pajou...@gmail.com wrote:
Hello,
I made that conclusion because in the first example, the library kinda
forces strict mode rules on the caller, even if he doesn't want to use
strict mode - this makes the interoperability of the two modes
problematic.
This is incorrect, library force itself to use right types, not you. I don't
see any problems here. The only thing that for sure lacks in PHP and that
would make STH better is callable signature types.
Well, it forces you to do that, basically. And also forces you to
care about the mode of library, adding mental overhead. Look more
closesly at the first example - does the error in that case make sense
to you (from purely user's point of view)? When you call
a(function(int $b) {return $b * 2; }) - should you really be required
to check the context within the a() is declared?
Also, the other possible outcome of the scenario (respecting the mode
of the place where the callback is declared), is IMHO problematic as
well, because it does not respect the strict mode of the place where
it is called, making it inconsistent with how the dual mode RFC works
in general.
It doesn't matter where the callback or function was declared, it only
matters where it was called. It pretty much is consistent.
This was just a comment about how it would be (also) wrong to solve it
the other way around.
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [RFC][Accepted] Scalar Type Declarations V0.5
Pavel Kouřil wrote:
On Wed, Mar 18, 2015 at 1:47 PM, Anatol Belski anatol@belski.net wrote:
for anyone needing to test on Windows, there was builds for an older RFC
version
http://windows.php.net/downloads/snaps/ostc/scalar_type_hints_2_strict_mode/
but I just made quick builds for the current as well
http://windows.php.net/downloads/snaps/ostc/scalar_type_hints_v5/
So you've got the choice.
I've tried the build, and it seems like it's in the strict mode 100%
by default, and the declare statement doesn't recognize strict_types
(PHP Warning: Unsupported declare 'strict_types'). Is this
intentional?
I quickly tried both php-7.0.0-dev-nts-Win32-VC11-x64.zip, but it seems
the 2015-03-18 build doesn't handle scalar type hints at all.
?php
function foo(int $n) {
var_dump($n);
}
foo(42);
Catchable fatal error: Argument 1 passed to foo() must be an
instance of int, integer given, called in [...] on line 6 and
defined in [...] on line 3
The 2015-02-09 build works fine, at least for this example.
--
Christoph M. Becker
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [RFC][Accepted] Scalar Type Declarations V0.5
On 18 March 2015 at 13:12, Pavel Kouřil pajou...@gmail.com wrote:
On Wed, Mar 18, 2015 at 2:02 PM, Nikita Nefedov inefe...@gmail.com
wrote:
On 18 Mar 2015 15:52, Pavel Kouřil pajou...@gmail.com wrote:
Hello,
I made that conclusion because in the first example, the library kinda
forces strict mode rules on the caller, even if he doesn't want to use
strict mode - this makes the interoperability of the two modes
problematic.
This is incorrect, library force itself to use right types, not you. I
don't
see any problems here. The only thing that for sure lacks in PHP and that
would make STH better is callable signature types.
Well, it forces you to do that, basically. And also forces you to
care about the mode of library, adding mental overhead. Look more
closesly at the first example - does the error in that case make sense
to you (from purely user's point of view)? When you call
a(function(int $b) {return $b * 2; }) - should you really be required
to check the context within the a() is declared?
You don't need to check the declaration context of a(). Either the library
is definitely passing an integer and your code will work, or it isn't
definitely passing an integer, maybe it's a float, so you shouldn't declare
the parameter type at all - it isn't a typed parameter. This is simply a
matter of RTFM in the library docs (and if there are no docs or the docs
are wrong then you have to go read the library code anyway just as you
would today, so you haven't lost anything).
Type declarations are a way to more completely describe the interface
contract, they are *not* a replacement/shorthand for casts. If the desired
behaviour for your callback should be to accept anything and treat it as an
integer for the computation, then your code should be written to describe
that intent, i.e:
a(function($b) {return ((int)$b) * 2; })
This code both describes the behaviour of a() and the programmer's intended
behaviour for the callback. Using a type declaration as a means to force a
cast hides both of these - a reader would assume the callback is always
called with an integer.
Also, the other possible outcome of the scenario (respecting the mode
of the place where the callback is declared), is IMHO problematic as
well, because it does not respect the strict mode of the place where
it is called, making it inconsistent with how the dual mode RFC works
in general.
It doesn't matter where the callback or function was declared, it only
matters where it was called. It pretty much is consistent.
This was just a comment about how it would be (also) wrong to solve it
the other way around.
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [RFC][Accepted] Scalar Type Declarations V0.5
On Wed, Mar 18, 2015 at 4:28 PM, Chris Wright c...@daverandom.com wrote:
On 18 March 2015 at 13:12, Pavel Kouřil pajou...@gmail.com wrote:
On Wed, Mar 18, 2015 at 2:02 PM, Nikita Nefedov inefe...@gmail.com
wrote:
On 18 Mar 2015 15:52, Pavel Kouřil pajou...@gmail.com wrote:
Hello,
I made that conclusion because in the first example, the library kinda
forces strict mode rules on the caller, even if he doesn't want to use
strict mode - this makes the interoperability of the two modes
problematic.
This is incorrect, library force itself to use right types, not you. I
don't
see any problems here. The only thing that for sure lacks in PHP and
that
would make STH better is callable signature types.
Well, it forces you to do that, basically. And also forces you to
care about the mode of library, adding mental overhead. Look more
closesly at the first example - does the error in that case make sense
to you (from purely user's point of view)? When you call
a(function(int $b) {return $b * 2; }) - should you really be required
to check the context within the a() is declared?
You don't need to check the declaration context of a(). Either the library
is definitely passing an integer and your code will work, or it isn't
definitely passing an integer, maybe it's a float, so you shouldn't declare
the parameter type at all - it isn't a typed parameter. This is simply a
matter of RTFM in the library docs (and if there are no docs or the docs
are wrong then you have to go read the library code anyway just as you
would today, so you haven't lost anything).
Type declarations are a way to more completely describe the interface
contract, they are *not* a replacement/shorthand for casts. If the desired
behaviour for your callback should be to accept anything and treat it as an
integer for the computation, then your code should be written to describe
that intent, i.e:
a(function($b) {return ((int)$b) * 2; })
This code both describes the behaviour of a() and the programmer's intended
behaviour for the callback. Using a type declaration as a means to force a
cast hides both of these - a reader would assume the callback is always
called with an integer.
Also, the other possible outcome of the scenario (respecting the mode
of the place where the callback is declared), is IMHO problematic as
well, because it does not respect the strict mode of the place where
it is called, making it inconsistent with how the dual mode RFC works
in general.
It doesn't matter where the callback or function was declared, it only
matters where it was called. It pretty much is consistent.
This was just a comment about how it would be (also) wrong to solve it
the other way around.
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
there is even a better argument for this, say you can add a callback to
your franework to register actions and it has to be:
function (Request $request, Response $response) {
}
This is the public interface of the callback so to speak. If you add
something different, you get a catchable fatal error, because you use that
library wrong, right now in PHP 5.*.
I don't see how strict mode enabled in a library, forcing you to define the
right signature for scalars is problematic from any POV. Granted you can
even just omit the scalar type hints completely and it would work.
Re: [PHP-DEV] [RFC][Accepted] Scalar Type Declarations V0.5
On Wed, March 18, 2015 14:33, Pavel Kouřil wrote: I've tried the build, and it seems like it's in the strict mode 100% by default, and the declare statement doesn't recognize strict_types (PHP Warning: Unsupported declare 'strict_types'). Is this intentional? No, that's probably me building the wrong branch. I've redone and reuploaded, it should be fine. Thanks. Anatol. -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [RFC][Accepted] Scalar Type Declarations V0.5
2015-03-18 16:28 GMT+01:00 Chris Wright c...@daverandom.com:
On 18 March 2015 at 13:12, Pavel Kouřil pajou...@gmail.com wrote:
On Wed, Mar 18, 2015 at 2:02 PM, Nikita Nefedov inefe...@gmail.com
wrote:
On 18 Mar 2015 15:52, Pavel Kouřil pajou...@gmail.com wrote:
Hello,
I made that conclusion because in the first example, the library kinda
forces strict mode rules on the caller, even if he doesn't want to use
strict mode - this makes the interoperability of the two modes
problematic.
This is incorrect, library force itself to use right types, not you. I
don't
see any problems here. The only thing that for sure lacks in PHP and
that
would make STH better is callable signature types.
Well, it forces you to do that, basically. And also forces you to
care about the mode of library, adding mental overhead. Look more
closesly at the first example - does the error in that case make sense
to you (from purely user's point of view)? When you call
a(function(int $b) {return $b * 2; }) - should you really be required
to check the context within the a() is declared?
You don't need to check the declaration context of a(). Either the library
is definitely passing an integer and your code will work, or it isn't
definitely passing an integer, maybe it's a float, so you shouldn't declare
the parameter type at all - it isn't a typed parameter. This is simply a
matter of RTFM in the library docs (and if there are no docs or the docs
are wrong then you have to go read the library code anyway just as you
would today, so you haven't lost anything).
Type declarations are a way to more completely describe the interface
contract, they are *not* a replacement/shorthand for casts. If the desired
behaviour for your callback should be to accept anything and treat it as an
integer for the computation, then your code should be written to describe
that intent, i.e:
a(function($b) {return ((int)$b) * 2; })
This code both describes the behaviour of a() and the programmer's intended
behaviour for the callback. Using a type declaration as a means to force a
cast hides both of these - a reader would assume the callback is always
called with an integer.
Yet, this code has a major flaw: the type of $b cannot be statically
inferred.
No matter how strict the new mode is, it can only catch errors at
runtime. This is usually too late. Having the ability to find error at
design time is priceless. For me, this is the primary reason I am using
type hints.
Lazare INEPOLOGLOU
Ingénieur Logiciel
Also, the other possible outcome of the scenario (respecting the mode
of the place where the callback is declared), is IMHO problematic as
well, because it does not respect the strict mode of the place where
it is called, making it inconsistent with how the dual mode RFC works
in general.
It doesn't matter where the callback or function was declared, it only
matters where it was called. It pretty much is consistent.
This was just a comment about how it would be (also) wrong to solve it
the other way around.
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [RFC][Accepted] Scalar Type Declarations V0.5
On 18 Mar 2015, at 3:44 pm, Yasuo Ohgaki yohg...@ohgaki.net wrote:
Hi Pierre,
On Wed, Mar 18, 2015 at 1:35 PM, Pierre Joye pierre@gmail.com wrote:
On Mar 18, 2015 11:26 AM, Yasuo Ohgaki yohg...@ohgaki.net wrote:
I didn't have my time to spent for the patch. So I don't verify this
by myself, but it seems common sense for this RFC.
So you voted against it without knowing how it actually works or aims to
work? I suggest you to do it now then, before going further with this
discussion :)
I know we are better to play with patch before vote.
I played with Zeev's patch and I was sure it's better ;)
How many of voters spend enough time for both patches before vote?
The reason I admit that I didn't spent time to play with the patch is
following behavior does not make sense to me much and I have
doubt for it.
lib.php:
?php
declare(strict_types = 1);
function foo(int $a) {
// no function call here
}
?
The declare here does just nothing.
Correct. There are no function calls in the file, so there's nothing for
declare strict to act on.
?php
require lib.php;
foo(123); // will work
?
?php
declare(strict_types = 1);
require lib.php;
foo(123); // will give an error
?
Could someone knowledgeable shed light on this?
Regards,
--
Yasuo Ohgaki
yohg...@ohgaki.net
Shed light on what exactly? Why it behaves this way?
The second file passes because it is in the default weak mode, so it will
coerce to an int, so the type hint is satisfied.
The third file will error because you have asked it to error when you pass the
wrong scalar type to a function.
David
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Voting irregularities
On Thu, Mar 19, 2015 at 12:19 PM, Christoph Becker cmbecke...@gmx.de wrote: Pierre Joye wrote: However, as of today, you are the blocking point when it comes to improve the wiki RFCs, registration and voting areas.And this is really becoming a problem. I am not talking about irregularities and the likes and I agree that it may not be fair to start bitching about one or another vote, especially for some 1st time voters but oldest contributors. While I do see an issue with inactive developers suddenly jumping in but not using or contributing to PHP in any form since quite long. But this is a totally different issues and I really have no idea how to solve that, I do not see it as a big issue either so... However, the RFCs have been abused in many possible ways where I thought common sense will make people act fairly and correctly. I was wrong. Having simple technical measures to ensure fairness in discussions, voting and end of voting periods will prevent some of these abuses to happen again. It is possible to achieve that without going down a more drastic road (anonymous votes or other more deep changes) but will make things work the same way for everyone. [...] Now, to be able to actually implement the little technical measure to ensure that everyone follows the same rules, I ask you one more time to provide the data of the current wiki so patches, changes etc can be implemented in a safer way. You know where to reach me to provide it. Thanks for your cooperation. Whatever you want to improve, please consider that the PHP wiki is driven by DokuWiki which needs to get updated from time to time (lately there have been two updates every year[1]; this is not accounting any necessary updates to DokuWiki plugins). These updates seem to be painful already, due to the required customizations. It would be helpful if further as well as existing customizations could be moved to custom DokuWiki plugins as far as feasible. I know, we setup it together with Lukas back then. And yes, most of the changes should be plugins not patching the cores, the latter is a maintenance nightmare. Furthermore, please note that README.CONFIGURE[2] states: | There is no data in cvs. The data is only available on the server and | backup many times daily. If you need sample data using the production | documents, please contact the php webmaster list. I know that too and asked that for more than a year now. Hence my rather undiplomatic mail. To avoid potential misunderstandings: I'm rather new to php.net, and I don't like to get involved into apparently long standing contentions. Instead I'd prefer to help to maintain the technical base (i.e. the software -- I'm no sys admin) of the wiki for the sake of PHP. I very much appreciate your efforts and contributions, much much welcome! :) Cheers, -- Pierre @pierrejoye | http://www.libgd.org -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Voting irregularities
Pierre Joye wrote: However, as of today, you are the blocking point when it comes to improve the wiki RFCs, registration and voting areas.And this is really becoming a problem. I am not talking about irregularities and the likes and I agree that it may not be fair to start bitching about one or another vote, especially for some 1st time voters but oldest contributors. While I do see an issue with inactive developers suddenly jumping in but not using or contributing to PHP in any form since quite long. But this is a totally different issues and I really have no idea how to solve that, I do not see it as a big issue either so... However, the RFCs have been abused in many possible ways where I thought common sense will make people act fairly and correctly. I was wrong. Having simple technical measures to ensure fairness in discussions, voting and end of voting periods will prevent some of these abuses to happen again. It is possible to achieve that without going down a more drastic road (anonymous votes or other more deep changes) but will make things work the same way for everyone. [...] Now, to be able to actually implement the little technical measure to ensure that everyone follows the same rules, I ask you one more time to provide the data of the current wiki so patches, changes etc can be implemented in a safer way. You know where to reach me to provide it. Thanks for your cooperation. Whatever you want to improve, please consider that the PHP wiki is driven by DokuWiki which needs to get updated from time to time (lately there have been two updates every year[1]; this is not accounting any necessary updates to DokuWiki plugins). These updates seem to be painful already, due to the required customizations. It would be helpful if further as well as existing customizations could be moved to custom DokuWiki plugins as far as feasible. Furthermore, please note that README.CONFIGURE[2] states: | There is no data in cvs. The data is only available on the server and | backup many times daily. If you need sample data using the production | documents, please contact the php webmaster list. To avoid potential misunderstandings: I'm rather new to php.net, and I don't like to get involved into apparently long standing contentions. Instead I'd prefer to help to maintain the technical base (i.e. the software -- I'm no sys admin) of the wiki for the sake of PHP. [1] http://cmsimpleforum.com/viewtopic.php?f=29t=8602 [2] https://github.com/php/web-wiki/tree/master/docs -- Christoph M. Becker -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [RFC][Accepted] Scalar Type Declarations V0.5
Hi, 2015-03-18 20:42 GMT+01:00 Lazare Inepologlou linep...@gmail.com: However, it seems that the second form is possible to fail, and that depends on the mode (strict or not) of the library that contains the function a. It does not depend on the mode that I have chosen to work with. The two closures will not work in the same way and that's a kind of a WTF moment. If the library documents that it is passing an int or an intable value in non-strict to the callback and it does not do so it has a bug. If the library does not declare a type and you hint an int and it passes something else, you created a bug. However, to work in a real code base some discipline and clean documentation from the library author is required. But I agree that this is currently fragile. Having a way to hint a callables signature may not solve the issue , but make it easier to catch and shift most, if not all, responsibility to the library author. -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Voting irregularities
On Mar 19, 2015 5:20 AM, Hannes Magnusson hannes.magnus...@gmail.com wrote: I have asked you before to stop harassing me, and stop spreading these lies and defamation before. Furthermore I have asked you to stop emailing all together. I have asked you very politely several times before. Please refrain for talking about me or to me ever again. I will take legal actions if this does not stop. Thank you for your understanding. No idea what you are talking about and really not interested to this kind of discussion, but I am still waiting for the data to valid changes. Cheers, Pierre
Re: [PHP-DEV] Voting irregularities
Whatever you want to improve, please consider that the PHP wiki is driven by DokuWiki which needs to get updated from time to time (lately there have been two updates every year[1]; this is not accounting any necessary updates to DokuWiki plugins). These updates seem to be painful already, due to the required customizations. It would be helpful if further as well as existing customizations could be moved to custom DokuWiki plugins as far as feasible. Thankfully I've never had to do that part myself. Do we have a document somewhere that explains our general update/upgrade procedure for DokuWiki? Maybe now that PHP 7.0 is in feature freeze I can find some time to work on our web infrastructure again. -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [RFC][Accepted] Scalar Type Declarations V0.5
2015-03-18 18:30 GMT+01:00 Chris Wright c...@daverandom.com:
On 18 March 2015 at 17:07, Lazare Inepologlou linep...@gmail.com wrote:
2015-03-18 16:28 GMT+01:00 Chris Wright c...@daverandom.com:
On 18 March 2015 at 13:12, Pavel Kouřil pajou...@gmail.com wrote:
On Wed, Mar 18, 2015 at 2:02 PM, Nikita Nefedov inefe...@gmail.com
wrote:
On 18 Mar 2015 15:52, Pavel Kouřil pajou...@gmail.com wrote:
Hello,
I made that conclusion because in the first example, the library
kinda
forces strict mode rules on the caller, even if he doesn't want to
use
strict mode - this makes the interoperability of the two modes
problematic.
This is incorrect, library force itself to use right types, not you.
I
don't
see any problems here. The only thing that for sure lacks in PHP and
that
would make STH better is callable signature types.
Well, it forces you to do that, basically. And also forces you to
care about the mode of library, adding mental overhead. Look more
closesly at the first example - does the error in that case make sense
to you (from purely user's point of view)? When you call
a(function(int $b) {return $b * 2; }) - should you really be required
to check the context within the a() is declared?
You don't need to check the declaration context of a(). Either the
library
is definitely passing an integer and your code will work, or it isn't
definitely passing an integer, maybe it's a float, so you shouldn't
declare
the parameter type at all - it isn't a typed parameter. This is simply a
matter of RTFM in the library docs (and if there are no docs or the docs
are wrong then you have to go read the library code anyway just as you
would today, so you haven't lost anything).
Type declarations are a way to more completely describe the interface
contract, they are *not* a replacement/shorthand for casts. If the
desired
behaviour for your callback should be to accept anything and treat it as
an
integer for the computation, then your code should be written to describe
that intent, i.e:
a(function($b) {return ((int)$b) * 2; })
This code both describes the behaviour of a() and the programmer's
intended
behaviour for the callback. Using a type declaration as a means to force
a
cast hides both of these - a reader would assume the callback is always
called with an integer.
Yet, this code has a major flaw: the type of $b cannot be statically
inferred.
No matter how strict the new mode is, it can only catch errors at
runtime. This is usually too late. Having the ability to find error at
design time is priceless. For me, this is the primary reason I am using
type hints.
In the case where the caller may or may not be passing an int (i.e. the
case where the original example would error because of strict mode in the
lib), the type cannot be inferred through static analysis no matter what
you do, at least not correctly, because it has no definite type. Since
there is currently no number union type it is mixed, which is the
default type for any variable.
Let me be more clear. The type of $b cannot be statically inferred here:
a(function($b) {return ((int)$b) * 2; })
But it can be inferred here:
a(function(int $b) {return $b * 2; })
So I would always prefer to use the second form, especially if the closure
was more complex.
However, it seems that the second form is possible to fail, and that
depends on the mode (strict or not) of the library that contains the
function a. It does not depend on the mode that I have chosen to work with.
The two closures will not work in the same way and that's a kind of a WTF
moment.
Lazare INEPOLOGLOU
Ingénieur Logiciel
Lazare INEPOLOGLOU
Ingénieur Logiciel
Also, the other possible outcome of the scenario (respecting the
mode
of the place where the callback is declared), is IMHO problematic as
well, because it does not respect the strict mode of the place where
it is called, making it inconsistent with how the dual mode RFC
works
in general.
It doesn't matter where the callback or function was declared, it
only
matters where it was called. It pretty much is consistent.
This was just a comment about how it would be (also) wrong to solve it
the other way around.
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [RFC][Accepted] Scalar Type Declarations V0.5
On 18 March 2015 at 17:07, Lazare Inepologlou linep...@gmail.com wrote:
2015-03-18 16:28 GMT+01:00 Chris Wright c...@daverandom.com:
On 18 March 2015 at 13:12, Pavel Kouřil pajou...@gmail.com wrote:
On Wed, Mar 18, 2015 at 2:02 PM, Nikita Nefedov inefe...@gmail.com
wrote:
On 18 Mar 2015 15:52, Pavel Kouřil pajou...@gmail.com wrote:
Hello,
I made that conclusion because in the first example, the library
kinda
forces strict mode rules on the caller, even if he doesn't want to
use
strict mode - this makes the interoperability of the two modes
problematic.
This is incorrect, library force itself to use right types, not you. I
don't
see any problems here. The only thing that for sure lacks in PHP and
that
would make STH better is callable signature types.
Well, it forces you to do that, basically. And also forces you to
care about the mode of library, adding mental overhead. Look more
closesly at the first example - does the error in that case make sense
to you (from purely user's point of view)? When you call
a(function(int $b) {return $b * 2; }) - should you really be required
to check the context within the a() is declared?
You don't need to check the declaration context of a(). Either the library
is definitely passing an integer and your code will work, or it isn't
definitely passing an integer, maybe it's a float, so you shouldn't
declare
the parameter type at all - it isn't a typed parameter. This is simply a
matter of RTFM in the library docs (and if there are no docs or the docs
are wrong then you have to go read the library code anyway just as you
would today, so you haven't lost anything).
Type declarations are a way to more completely describe the interface
contract, they are *not* a replacement/shorthand for casts. If the desired
behaviour for your callback should be to accept anything and treat it as
an
integer for the computation, then your code should be written to describe
that intent, i.e:
a(function($b) {return ((int)$b) * 2; })
This code both describes the behaviour of a() and the programmer's
intended
behaviour for the callback. Using a type declaration as a means to force a
cast hides both of these - a reader would assume the callback is always
called with an integer.
Yet, this code has a major flaw: the type of $b cannot be statically
inferred.
No matter how strict the new mode is, it can only catch errors at
runtime. This is usually too late. Having the ability to find error at
design time is priceless. For me, this is the primary reason I am using
type hints.
In the case where the caller may or may not be passing an int (i.e. the
case where the original example would error because of strict mode in the
lib), the type cannot be inferred through static analysis no matter what
you do, at least not correctly, because it has no definite type. Since
there is currently no number union type it is mixed, which is the
default type for any variable.
Lazare INEPOLOGLOU
Ingénieur Logiciel
Also, the other possible outcome of the scenario (respecting the mode
of the place where the callback is declared), is IMHO problematic as
well, because it does not respect the strict mode of the place where
it is called, making it inconsistent with how the dual mode RFC works
in general.
It doesn't matter where the callback or function was declared, it only
matters where it was called. It pretty much is consistent.
This was just a comment about how it would be (also) wrong to solve it
the other way around.
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Voting irregularities
I have asked you before to stop harassing me, and stop spreading these lies and defamation before. Furthermore I have asked you to stop emailing all together. I have asked you very politely several times before. Please refrain for talking about me or to me ever again. I will take legal actions if this does not stop. Thank you for your understanding. -Hannes On Tue, Mar 17, 2015 at 6:30 PM, Pierre Joye pierre@gmail.com wrote: hi, On Wed, Mar 18, 2015 at 9:00 AM, Hannes Magnusson hannes.magnus...@gmail.com wrote: On Tue, Mar 17, 2015 at 2:15 PM, Sebastian B.-Hagensen sbj.ml.r...@gmail.com wrote: Hi, 2015-03-17 20:55 GMT+01:00 Hannes Magnusson hannes.magnus...@gmail.com: If you need to confirm the statistics, or gather more background data, then feel free to contact me privately, off the list, and I'll get you the account approval dates (karma and/or wiki). While I agree that the issue at hand was not presented in the way it should have been may still become a valid issue in the future. If you want to prevent situations or even (wrong) ideas and accusations like these the dates of account creations have to be public and easily accessible by everyone involved (publicly listed on people.php.net for example). people.php.net are php.net karma holders. We have no responsibility to disclose any information about our contributors to anyone. It is however fun to do so, so I created people.php.net listing random info about our contributors. If you can think of other fun things to do with that website, I'd love feedback and contributions! The wiki account system is different. php.net karma holders have access out-of-the-box using their vcs credentials. Then there is a special case where you have to register to the wiki itself. Having a wiki account does nothing out-of-the-box. You have to ask for specific access. Since the inception of the wiki I have been the only one giving out wiki credentials. This has mostly been to outsiders wanting to write RFCs. I have vague memories having given 2-3 people access to https://wiki.php.net/usergroups and similar to docs and so on. These people still cannot vote. A person who maintains popular pecl extension cannot vote either, unless the extension is maintained on the php.net infrastructure (and therefore requiring php.net account) btw. There have been several members from the community that have asked for voting privileges, as per the voting rfc. I have arbitrary approved maybe 3 or 4 over the years. The other 5-10 did not get voting privileges because the authors of the voting rfc didn't care. I have absolutely no interest this voting business and and strongly disagree with the entire voting rfc idea. I would love to get back to http://producingoss.com/en/consensus-democracy.html that's your good right to disagree and I respect your opinion in that regard. However, as of today, you are the blocking point when it comes to improve the wiki RFCs, registration and voting areas.And this is really becoming a problem. I am not talking about irregularities and the likes and I agree that it may not be fair to start bitching about one or another vote, especially for some 1st time voters but oldest contributors. While I do see an issue with inactive developers suddenly jumping in but not using or contributing to PHP in any form since quite long. But this is a totally different issues and I really have no idea how to solve that, I do not see it as a big issue either so... However, the RFCs have been abused in many possible ways where I thought common sense will make people act fairly and correctly. I was wrong. Having simple technical measures to ensure fairness in discussions, voting and end of voting periods will prevent some of these abuses to happen again. It is possible to achieve that without going down a more drastic road (anonymous votes or other more deep changes) but will make things work the same way for everyone. The other problem I see, which becomes a habit for a couple of RFC authors, is the quality of the RFC. On one hand we have detailed high quality RFC, clear communications and flows and on the other hand, incomplete, confusing, lack of communications (aka missing the points of a Request for Comments completely). And this is a much more bigger worry than anything else. We have to fix that and such RFCs must be discarded or simply not accepted to vote unless they actually reach a certain quality and will to discuss. I will start another separate thread about that. Now, to be able to actually implement the little technical measure to ensure that everyone follows the same rules, I ask you one more time to provide the data of the current wiki so patches, changes etc can be implemented in a safer way. You know where to reach me to provide it. Thanks for your cooperation. Cheers, -- Pierre @pierrejoye | http://www.libgd.org -- PHP Internals - PHP Runtime Development
[PHP-DEV] Re: Hello PHP-World
Pretzlaw wrote: my name is Mike Pretzlaw, I am a (senior) developer, (junior) project manager and work with PHP for a decade now. About time to contribute to the PHP-Core and give something back to it. Unfortunately the registration (https://wiki.php.net/rfc/engine_exceptions_for_php7?do=register) does not seem to be send anywhere or lacks at response messages to the submitter. Yet I hope my registration reached the mailing list ;) I assume that the wiki account request hasn't been send. There was a bug, so error messages didn't show up. It should be fixed now, so if you still want a wiki account, try registering again. Note, though, that a wiki account doesn't give you voting rights. My knowledge in PHP is great (as I can say) and thanks to my studying I am familiar with C++, Java and other languages. But I rather like to take things step by step than straddle into your development. For the first step it shall be contribution to the RFC and topics in the mailing list. By looking and learning from the patches in the RFC list I hope to meet the whole architecture of PHP (as my second step). And at l(e)ast I like to write RFCs too and contributes patches. Bugfixes, fasten up algorithms and developing more in the core is a dream but not impossible. But that last one is something I need to find out and hope to be welcome in your team. Please give me the opportunity to contribute to your language and the chance to adapt more competences. It would meet one of my big wishes. Note, there is http://php.net/get-involved.php where several ways to contribute to the PHP project are pointed out. -- Christoph M. Becker -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
