[PHP-DEV] Pull requests report (9/9/2013)
Hi, The last week brought quite a few new pull requests. I hope we'll keep see new people getting involved. New: #427 https://github.com/php/php-src/pull/427 run-tests.php: Added EXPECT_EXTERNAL, EXPECTF_EXTERNAL, EXPECTREGEX_EXTERNAL #55736 #428 https://github.com/php/php-src/pull/428 Fixed bug #48770: when call_user_func() fails to call parent from inheriting class (2) #429 https://github.com/php/php-src/pull/429 Segfault fix for more than one modules #430 https://github.com/php/php-src/pull/430 Add support for CryptoPro S-box for GOST #431 https://github.com/php/php-src/pull/431 New function: stream_socket_listen() #432 https://github.com/php/php-src/pull/432 Addition of DATE_SQL and DATE_SQLTIMESTAMP constants #434 https://github.com/php/php-src/pull/434 Call php_module_shutdown() for php-fpm child processes Merged: (none) Closed (without merge): #433 https://github.com/php/php-src/pull/433 undefine user constants at runtime Still open (21 days): #413 https://github.com/php/php-src/pull/413 Make exception messages and error output binary safe #416 https://github.com/php/php-src/pull/416 New function: pcntl_daemonize pcntl_setaffinity #421 https://github.com/php/php-src/pull/421 Dedicated syntax for variadic parameters #422 https://github.com/php/php-src/pull/422 Add test for bug #60598 #424 https://github.com/php/php-src/pull/424 Signature is valid if there are less args #426 https://github.com/php/php-src/pull/426 Parameter skipping in function calls Kaplan On Tue, Sep 3, 2013 at 9:31 AM, Lior Kaplan lio...@zend.com wrote: New: #422 https://github.com/php/php-src/pull/422 Add test for bug #60598 #424 https://github.com/php/php-src/pull/424 Signature is valid if there are less args #426 https://github.com/php/php-src/pull/426 Parameter skipping in function calls Merged: #420 https://github.com/php/php-src/pull/420 Always provide retval ptr #423 https://github.com/php/php-src/pull/423 Fix bug #65579 (Using traits with get_class_methods causes segfault). Closed (without merge): #425 https://github.com/php/php-src/pull/425 Function autoloading Still open (21 days): #406 https://github.com/php/php-src/pull/406 OnEnable INI MH for opcache causing strangeness #413 https://github.com/php/php-src/pull/413 Make exception messages and error output binary safe #416 https://github.com/php/php-src/pull/416 New function: pcntl_daemonize pcntl_setaffinity #421 https://github.com/php/php-src/pull/421 Dedicated syntax for variadic parameters Kaplan
[PHP-DEV] 5.4 DateTimeZone: Supported timezones have changed
Hello together, just wanted to mention, what the list of supported Timezones has changedin 5.4. It's already mentioned here, that all special timezones, expect of UTC are deprecated: http://www.php.net/manual/en/timezones.others.php But couldn't found that in the upgrade guide...so i used CET somewhere in my code and didn't found the error soon A short note in the upgrade guid would be great!
Re: [PHP-DEV] 5.4 DateTimeZone: Supported timezones have changed
Martin Keckeis wrote: Hello together, just wanted to mention, what the list of supported Timezones has changedin 5.4. It's already mentioned here, that all special timezones, expect of UTC are deprecated: http://www.php.net/manual/en/timezones.others.php But couldn't found that in the upgrade guide...so i used CET somewhere in my code and didn't found the error soon A short note in the upgrade guid would be great! This is not so much an 'upgrade' note, but rather a update to the timezone library in general. The tz database is being 'rationalised' at the moment, and the base list of zone names simplified, with many of these only being retained for 'backwards' compatibility. Derick will probably add a comment, but we can expect a few more changes over the next couple of updates to the tz data. -- 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
Re: [PHP-DEV] When will 5.2 binaries be retired from windows.php.net?
On Mon, Sep 2, 2013 at 10:38 AM, Thomas Hruska thru...@cubiclesoft.comwrote: It is approaching 2 1/2 years since the last release of PHP 5.2. 5.2 has been declared dead on more than one occasion around here. The dust has more or less settled since PHP 5.3 EOL was announced. The ONLY reason I still support 5.2 in my own userland software is because the 5.2 binaries are available on windows.php.net. There are some things I'd like to do that are only available in the core in 5.3 and later but I won't do them until the binaries for 5.2 disappear from the website. I like to make sure I reach the widest possible, yet rationally supportable audience. As such, I figure that generally supporting whatever users can download from an official source is a good logical cutoff point. Is the issue the 5.2 binaries haven't been retired due to 5.2 being compiled with VC6? VC10 and VC11 runtimes fixed a lot of the issues that the VC8 and VC9 runtimes had. I've dropped VC11 runtimes into the same directory as the PHP 5.5 binaries and they seem to work fine on hosts without VC11 on them. That is a huge improvement over the VC9 runtimes, which are a nightmare to work with from both a development and deployment perspective. What I'm NOT saying is that the 5.2 binaries should come down right now. What I am saying is that the discussion and the plan formulated for their removal should take place if it hasn't already. Currently the downloads page on http://php.net/ only lists the supported versions(5.3, 5.4, 5.5) and I think that http://windows.php.net/ should be synced with that, so the 5.2 links should be removed. http://museum.php.net/ already has those binaries, so it would be still available for those who are looking for that version, but without the possible confusion that the 5.2 version is still supported on windows. Pierre, what do you think? -- Ferenc Kovács @Tyr43l - http://tyrael.hu
Re: [PHP-DEV] When will 5.2 binaries be retired from windows.php.net?
hi, On Mon, Sep 9, 2013 at 2:26 PM, Ferenc Kovacs tyr...@gmail.com wrote: On Mon, Sep 2, 2013 at 10:38 AM, Thomas Hruska thru...@cubiclesoft.comwrote: It is approaching 2 1/2 years since the last release of PHP 5.2. 5.2 has been declared dead on more than one occasion around here. The dust has more or less settled since PHP 5.3 EOL was announced. The ONLY reason I still support 5.2 in my own userland software is because the 5.2 binaries are available on windows.php.net. There are some things I'd like to do that are only available in the core in 5.3 and later but I won't do them until the binaries for 5.2 disappear from the website. I like to make sure I reach the widest possible, yet rationally supportable audience. As such, I figure that generally supporting whatever users can download from an official source is a good logical cutoff point. Is the issue the 5.2 binaries haven't been retired due to 5.2 being compiled with VC6? VC10 and VC11 runtimes fixed a lot of the issues that the VC8 and VC9 runtimes had. I've dropped VC11 runtimes into the same directory as the PHP 5.5 binaries and they seem to work fine on hosts without VC11 on them. That is a huge improvement over the VC9 runtimes, which are a nightmare to work with from both a development and deployment perspective. What I'm NOT saying is that the 5.2 binaries should come down right now. What I am saying is that the discussion and the plan formulated for their removal should take place if it hasn't already. Currently the downloads page on http://php.net/ only lists the supported versions(5.3, 5.4, 5.5) and I think that http://windows.php.net/ should be synced with that, so the 5.2 links should be removed. http://museum.php.net/ already has those binaries, so it would be still available for those who are looking for that version, but without the possible confusion that the 5.2 version is still supported on windows. Pierre, what do you think? There is no link from windows.php.net web sites to 5.2. They only remain in the downloads section, if accessed directly. 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] 5.4 DateTimeZone: Supported timezones have changed
Hi lester,
2013/9/9 Lester Caine les...@lsces.co.uk
Martin Keckeis wrote:
Hello together,
just wanted to mention, what the list of supported Timezones has changedin
5.4.
It's already mentioned here, that all special timezones, expect of UTC
are deprecated:
http://www.php.net/manual/en/**timezones.others.phphttp://www.php.net/manual/en/timezones.others.php
But couldn't found that in the upgrade guide...so i used CET somewhere in
my code and didn't found the error soon
A short note in the upgrade guid would be great!
This is not so much an 'upgrade' note, but rather a update to the timezone
library in general. The tz database is being 'rationalised' at the moment,
and the base list of zone names simplified, with many of these only being
retained for 'backwards' compatibility. Derick will probably add a comment,
but we can expect a few more changes over the next couple of updates to the
tz data.
Okay no problem, just wanted to mention it.
If you use a deprecated Timezone somewhere and don't know it, it's hard to
track down...(no exception)
I only found it randomly today, that i've used it there and all time data
in the database are not correct...
If you use something like:
\DateTime::createFromFormat('Y-m-d H:i:s', '2013-09-09 14:49:00', new
DateTimeZone('CET'))
Just the default timezone from ini will be used and therefor the dateTime
value is wrong if you save it or display it somewhere...
Re: [PHP-DEV] When will 5.2 binaries be retired from windows.php.net?
Pierre Joye wrote: There is no link from windows.php.net web sites to 5.2. They only remain in the downloads section, if accessed directly. I think it's the presence of 5.2 on the download page that is being talked about? While I still have reason to use 5.2, I'd support dropping this ti the archives. You only need to be using 5.2 if you already have it installed, and it's up to us to manage that access. -- 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
Re: [PHP-DEV] 5.4 DateTimeZone: Supported timezones have changed
Martin Keckeis wrote:
Hi lester,
2013/9/9 Lester Caine les...@lsces.co.uk mailto:les...@lsces.co.uk
Martin Keckeis wrote:
Hello together,
just wanted to mention, what the list of supported Timezones has
changedin
5.4.
It's already mentioned here, that all special timezones, expect of UTC
are deprecated:
http://www.php.net/manual/en/__timezones.others.php
http://www.php.net/manual/en/timezones.others.php
But couldn't found that in the upgrade guide...so i used CET somewhere
in
my code and didn't found the error soon
A short note in the upgrade guid would be great!
This is not so much an 'upgrade' note, but rather a update to the timezone
library in general. The tz database is being 'rationalised' at the moment,
and the base list of zone names simplified, with many of these only being
retained for 'backwards' compatibility. Derick will probably add a comment,
but we can expect a few more changes over the next couple of updates to the
tz data.
Okay no problem, just wanted to mention it.
If you use a deprecated Timezone somewhere and don't know it, it's hard to track
down...(no exception)
I only found it randomly today, that i've used it there and all time data in
the database are not correct...
If you use something like:
\DateTime::createFromFormat('Y-m-d H:i:s', '2013-09-09 14:49:00', new
DateTimeZone('CET'))
Just the default timezone from ini will be used and therefor the dateTime value
is wrong if you save it or display it somewhere...
That sounds like a different problem. I've no time to play at the moment, but
does an 'non-existent' timezone give you an error? Or is it just the 'retired'
timezone names that are a problem?
--
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
Re: [PHP-DEV] When will 5.2 binaries be retired from windows.php.net?
Currently the downloads page on http://php.net/ only lists the supported versions(5.3, 5.4, 5.5) and I think that http://windows.php.net/ should be synced with that, so the 5.2 links should be removed. http://museum.php.net/ already has those binaries, so it would be still available for those who are looking for that version, but without the possible confusion that the 5.2 version is still supported on windows. Pierre, what do you think? There is no link from windows.php.net web sites to 5.2. They only remain in the downloads section, if accessed directly. yes, we are talking about the downloads page, which page is linked from like every release annonuncement on the windows.php.net frontpage(we even have 5.2 release announcements if you scroll down a bit). I think we should remove the 5.2 section from the downloads page. -- Ferenc Kovács @Tyr43l - http://tyrael.hu
Re: [PHP-DEV] When will 5.2 binaries be retired from windows.php.net?
On Mon, Sep 9, 2013 at 3:48 PM, Ferenc Kovacs tyr...@gmail.com wrote: Currently the downloads page on http://php.net/ only lists the supported versions(5.3, 5.4, 5.5) and I think that http://windows.php.net/should be synced with that, so the 5.2 links should be removed. http://museum.php.net/ already has those binaries, so it would be still available for those who are looking for that version, but without the possible confusion that the 5.2 version is still supported on windows. Pierre, what do you think? There is no link from windows.php.net web sites to 5.2. They only remain in the downloads section, if accessed directly. yes, we are talking about the downloads page, which page is linked from like every release annonuncement on the windows.php.net frontpage(we even have 5.2 release announcements if you scroll down a bit). I think we should remove the 5.2 section from the downloads page. I agree as it's been EOLed. Julien.Pauli
Re: [PHP-DEV] When will 5.2 binaries be retired from windows.php.net?
done, was sure it was done since long already. On Mon, Sep 9, 2013 at 4:14 PM, Julien Pauli jpa...@php.net wrote: On Mon, Sep 9, 2013 at 3:48 PM, Ferenc Kovacs tyr...@gmail.com wrote: Currently the downloads page on http://php.net/ only lists the supported versions(5.3, 5.4, 5.5) and I think that http://windows.php.net/ should be synced with that, so the 5.2 links should be removed. http://museum.php.net/ already has those binaries, so it would be still available for those who are looking for that version, but without the possible confusion that the 5.2 version is still supported on windows. Pierre, what do you think? There is no link from windows.php.net web sites to 5.2. They only remain in the downloads section, if accessed directly. yes, we are talking about the downloads page, which page is linked from like every release annonuncement on the windows.php.net frontpage(we even have 5.2 release announcements if you scroll down a bit). I think we should remove the 5.2 section from the downloads page. I agree as it's been EOLed. Julien.Pauli -- Pierre @pierrejoye | http://blog.thepimp.net | http://www.libgd.org -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] When will 5.2 binaries be retired from windows.php.net?
Pierre Joye wrote: done, was sure it was done since long already. Pierre ... I think that the 5.2 stuff was left as the only VC6 build. The notes of the side bar refer still to using that when perhaps a 'no longer supported' may be better? -- 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
Re: [PHP-DEV] When will 5.2 binaries be retired from windows.php.net?
On Mon, Sep 9, 2013 at 6:21 PM, Lester Caine les...@lsces.co.uk wrote: Pierre Joye wrote: done, was sure it was done since long already. Pierre ... I think that the 5.2 stuff was left as the only VC6 build. The notes of the side bar refer still to using that when perhaps a 'no longer supported' may be better? As it is no longer supported it has no place there. However you can still fetch it here http://windows.php.net/downloads/ we keep there as many installers fetch it from there, as convenience. But its time is counted as well (will be moved to museum), -- 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] When will 5.2 binaries be retired from windows.php.net?
Pierre Joye wrote: On Mon, Sep 9, 2013 at 6:21 PM, Lester Caine les...@lsces.co.uk wrote: Pierre Joye wrote: done, was sure it was done since long already. Pierre ... I think that the 5.2 stuff was left as the only VC6 build. The notes of the side bar refer still to using that when perhaps a 'no longer supported' may be better? As it is no longer supported it has no place there. However you can still fetch it here http://windows.php.net/downloads/ we keep there as many installers fetch it from there, as convenience. But its time is counted as well (will be moved to museum), Pierre ... all I am saying is that the reference to 'older VC6 versions' in the left hand column would benefit from a 'which are only available in the museum', although I would suggest it may be better simply to say 'no longer supported'. *I* seem to recall that you did take the 5.2 stuff off, but restored it when the Apache link was pointed out ... but I may well be wrong ;) -- 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] segfaulting in php5.5 core when doing function wrapping
I have a PHP extension that wraps or replaces function calls. This extension has worked successfully with minimal changes between php versions from PHP 5.1 through PHP 5.4. However, my attempts to port this extension to PHP 5.5 have failed in one case, which makes we wonder about my other successes with PHP 5.5. I have figured out that in order to get access to the incoming actual parameters for a hooked function I need to indirect through -prev_execute_data iff the arguments pointer on the topmost frame is null. Here's the scenario where I segfault: I rebind zend_execute_ex to point to my executor. For most code paths my executor does: (a) gathers some profiling data; (b) may call 0 or more times to other php functions using the call_user_function_ex entry point into zend; (c) turns around and calls execute_ex (zend_execute_data *ed), with the same value of ed that my executor was given and so apparently correctly executes the original function in what I presume is the correct evaluation context. However, if I do not do step (c) to execute the intended function, then shortly after my executor returns I get a segfault in zend_vm_stack_get_arg_ex (zend_execute.h line 320 from php 5.5.3), called by zend_vm_stack_get_arg, called by ZEND_RECV_SPEC_HANDLER. The location of the segfault has been seen to move around, and, for example, has been observed to happen when the number of local slots to clear in a clear_multiple is the bogus value 0x5a5a5a5a (which says, obviously, there's memory corruption). The discussions here http://www.php.net/manual/en/migration55.internals.phpdo not provide enough insight as to the changes in zend and how the extension authors need to adjust for these changes. Is there another working extension that does similar things that I can study, or other guidelines to consult? I note that Julienn Salleyron reported similar issues with his AOP work, but that work contains a lot of code very specific to the implementation of zend itself, and so from my position looks to be too complex. -- Robert Henry, New Relic
[PHP-DEV] Re: [RFC] Named parameters
On Fri, Sep 6, 2013 at 6:39 PM, Nikita Popov nikita@gmail.com wrote:
Hi internals!
I created an RFC and preliminary implementation for named parameters:
https://wiki.php.net/rfc/named_params
Thanks for the feedback everyone! I will not answer every mail individually
(as many share a common topic) and will try to group things reasonably.
Dynamic named parameters syntax
-
I'm strongly against making the parameter names in named-args calls
dynamic. If you need dynamic parameter names you can always use unpacking
notation:
foo(...[$paramName = $paramValue]);
If we allow dynamic named params virtually any syntax we choose will seem
somewhat ambiguous, e.g.:
foo(paramName = $paramValue); // is paramName a parameter name or a
constant with the parameter name?
foo($paramName = $paramValue); // is $paramName a parameter name or a
variable with the parameter name?
By clearly saying that the parameter names in the named-args syntax
(whichever we choose) are static much confusion can be avoided.
Furthermore allow non-constant parameter names will complicate the
implementation for very little practical gain.
Let only special functions accept named params
-
There has been the suggestion that only functions that are specifically
marked (a named keyword) can accept named parameters and another
suggestion that only parameters that have been specifically marked can be
passed as named parameters.
In such a setting named parameters would loose all value for me.
Implementing the good old $options array isn't *that* hard after all. The
value named parameters offer to me is being able to use them everywhere I
consider them beneficial without requiring special support from the API. In
particular I think it's critical that they also work with existing internal
functions (we have quite a lot of internal functions with many independent
optional parameters) and also in cases where $options are not worth it
(just a single optional parameter).
Concerns about readability and APIs
-
There have been some concerns regarding readability and API design relating
to named args:
By Matthew:
I feel like this will just encourage more core PHP functions with an
unmanageable number of parameters. Will there be any proposed
guidelines to how future functions will make use of named parameters?
e.g., Will we see native functions with 20 arguments
You need to shift your viewpoint. Named parameters change what an
unmanageable number of parameters is. Right now I would consider a
function with just two independent(!) optional parameters to already have
an unmanageable number of parameters. Right now I would not willingly
include such a function in an API design. Named args change this. With them
there is nothing bad to a function with multiple independent optional
parameters. So: Will there be more functions that have more parameters?
Maybe. Is that a problem? No.
By Matthew:
The OCD in me shudders to think about now having to parse through
people's code like:
substr('length' = 1, 'string' = 'Hello World');
Now I see the function, and I have to see how they ordered their
parameters. Why was 'start' omitted... is this a warning due to using
NULL as an int.. did the person mean 'start', etc? It's just one
example, but I know that this sort of code will start cropping up
everywhere.
You will not have to parse through that code, because it's not valid. If
you fail to pass a required argument, you'll get a warning just like you
already do now. Your example is no different from the nonsensicality of
doing a substr(Foo) call.
Furthermore I think your concerns of overuse of named parameters in
contexts where they make no sense (like a substr call) are unfounded.
Looking at other languages that already support named parameters (like
Python or C#) I never noticed such patterns. Of course, every feature has a
potential for misuse, but I tend to think that most programmers *do* have
enough common sense to use features where reasonable and not at every
possible occurrence just because they can.
Renaming of parameters in signatures
-
Until now three options were discussed:
1. Throw an E_STRICT (or similar) error during signature validation if a
parameter is renamed
2. Don't validate parameter renames in signature and just let people hit
the runtime error when they do the call.
3. Create an ini-setting chooses either behavior 1 or 2.
Both options 1 and 2 are not ideal, the former because it breaks old
code, the latter because we allow LSP violations that lead to runtime
errors. Option 3 is not really an option, we already decided a while ago
not to introduce ini-settings controlling runtime behavior.
I have another suggestion at how this could be approached: When the used
named parameter is not found we go through the inheritance hierarchy and
try to find the parameter name there. So if we have
class A {
public function foo($oldBar) { ... }
}
and
class B extends A
Re: [PHP-DEV] Re: [RFC] Named parameters
Nikita, I agree with your views, although, I think your last suggestion comes close to being close to some sort of weird method overloading (the way I understood it). I'd expect B::foo() to throw a warning/error and maybe stop there, and you're considering reaching to the parent method to see if that signature matches the function call... While method overloading would be interesting to have (see previous discussions on the matter ;)) this is a sort of weird and unexpected reaching-back behaviour... I'm not sure this seems like a logical approach, I say stick with the error and expect a consistent usage of the (rewritten) API and prevent obscure bugs where you change an implementation and rewrite param names when in fact you should stay consistent with the existing code if you're extending existing behaviour! In fact I'm not sure if the other way around should be the norm; where we'd force the dev to implement the *same* args as the parent (like it is now: i.e. type hinting, same signature, etc); even if it's just to do an unset($oldbar) inside something like B::foo($newBar, $oldBar = NULL) Was that clear? Thanks, Daniel Macedo -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [RFC] Named parameters
On Fri, Sep 6, 2013 at 8:01 PM, Johannes Schlüter johan...@schlueters.dewrote: From the explanation it sounds like there shouldn't be a high cost, but as fcalls are a key operation and already quite slow I wonder if you could share some benchmarks. (non-debug-non-tsrm-build) A good start might be Zend/bench.php. And I understand this is not the final patch but good to have the order of magnitude. I didn't see any obvious regressions from Zend/bench.php and this is also what I would expect: The parts relating to named arguments are hidden behind optype-specialization of the send opcodes, so those shouldn't affect perf. There is also a bit extra code in do_fcall_common to handle passing of additional unknown named params, but that's also just two branches in a large mix of other code. So it really shouldn't impact performance and judging from Zend/bench.php it doesn't. I also did a very quick test how a normal call compares to one using named params. Right now the latter is about 25% slower. But I'm pretty sure this number can be improved a good bit, e.g. I'm not yet making use of CACHED_PTR to store the argument number of the parameter. Nikita
Re: [PHP-DEV] 5.4 DateTimeZone: Supported timezones have changed
On Mon, 9 Sep 2013, Martin Keckeis wrote: Hello together, just wanted to mention, what the list of supported Timezones has changedin 5.4. It's already mentioned here, that all special timezones, expect of UTC are deprecated: http://www.php.net/manual/en/timezones.others.php But couldn't found that in the upgrade guide...so i used CET somewhere in my code and didn't found the error soon A short note in the upgrade guid would be great! But nothing changed at all. CET has always been in others and should be avoided just like the documentation says. cheers, Derick -- http://derickrethans.nl | http://xdebug.org Like Xdebug? Consider a donation: http://xdebug.org/donate.php twitter: @derickr and @xdebug Posted with an email client that doesn't mangle email: alpine -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [RFC] Named parameters
On Sat, Sep 7, 2013 at 9:52 AM, Pierre Joye pierre@gmail.com wrote: In no particular order: . Warning: Cannot pass positional arguments after named arguments. Aborting argument unpacking in %s on line %d Would it make more sense to make it a fatal error? As the code will likely not work as expected, at all. It could be a bit too harsh but as it is a new feature, there is no BC impact and ensure good usage. I agree that continuing the function call in that case is a bad idea, but I also really dislike throwing fatal errors when dynamic constructors are used. An exception would be optimal here (no continued function call, but easily recoverable), but I know I'm not allowed to introduce those... . would it make sense to have an alternative zend API to fetch one or more argument using its name? I can see a couple of usages for such a function I provide this function: ZEND_API int zend_get_arg_num(zend_uint *arg_num_target, zend_function *fn, char *name, int name_len, zend_ulong hash_value TSRMLS_DC); Using it you can get the argument number from a parameter name and based on that lookup the value of the argument as usual. Is that sufficient? - It would be nice to add (later once the RFC is more stable) docs about which impacts and changes are expected for extension developers Yes, sure :) - Do you have a fork for this RFC? Much easier to test, create snaps, etc. Yes, it's the namedParams branch of my github fork: https://github.com/nikic/php-src/tree/namedParams Nikita
Re: [PHP-DEV] 5.4 DateTimeZone: Supported timezones have changed
On Mon, 9 Sep 2013, Derick Rethans wrote:
On Mon, 9 Sep 2013, Martin Keckeis wrote:
If you use a deprecated Timezone somewhere and don't know it, it's hard to
track down...(no exception)
I only found it randomly today, that i've used it there and all time data
in the database are not correct...
If you use something like:
\DateTime::createFromFormat('Y-m-d H:i:s', '2013-09-09 14:49:00', new
DateTimeZone('CET'))
Just the default timezone from ini will be used and therefor the dateTime
value is wrong if you save it or display it somewhere...
That is not true. CET is actually mapped to Europe/Berlin. This mapping
was made specifically for BC reasons.
Or even in a smaller example:
derick@whisky:~ $ php -r '$a = new DateTimeZone(CET); echo $a-getName(),
\n;'
Europe/Berlin
cheers,
Derick
--
http://derickrethans.nl | http://xdebug.org
Like Xdebug? Consider a donation: http://xdebug.org/donate.php
twitter: @derickr and @xdebug
Posted with an email client that doesn't mangle email: alpine
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] 5.4 DateTimeZone: Supported timezones have changed
On Mon, 9 Sep 2013, Martin Keckeis wrote:
If you use a deprecated Timezone somewhere and don't know it, it's hard to
track down...(no exception)
I only found it randomly today, that i've used it there and all time data
in the database are not correct...
If you use something like:
\DateTime::createFromFormat('Y-m-d H:i:s', '2013-09-09 14:49:00', new
DateTimeZone('CET'))
Just the default timezone from ini will be used and therefor the dateTime
value is wrong if you save it or display it somewhere...
That is not true. CET is actually mapped to Europe/Berlin. This mapping
was made specifically for BC reasons.
derick@whisky:~ $ php
?php
$a = \DateTime::createFromFormat('Y-m-d H:i:s', '2013-09-09 14:49:00' );
var_dump( $a );
?
class DateTime#1 (3) {
public $date =
string(19) 2013-09-09 14:49:00
public $timezone_type =
int(3)
public $timezone =
string(13) Europe/London
}
derick@whisky:~ $ php
?php
$a = \DateTime::createFromFormat('Y-m-d H:i:s', '2013-09-09 14:49:00', new
DateTimeZone('CET'));
var_dump( $a );
?
class DateTime#2 (3) {
public $date =
string(19) 2013-09-09 14:49:00
public $timezone_type =
int(3)
public $timezone =
string(13) Europe/Berlin
}
cheers,
Derick
--
http://derickrethans.nl | http://xdebug.org
Like Xdebug? Consider a donation: http://xdebug.org/donate.php
twitter: @derickr and @xdebug
Posted with an email client that doesn't mangle email: alpine
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] 5.4 DateTimeZone: Supported timezones have changed
Derick Rethans wrote: This is not so much an 'upgrade' note, but rather a update to the timezone library in general. The tz database is being 'rationalised' at the moment, and the base list of zone names simplified, with many of these only being retained for 'backwards' compatibility. Derick will probably add a comment, but we can expect a few more changes over the next couple of updates to the tz data. We will see what happens there. As far as I know most of those changes have been reverted in the TZDB anyway. The discussion on 'extended' timezones is still going on ;) Daylight saving did not start in 1970, but the recent proposed change in tz was to ignore them to simplify the list of timezones. That has now been reverted, but how to handle the additional information has not yet been agreed. The tz dataabse will probably not return pre 1970 date, you will need a different build of tz to get that. Which is something I think is simply wrong! We have increasingly accurate pre 1970 data but that requires additional timezone names which the basic tz database will not support. -- 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
Re: [PHP-DEV] 5.4 DateTimeZone: Supported timezones have changed
On Mon, 9 Sep 2013, Lester Caine wrote: Martin Keckeis wrote: just wanted to mention, what the list of supported Timezones has changedin 5.4. It's already mentioned here, that all special timezones, expect of UTC are deprecated: http://www.php.net/manual/en/timezones.others.php But couldn't found that in the upgrade guide...so i used CET somewhere in my code and didn't found the error soon A short note in the upgrade guid would be great! This is not so much an 'upgrade' note, but rather a update to the timezone library in general. The tz database is being 'rationalised' at the moment, and the base list of zone names simplified, with many of these only being retained for 'backwards' compatibility. Derick will probably add a comment, but we can expect a few more changes over the next couple of updates to the tz data. We will see what happens there. As far as I know most of those changes have been reverted in the TZDB anyway. cheers, Derick -- http://derickrethans.nl | http://xdebug.org Like Xdebug? Consider a donation: http://xdebug.org/donate.php twitter: @derickr and @xdebug Posted with an email client that doesn't mangle email: alpine -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Re: [RFC] Named parameters
On Mon, Sep 9, 2013 at 9:39 PM, Daniel Macedo admac...@gmail.com wrote:
Nikita,
I agree with your views, although, I think your last suggestion comes
close to being close to some sort of weird method overloading (the way
I understood it).
Uh, I think this is a misunderstanding caused by my bad phrasing. I'll try
to clarify:
class A {
public function foo($oldBar) { ... }
}
class B extends A {
public function foo($newBar) { ... }
}
$b-foo(oldBar = $xyz);
Here `$b-foo()` will call `B::foo()`, *not* `A::foo()`. The thing about
looking at the parameter names of the parent methods is just to make sure
calls are compatible with the parameter names of parent methods, even if
those names were changed during inheritance. We do not actually call the
parent method, we just borrow the parameter name from there.
In fact I'm not sure if the other way around should be the norm; where
we'd force the dev to implement the *same* args as the parent (like it
is now: i.e. type hinting, same signature, etc); even if it's just to
do an unset($oldbar) inside something like B::foo($newBar, $oldBar =
NULL)
Yes, throwing an error during the signature validation is the right thing
to do from a theoretic point of view. The issue is just that it breaks old
code which didn't make sure that parameter names between parent and child
lined up. Break is a bit too much here as it would still run, just
throwing an E_STRICT. This is what I'd like to go for, but others disagree
so I tried to offer an alternative solution.
Nikita
Re: [PHP-DEV] When will 5.2 binaries be retired from windows.php.net?
On Mon, Sep 9, 2013 at 8:06 PM, Lester Caine les...@lsces.co.uk wrote: Pierre ... all I am saying is that the reference to 'older VC6 versions' in the left hand column would benefit from a 'which are only available in the museum', although I would suggest it may be better simply to say 'no longer supported'. I do not think it would benefit anyone to promote VC6, in any form :) The only note we keep there is about using apache.org's binaries: If you are using PHP with Apache 1 or Apache2 fromapache.org (not recommended) you need to use the older VC6 versions of PHP compiled with the legacy Visual Studio 6 compiler. Do NOT use VC9+ versions of PHP with the apache.org binaries. 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] When will 5.2 binaries be retired from windows.php.net?
On Tue, Sep 10, 2013 at 1:05 AM, Lester Caine les...@lsces.co.uk wrote: Pierre Joye wrote: On Mon, Sep 9, 2013 at 8:06 PM, Lester Caine les...@lsces.co.uk wrote: Pierre ... all I am saying is that the reference to 'older VC6 versions' in the left hand column would benefit from a 'which are only available in the museum', although I would suggest it may be better simply to say 'no longer supported'. I do not think it would benefit anyone to promote VC6, in any form :) Exactly The only note we keep there is about using apache.org's binaries: If you are using PHP with Apache 1 or Apache2 fromapache.org (not recommended) you need to use the older VC6 versions of PHP compiled with the legacy Visual Studio 6 compiler. Do NOT use VC9+ versions of PHP with the apache.org binaries. Which is why I said 'no longer supported' so an extra line This is no longer supported. Would just clarify the situation rather than it's current suggestion that you SHOULD use the VC6 versions ... And it is what it means, you must use VC6, not supported anymore, if you use apache.org's binary. -- Pierre @pierrejoye | http://www.libgd.org -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
