Re: [PHP-DEV] Re: Support negative indexes for arrays and strings
On 03.09.2012, at 09:37, Jannik Zschiesche he...@apfelbox.net wrote: The main problem arises from the ambiguity for $array[-1] for arrays. But this is easily solvable: just introduce a slice operator. $array[:-1] and the ambiguity is gone. That would return an array containing the last item as the sole member, not the last item itself. David -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Support negative indexes for arrays and strings
On 03.09.2012, at 01:11, sle...@pipeline.com wrote: I see how this may work for strings and simple vectors, but what about this: $a = array(-1 = foo, -2 = bar); echo $a[-1]; It should keep returning foo, right? So then the question is - what $array[-1] actually means? Context would be the deciding factor, i.e. perhaps restrict the shortcut's applicability to only a positive sequence of numbers for an indexed array's keys, as follows: $a = array(10 = pen, 11 = heaven); echo $a[-1]; // heaven You clearly haven't thought this through. What if my code wants to check for the existance of an array index -1, and it doesn't know what kind of array gets passed in? For an index -1, a value would exist, and for a sequential array, it would exist as well. This is an insane can of worms. smime.p7s Description: S/MIME cryptographic signature
Re: [PHP-DEV] Older style frameworks ...
On 25.08.2012, at 11:15, Lester Caine les...@lsces.co.uk wrote: Many of my 'problems' with all of the 'progress' being made with PHP are caused because I'm using a core framework who's origins go back to PHP4 days. I'm sorry, but what is the point of this email? This is a mailing list, not a group therapy session for people who didn't update their code regularly. David -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Results of testing ZF against PHP 5.4.0RC1
So the consensus so far is to drop notices from ob_clean(), ob_end_clean() and ob_get_clean()? What about ob_flush() or others? David On 18.11.2011, at 14:08, Ilia Alshanetsky wrote: I agree with Stas' point there is really no need to force people do the while (ob_get_level()) ob_end_clean(); loop or force people to use the @ob_end_clean(); to avoid notices. If there are no buffers to clear it should be a noop, without any notices being raised. On Fri, Nov 18, 2011 at 12:04 AM, Stas Malyshev smalys...@sugarcrm.com wrote: Hi! First of all, ob_clean() and ob_end_clean() will raise the same notice even in PHP 5.3. It seems inconsistent to me to treat these three differently, so in that regard, PHP 5.4 is actually fixing behavior (although arguably the other way to approach the problem is to remove the notice from all three of them). I don't think ob_end_clean() should produce notices, otherwise it leads to needless boilerplate code like: if(ob_get_evel()0) ob_end_clean(); while you could just write ob_end_clean() and be done with it. ob_clean() is trickier since it's supposed to leave buffer in place, but for functions that are supposed to remove the buffer warning doesn't add any value, only makes people write uglier code. -- Stanislav Malyshev, Software Architect SugarCRM: http://www.sugarcrm.com/ (408)454-6900 ext. 227 -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php smime.p7s Description: S/MIME cryptographic signature
Re: [PHP-DEV] Results of testing ZF against PHP 5.4.0RC1
On 17.11.2011, at 21:46, Matthew Weier O'Phinney wrote: * ob_get_clean() now raises a notice if no buffer to delete Prior to 5.4.0RC1, if there were no buffers left to delete, ob_get_clean() was silent. It now raises a notice -- which, when using PHPUnit, means an error is now raised, making the test fail. I do not see any benefit to raising the notice; if there's nothing left to clean, return an empty string or false (which was the former behavior, and is documented). I've looked into this for the purpose of coming up with a patch, and judging from the tests and also behavior in PHP 5.3, it doesn't seem that simple. First of all, ob_clean() and ob_end_clean() will raise the same notice even in PHP 5.3. It seems inconsistent to me to treat these three differently, so in that regard, PHP 5.4 is actually fixing behavior (although arguably the other way to approach the problem is to remove the notice from all three of them). Also, the documentation states for ob_get_clean(): ob_get_clean() essentially executes both ob_get_contents() and ob_end_clean(). Since ob_end_clean() currently raises the notice, it'd not be unreasonable to expect it for ob_get_clean() as well. David smime.p7s Description: S/MIME cryptographic signature
[PHP-DEV] get_magic_quotes_gpc() throws deprecated warning in 5.4
I looked through the mailing list archives, and in several threads the consensus seemed to be that the setters should throw a warning, but the getters should not... localhost:test dzuelke$ ~/Code/oss/php/php-5.4.0RC1/sapi/cli/php -v PHP 5.4.0RC1 (cli) (built: Nov 11 2011 19:53:40) Copyright (c) 1997-2011 The PHP Group Zend Engine v2.4.0, Copyright (c) 1998-2011 Zend Technologies localhost:test dzuelke$ ~/Code/oss/php/php-5.4.0RC1/sapi/cli/php -r 'get_magic_quotes_gpc();' PHP Deprecated: Function get_magic_quotes_gpc() is deprecated in Command line code on line 1 Bug report is up at https://bugs.php.net/bug.php?id=55371, I've attached a patch to the ticket and this email that fixes the problem, test included. - David -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] get_magic_quotes_gpc() throws deprecated warning in 5.4
Had a few other tests failing, updated those accordingly and attached a newer version. David On 12.11.2011, at 12:06, David Zülke wrote: I looked through the mailing list archives, and in several threads the consensus seemed to be that the setters should throw a warning, but the getters should not... localhost:test dzuelke$ ~/Code/oss/php/php-5.4.0RC1/sapi/cli/php -v PHP 5.4.0RC1 (cli) (built: Nov 11 2011 19:53:40) Copyright (c) 1997-2011 The PHP Group Zend Engine v2.4.0, Copyright (c) 1998-2011 Zend Technologies localhost:test dzuelke$ ~/Code/oss/php/php-5.4.0RC1/sapi/cli/php -r 'get_magic_quotes_gpc();' PHP Deprecated: Function get_magic_quotes_gpc() is deprecated in Command line code on line 1 Bug report is up at https://bugs.php.net/bug.php?id=55371, I've attached a patch to the ticket and this email that fixes the problem, test included. - David -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] Time zone database shut down by legal threat
FYI: http://blog.joda.org/2011/10/today-time-zone-database-was-closed.html This could impact PHP as well since it bundles the database. David P.S. I hope Google/IBM/Oracle/whoever just buys those guys and then fires everyone. -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Improvements to HTTP stream metadata
On 01.07.2011, at 01:29, Stas Malyshev wrote: Hi! On 6/30/11 2:34 PM, Michael Maclean wrote: The same data also ends up in the bizarre $http_response_headers var that gets spontaneously created in local scope - I've wondered about how good that is to do. This thing is indeed bizzare. I wonder if anybody uses it and why it was done this way... I've used it before... IIRC, it was because that var gets set on older PHP versions even if the HTTP response is an error (in which case the stream is destroyed and you can't get the metadata anymore either; newer versions have the ignore_errors context option for that). David smime.p7s Description: S/MIME cryptographic signature
Re: [PHP-DEV] Fix for #53727 (is_subclass_of resolution with interfaces)
On 29.06.2011, at 21:39, Ralph Schindler wrote:
interface A {}
class B implements A {}
class C extends B {}
var_dump(is_subclass_of('B', 'A')); // true
Typo there; that should be 'C', not 'B'.
David
smime.p7s
Description: S/MIME cryptographic signature
Re: [PHP-DEV] Fix for #53727 (is_subclass_of resolution with interfaces)
On 29.06.2011, at 22:20, Paul Dragoonis wrote: On Wed, Jun 29, 2011 at 8:49 PM, Ralph Schindler ra...@smashlabs.com wrote: Correct. I was hasty in that example, the first was copied tested (and is reflected in the test, as is that variation of what I wrote up.) Either way, test and patch work in 5_3. Doesn't this functionality confuse matters? If this patch is added, is there now no difference between instanceof and is_subclass_of(). If this is the case my question is then why do we have two methods to do the same thing? I thought instanceof was for parent classes + interfaces.. and is_subclass_of() was just for parent classes. instanceof is a language construct and only operates on object instances. David smime.p7s Description: S/MIME cryptographic signature
Re: [PHP-DEV] Fix for #53727 (is_subclass_of resolution with interfaces)
On 29.06.2011, at 23:05, Martin Scotta wrote: are you kidding, right? $class = 'stdClass'; $instance = new $class; var_dump( $instance instanceof $class ); That still only works on instances. Not on class names. Which this dicussion is about. David smime.p7s Description: S/MIME cryptographic signature
Re: [PHP-DEV] [PATCH] Friendly log messages for CLI server
On 29.06.2011, at 01:19, Johannes Schlüter wrote: On Tue, 2011-06-28 at 23:37 +0100, Arpad Ray wrote: - Colours messages according to their response code (success=green, client error=yellow, server error=red) I would prefer if this would be an ini option (if (cli_web_server.color isatty) color = true) default can be on, but I've seen cases where such magic failed and created hard-to use results (due to control sequences in log files or such). The code could detect if it's outputting to a TTY or not and only use color codes if the output isn't redirected somewhere else. David smime.p7s Description: S/MIME cryptographic signature
Re: [PHP-DEV] bugs.php.net status and plan(s)
On 28.06.2011, at 23:17, Pierre Joye wrote: A significant change is that now bugs.php.net is only available via https://bugs.php.net. May I suggest that the interface doesn't redirect to https:// by default? http:// plays much nicer with proxies, and browsers cache resources to disk, which is helpful not only on slow connections :) The bug report form and anything else that transmits a password or similar could of course still be done via https://. If the current web interface doesn't allow this, I'd be happy to help with adding that feature. David smime.p7s Description: S/MIME cryptographic signature
Re: [PHP-DEV] todo: crypt_blowfish issue
On 27.06.2011, at 01:55, Stas Malyshev wrote: However, it still has a chance somebody's data won't work after the update if he had 8-bit data hashed with old crypt(). He would need either to re-hash or to change prefix from $2a to $2x. IMO that's a fair trade-off; people could even implement this in their app code by replacing $2a with $2x for a transitional period in the hash if the comparison fails (and then simply re-hash the password again with $2a so it's secure). I'm volunteering to write the necessary code sample for the upgrading notes :p David smime.p7s Description: S/MIME cryptographic signature
Re: [PHP-DEV] todo: crypt_blowfish issue
On 28.06.2011, at 14:26, Johannes Schlüter wrote: On Tue, 2011-06-28 at 12:19 +0200, David Zülke wrote: On 27.06.2011, at 01:55, Stas Malyshev wrote: However, it still has a chance somebody's data won't work after the update if he had 8-bit data hashed with old crypt(). He would need either to re-hash or to change prefix from $2a to $2x. IMO that's a fair trade-off; people could even implement this in their app code by replacing $2a with $2x for a transitional period in the hash if the comparison fails (and then simply re-hash the password again with $2a so it's secure). I'm volunteering to write the necessary code sample for the upgrading notes :p if people read it ... what might happen is that people test when upgrading (yay!) all tests and all work and then 1% of the users or so can't login anymore (with an european site for instance where 8bit characters might happen ...) That might happen, but it isn't a critical issue I think since the change does not produce unconsumable hashes or silently corrupt data in some other way. I think you're also overestimating the amount of people using bcrypt for password storage; most people unfortunately still use SHA1s (with or without a salt). As Stas said though, whatever the upstream implementation uses as a solution should be mirrored by PHP. The alternative would be to introduce a new hash algorithm code that only works in newer versions of PHP, which hurts portability (which is the major selling point of crypt()). Simply breaking old hashes (there's not gonna be many of them out there) with the ability to easily and transparently fix it without user interaction in userland code seems like a much better idea to me. David smime.p7s Description: S/MIME cryptographic signature
Re: [PHP-DEV] Callable type
He means
function foo(callback derp = array('MyClass', 'ohai')) { ... }
David
On 08.06.2011, at 15:31, Anthony Ferrara wrote:
No default values, other then NULL allowed.
Otherwise we would need to support array(classname, methodname)
too, and then people would want default array values for array
typehinting etc etc etc.
Unless I mis-read what you said, we already have default array values
for array type-hinting:
function foo(array $array = array('bar', 'baz')) {
var_dump($array);
}
foo();
foo(array());
Works perfectly for me on 5.3.6...
2011/6/8 Hannes Magnusson hannes.magnus...@gmail.com:
2011/6/8 Johannes Schlüter johan...@schlueters.de:
On Tue, 2011-06-07 at 12:12 -0700, Stas Malyshev wrote:
Hi!
https://wiki.php.net/rfc/callable
It is good there's an RFC. However it seems to lack code examples. I
understand it may be obvious to the proposers how it looks like, but
it'd be nice to have the actual example there as it is done nearly
everywhere else.
The RFC is missing information about what happens in codebases which
already have a callable type declared. Will that be prevented or will
they hit a runtime error? (callable expected, callable type found)
You mean an interface/class with that name?
The error would be 'expected instanceof callable, string/array/closure
recieved.
gettype(strpos) will still return a string, not callable.
A callable wouldn't be fully featured type.
What about default values? Will
function foo(callback $cb = 'strpos') { }
be valid?
No default values, other then NULL allowed.
Otherwise we would need to support array(classname, methodname)
too, and then people would want default array values for array
typehinting etc etc etc.
The information on reflection is limited. what shall
Reflection::Parameter::getTypehint() return? Will that method allow to
differ between a class type and this magic?
There is no such method anymore :)
What about ARGINFO? Will internal functions be able to define this type
via ARGINFO? How will this be reported in `php --rf function`?
I didn't include arginfo in the patch, but good point. It should
probably be included.
As Felipe pointed out, ext/reflection hasn't been updated.
It should return [ callable $foobar ], just like with any other typehint
-Hannes
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
smime.p7s
Description: S/MIME cryptographic signature
Re: [PHP-DEV] Trying to find out where the memory went
Please test the exact thing I suggested :) var_dump(memory_get_usage()); token_get_all(file_get_contents(FILE)); gc_collect_cycles(); var_dump(memory_get_usage()); memory_get_peak_usage() is irrelevant, and USE_ZEND_ALLOC won't give accurate results anymore when looking at memory usage. If the above gives the same numbers you got initially, then there's a memleak in token_get_all(). David On 06.06.2011, at 22:30, Mike van Riel wrote: David and Pauli, When I change the test script to: var_dump(memory_get_peak_usage()); gc_collect_cycles(); token_get_all(file_get_contents(FILE)); gc_collect_cycles(); var_dump(memory_get_peak_usage()); And execute the following bash line preceding: export USE_ZEND_ALLOC=0 I get the following output: int(8240) int(8240) When I remove the gc_collect_cycles I get the same result. Even assigning the results to a variable do not increase the peak memory. FYI: When I change the argument of memory_get_peak_usage to 'true', I get the following results: int(262144) int(262144) This amount is astoundingly less than the previous conclusions and less than my own calculations would show. Of course this leads me to the following questions: 1. Does it hurt to disable the Zend MM? 2. Can it be done from inside a PHP Script? 3. Why is the memory consumption so much lower, even lower than my calculations? I assume it is a good thing to at least try to create an easy way to reproduce the issue (cannot include my test file) and create a bug report about this :) Thank you for your assistance thus far. Mike On Sun, 5 Jun 2011 15:36:43 +0200, Julien Pauli wrote: Seems like leak. Try disabling ZendMM to see if something noticeable happens (memory peak should be lower). USE_ZEND_ALLOC=0 Cheers, Julien On Sun, Jun 5, 2011 at 2:01 PM, David Zülke david.zue...@bitextender.com wrote: Smells like a memory leak if gc_collect_cycles() doesn't fix it. David -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php smime.p7s Description: S/MIME cryptographic signature
Re: [PHP-DEV] Trying to find out where the memory went
Damn I'm an idiot. I meant memory_get_usage() all along. Sorry Mike. Then it'll
make sense... memory_get_usage(), but a gc_collect_cycles() before the second
call.
So, my first email should have had this code in it:
var_dump(memory_get_usage());
token_get_all(file_get_contents('PATH'));
var_dump(memory_get_usage());
And then, a comparison to this would be useful:
var_dump(memory_get_usage());
token_get_all(file_get_contents('PATH'));
gc_collect_cycles();
var_dump(memory_get_usage());
David
On 07.06.2011, at 16:34, Ferenc Kovacs wrote:
On Tue, Jun 7, 2011 at 4:28 PM, David Zülke
david.zue...@bitextender.comwrote:
Please test the exact thing I suggested :)
AFAIK he did.
int(640720)
int(244001144)
except if you suggested something else off-list.
Tyrael
smime.p7s
Description: S/MIME cryptographic signature
Re: [PHP-DEV] Trying to find out where the memory went
One thing to keep in mind of course is that each zval incurs an overhead. $x =
1; requires 144 bytes of memory in total IIRC.
David
On 04.06.2011, at 23:38, Mike van Riel wrote:
Dear Internals,
During development of DocBlox I encountered a (for me) unusual situation
with regards to memory usage.
I hope you can shed some light on this for me as I do not understand.
The situations is as follows:
I have a php file containing about 53 KLOC (including whitespace and
comments), which is about 2.1MB in size. When I execute the
memory_get_peak_usage after running the token_get_all method on its
content it reports that 232MB of RAM have been used in the process.
I am having trouble understanding how 244003984B (232MB) RAM could be
used.
The following is what I have calculated:
* 640.952B to start with (measured);
* 2.1MB to load the file contents into memory using file_get_contents
* 68 bytes for the resulting array
* 68 bytes for each child array representing a token
* 68 bytes for each element in a token array (which can be either 1 or
3, depending whether it is actually a token or literal)
* 2.1MB in total for the string contents of the token literals /
contents (equivalent to the byte size of the file)
I have used the count method to retrieve the number of tokens (276697)
and come to the following sum (everything is retrieved and calculated in
bytes):
640952+2165950+68+(276697*68)+(276697*3*68)+2165950=80234436 = 76M
This is a worst case formula where I assume that every token in the
array consists of 3 elements.
Based on this calculation I would be missing 156MB of memory; anybody
know where that went?
I used the following snippet of code for my tests:
var_dump(memory_get_peak_usage());
$tokens = token_get_all(file_get_contents('PATH'));
var_dump(count($tokens));
var_dump(memory_get_peak_usage());
I hope this mail did not scare anyone ;)
Kind regards,
Mike van Riel
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
smime.p7s
Description: S/MIME cryptographic signature
Re: [PHP-DEV] Trying to find out where the memory went
memory_get_peak_usage() is the maximum amount of memory used by the VM of PHP (but not by some extensions for instance) up until the point where that function is called. So the actual memory usage may be even higher IIRC. But yeah, you're basically right. I've explained in another message why it might be so much more than you expected (zval overhead, basically) David On 07.06.2011, at 19:44, Mike van Riel wrote: I have ran the script that you provided and got the following results: int(635192) int(635944) Which is far less than the peak memory result. I use memory_get_peak_usage to measure what the worst case memory output is in my application. I expect this to be the actual memory used (and thus when the server starts swapping if this number exceeds the physical memory). Is my assertion about the meaning of memory_get_peak_usage incorrect? Mike On Tue, 2011-06-07 at 16:28 +0200, David Zülke wrote: Please test the exact thing I suggested :) var_dump(memory_get_usage()); token_get_all(file_get_contents(FILE)); gc_collect_cycles(); var_dump(memory_get_usage()); memory_get_peak_usage() is irrelevant, and USE_ZEND_ALLOC won't give accurate results anymore when looking at memory usage. If the above gives the same numbers you got initially, then there's a memleak in token_get_all(). David On 06.06.2011, at 22:30, Mike van Riel wrote: David and Pauli, When I change the test script to: var_dump(memory_get_peak_usage()); gc_collect_cycles(); token_get_all(file_get_contents(FILE)); gc_collect_cycles(); var_dump(memory_get_peak_usage()); And execute the following bash line preceding: export USE_ZEND_ALLOC=0 I get the following output: int(8240) int(8240) When I remove the gc_collect_cycles I get the same result. Even assigning the results to a variable do not increase the peak memory. FYI: When I change the argument of memory_get_peak_usage to 'true', I get the following results: int(262144) int(262144) This amount is astoundingly less than the previous conclusions and less than my own calculations would show. Of course this leads me to the following questions: 1. Does it hurt to disable the Zend MM? 2. Can it be done from inside a PHP Script? 3. Why is the memory consumption so much lower, even lower than my calculations? I assume it is a good thing to at least try to create an easy way to reproduce the issue (cannot include my test file) and create a bug report about this :) Thank you for your assistance thus far. Mike On Sun, 5 Jun 2011 15:36:43 +0200, Julien Pauli wrote: Seems like leak. Try disabling ZendMM to see if something noticeable happens (memory peak should be lower). USE_ZEND_ALLOC=0 Cheers, Julien On Sun, Jun 5, 2011 at 2:01 PM, David Zülke david.zue...@bitextender.com wrote: Smells like a memory leak if gc_collect_cycles() doesn't fix it. David -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php smime.p7s Description: S/MIME cryptographic signature
Re: [PHP-DEV] Trying to find out where the memory went
144 (not 114!) bytes is for an integer; I'm not quite sure what the overheads are for arrays, which token_get_all() produces in abundance :) An empty array seems to occupy 312 bytes of memory. Also, strings have memory allocated in 8 byte increments as far as I know, so 1 eats up 8 bytes, and 12345678901234567 will consume 24 bytes for the raw text, not 17. David On 07.06.2011, at 20:26, Mike van Riel wrote: Am i then also correct to assume that the output of memory_get_peak_usage is used for determining the memory_limit? Also: after correcting with your new information (zval = 114 bytes instead of 68) I still have a rather large offset: 640952+2165950+114+(276697*114)+(276697*3*114)+2165950 = 131146798 = 125M (not trying to be picky here; I just don't understand) _If_ my calculations are correct then a zval should be approx 216 bytes (excluding string contents): ((24400-640952-2165950-2165950) / 4) / 276697 = 215.9647B Mike On Tue, 2011-06-07 at 19:50 +0200, David Zülke wrote: memory_get_peak_usage() is the maximum amount of memory used by the VM of PHP (but not by some extensions for instance) up until the point where that function is called. So the actual memory usage may be even higher IIRC. But yeah, you're basically right. I've explained in another message why it might be so much more than you expected (zval overhead, basically) David smime.p7s Description: S/MIME cryptographic signature
Re: [PHP-DEV] Callable typehint
On 07.06.2011, at 12:09, Jordi Boggiano wrote:
On Tue, Jun 7, 2011 at 1:02 AM, Stas Malyshev smalys...@sugarcrm.com wrote:
Sure. How about reducing boilterplate code like this:
if(is_readable($foo)) {
$var = file_get_contents($foo);
} else {
throw InvalidArgumentException();
}
Why won't we make language construct to do that too? I don't think these
things belong in the language syntax.
The whole point is that callables are generally not constructed from
user input, they're hardcoded in the code somewhere, and so if a fatal
error occurs, the developer notices it, hopefully during development.
With is_readable, a file can be anywhere, anytime, readable or not, it
depends on the environment the code runs on, and not on the code
itself, so it's not deterministic and you should therefore be able to
easily handle this gracefully.
Precisely.
I'd love to see a callable type hint too. And a scalar one while we're at
it ;)
David
smime.p7s
Description: S/MIME cryptographic signature
Re: [PHP-DEV] Callable type
On 07.06.2011, at 21:12, Stas Malyshev wrote: Hi! https://wiki.php.net/rfc/callable Note also that this pseudo-type is called callback in all of our documentation, which means we have now documentation that says: bool array_walk ( array $array , callback $funcname [, mixed $userdata ] ) and type check that says callable. Oh, good point. It should be callback then, too, maybe? Or the documentation should be adjusted (which might be a good idea, as $funcname doesn't reflect the realities anymore). David smime.p7s Description: S/MIME cryptographic signature
Re: [PHP-DEV] Callable type
On 07.06.2011, at 22:31, Stas Malyshev wrote: Hi! callback is callable, the opposite could not be true. a string --or a closure-- is callable, but the string is not a callback According to our docs, which were out there for years, it is. One of the main and widespread complaints about PHP is the lack of any system in naming, design and documentation, it is sad to see how many people want to make it worse instead of making it better +1. I'm thinking it should be callback, or the docs should be adjusted. callable arguably does make more sense, but either way, it needs to be consistent, that's what matters most. David smime.p7s Description: S/MIME cryptographic signature
Re: [PHP-DEV] Callable type
On 08.06.2011, at 00:38, dukeofgaming wrote: On Tue, Jun 7, 2011 at 4:41 PM, Matthew Weier O'Phinney weierophin...@php.net wrote: On 2011-06-07, dukeofgaming dukeofgam...@gmail.com wrote: +1 for callable, it is really more consistent. I was actually agreeing With David and Stas that callback was more consistent, and casting my vote for that. Oh. But then, shouldn't is_callable be deprecated for a more consistently named is_callback? No, because is_callable() also performs visibility checks. Which of course begs the question... should the type hint do the same? David smime.p7s Description: S/MIME cryptographic signature
Re: [PHP-DEV] RFC: Short syntax for Arrays (redux)
On 04.06.2011, at 02:43, John Crenshaw wrote:
This is a moot point. You wouldn't send that to json_decode. You would send
it to json_encode. In other words json_decode({yay: ä}) is totally wrong
in the first place, because json_decode requires a string, not an object.
Just to quickly make another point... you couldn't necessarily send this
native JSON construct you and others dream about to json_encode() just like
that either, since json_encode() too only accepts UTF-8 encoded input.
So if you have a latin1-encoded file (still the default in Eclipse on Windows,
AFAIK) containing this:
var_dump(json_encode({foo: ä}));
Then you'll end up with
string(12) {foo:null}
Which is of course totally consistent with what happens when you do:
var_dump(json_encode(array(foo = ä)));
But try to explain *that* to the average user who doesn't even know what a
character encoding is.
It's just a totally bad idea. PHP is a language where a good number of people
still ask questions like how do I open a new browser window without an address
bar in PHP on forums. And now you want to throw yet another language construct
at them that looks like JSON, but doesn't necessarily behave like it even when
used with PHP's own JSON functionality, and does not offer any benefit
whatsoever other than the ability to copy and paste array and object
declarations between PHP and JS code.
David
smime.p7s
Description: S/MIME cryptographic signature
Re: [PHP-DEV] $arr = array('Hello', 'world'); $arr();
3
David
On 05.06.2011, at 17:52, Felipe Pena wrote:
Hi all,
Reading our bug tracker I noticed a good feature request [1] from 2009 which
points to an interesting feature that I think makes sense for us, since we
are now working with $f() using objects and strings, and the array('class',
'method') is an old known for call_user_func()-like functions.
So, I wrote a patch [2] that allow such behavior to be consistent with
arrays. See some examples:
class Hello {
public function world($x) {
echo Hello, $x\n; return $this;
}
}
$f = array('Hello','world');
var_dump($f('you'));
$f = array(new Hello, 'foo');
$f();
All such calls match with the call_user_func() behavior related to magic
methods, static non-static methods.
The array to be a valid callback should be a 2-element array, and it must be
for the first element object/string and for the second string only. (just
like our zend_is_callable() check and opcodes related to init call)
Any thoughts?
[1] - http://bugs.php.net/bug.php?id=47160
[2] - http://felipe.ath.cx/diff/fr47160.diff
phpt: http://felipe.ath.cx/diff/fr47160.phpt
--
Regards,
Felipe Pena
smime.p7s
Description: S/MIME cryptographic signature
Re: [PHP-DEV] RFC: Short syntax for Arrays (redux)
On 06.06.2011, at 20:03, John Crenshaw wrote: The desire is to be able to copy/paste things back and forth and make it work with only minor tweaks. That sounds like a problem an IDE should solve, and not the language itself. And again... there are potential encoding problems, plus single versus double quotes, trailing commas, and so forth. David smime.p7s Description: S/MIME cryptographic signature
Re: [PHP-DEV] Trying to find out where the memory went
Smells like a memory leak if gc_collect_cycles() doesn't fix it.
David
On 05.06.2011, at 00:01, Mike van Riel wrote:
Hey David,
That gives me the following output:
int(640720)
int(244001144)
Mike
On Sat, 2011-06-04 at 23:51 +0200, David Zülke wrote:
What does
var_dump(memory_get_peak_usage());
token_get_all(file_get_contents('PATH'));
var_dump(memory_get_peak_usage());
get you?
David
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
smime.p7s
Description: S/MIME cryptographic signature
Re: [PHP-DEV] JSON array/object syntax
To clarify: I don't understand what the advantage would be, either. It seems
that those demanding it somehow confuse or blur the lines between the
declaration of data in the language and its representation in a serialization
format. A few people in the thread demanded that it be a syntax that could also
be consumed by all the JSON parsers out there, and I have no idea how that
would be useful at all, since the construct per se isn't useful at all as PHP
code and at least needs to be wrapped in ?php and ? tags, so you couldn't
just evaluate it as JavaScript (which would be useless without assignment etc).
I ignored that aspect as others covered it already (e.g. Pierre asking what the
point was of this at all) and focused on the encoding issue that *would* occur
if someone, somehow managed to find a useful way of taking advantage of such a
notation (e.g. where it would be interchangeable with JS code or be evaluated
as JSON by other JSON parsers) - namely the problem that you could produce *PHP
code*, that, with some mingling and stripping, *PHP's own json_decode() could
not process*.
Perhaps I should have made that more clear, sorry.
David
On 04.06.2011, at 03:17, dukeofgaming wrote:
Hi,
After reading all the debate in the other thread it is still not clear to me
what the real advantages are of adopting JSON syntax for native PHP
types. Doing json_encode to an object and expect the code and output to be
the same seems useless to me, and reading David Zülke's example it seems
more like a pure-unicode issue to me:
It is different from writing json_decode('ä\u0123'), because json_decode()
in PHP only accepts UTF-8 encoded input;
Give it a shot:
?php
$chr = \xC3\xA4; // ä as UTF-8
var_dump(json_decode('[' . $chr . '\u00e4]'));
var_dump(json_decode('[' . utf8_decode($chr) . '\u00e4]'));
?
That'll produce:
array(1) {
[0]=
string(4) ää
}
NULL
Understand what the problem is now?
If someone does this in a latin1-encoded file:
?php $fancyNewArray = {yay: ä}; ?
Then that is valid as a PHP array (as it's a latin1 ä, so \xE4), but
cannot be consumed by PHP's json_decode(). And that would be terribly
inconsistent behavior.
-
It looks more like you want to do json_decode to PHP code hoping that will
somehow fix json_decode... instead of fixing json_decode.
Could someone advocating this please explain with use-cases and concrete
punctualized examples the advantages of having such JSON approach to PHP.
Regards,
David Vega
smime.p7s
Description: S/MIME cryptographic signature
Re: [PHP-DEV] [PATCH] Notice on array to string convertion
I think for consistency's sake it should be a notice as the same is already done in _convert_to_string(). In fact, couldn't zend_make_printable_zval() use _convert_to_string()? - David On 03.06.2011, at 09:57, Derick Rethans wrote: On Thu, 2 Jun 2011, Ilia Alshanetsky wrote: I like the idea of an error message when this happens, but as few other people in the thread had mentioned, I think it should be a warning (E_WARNING) because the conversion results in data loss (content of the array is replaced with Array string). Yup, E_WARNING sounds best to me too. Derick -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php smime.p7s Description: S/MIME cryptographic signature
Re: [PHP-DEV] Trying to find out where the memory went
What does
var_dump(memory_get_peak_usage());
token_get_all(file_get_contents('PATH'));
var_dump(memory_get_peak_usage());
get you?
David
On 04.06.2011, at 23:38, Mike van Riel wrote:
Dear Internals,
During development of DocBlox I encountered a (for me) unusual situation
with regards to memory usage.
I hope you can shed some light on this for me as I do not understand.
The situations is as follows:
I have a php file containing about 53 KLOC (including whitespace and
comments), which is about 2.1MB in size. When I execute the
memory_get_peak_usage after running the token_get_all method on its
content it reports that 232MB of RAM have been used in the process.
I am having trouble understanding how 244003984B (232MB) RAM could be
used.
The following is what I have calculated:
* 640.952B to start with (measured);
* 2.1MB to load the file contents into memory using file_get_contents
* 68 bytes for the resulting array
* 68 bytes for each child array representing a token
* 68 bytes for each element in a token array (which can be either 1 or
3, depending whether it is actually a token or literal)
* 2.1MB in total for the string contents of the token literals /
contents (equivalent to the byte size of the file)
I have used the count method to retrieve the number of tokens (276697)
and come to the following sum (everything is retrieved and calculated in
bytes):
640952+2165950+68+(276697*68)+(276697*3*68)+2165950=80234436 = 76M
This is a worst case formula where I assume that every token in the
array consists of 3 elements.
Based on this calculation I would be missing 156MB of memory; anybody
know where that went?
I used the following snippet of code for my tests:
var_dump(memory_get_peak_usage());
$tokens = token_get_all(file_get_contents('PATH'));
var_dump(count($tokens));
var_dump(memory_get_peak_usage());
I hope this mail did not scare anyone ;)
Kind regards,
Mike van Riel
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
smime.p7s
Description: S/MIME cryptographic signature
Re: [PHP-DEV] RFC: Short syntax for Arrays (redux)
It's not FUD.
It is different from writing json_decode('ä\u0123'), because json_decode() in
PHP only accepts UTF-8 encoded input;
Give it a shot:
?php
$chr = \xC3\xA4; // ä as UTF-8
var_dump(json_decode('[' . $chr . '\u00e4]'));
var_dump(json_decode('[' . utf8_decode($chr) . '\u00e4]'));
?
That'll produce:
array(1) {
[0]=
string(4) ää
}
NULL
Understand what the problem is now?
If someone does this in a latin1-encoded file:
?php $fancyNewArray = {yay: ä}; ?
Then that is valid as a PHP array (as it's a latin1 ä, so \xE4), but cannot
be consumed by PHP's json_decode(). And that would be terribly inconsistent
behavior.
David
On 02.06.2011, at 22:15, Andrei Zmievski wrote:
Stop spreading FUD, please.
It's no different than writing json_decode(ä\u0123).
Your statement, the stuff in bar in UTF-8 is wrong. The \u0123
escape sequence is a representation of a Unicode character, not the
character itself. This representation can be encoded in any
ASCII-compatible encoding, such as Latin-1, UTF-8, etc. So putting it
directly in a Latin-1 encoded script is just fine.
-Andrei
On Thu, Jun 2, 2011 at 12:00 PM, David Zülke
david.zue...@bitextender.com wrote:
No we can't; I already explained why in another email last night. Copypasta:
json_decode() can deal with Unicode sequences because decodes to UTF-8. That
is not possible in a language construct:
What if I do this, in a latin1 encoded file:
$x = {foo: ä, bar: \u0123}
Should that then give mixed encodings? The ä in foo in latin1 and the
stuff in bar in UTF-8?
And what if I do:
$x = {foo: ä\u0123}
I'll either end up with an invalid UTF-8 sequence, or with latin1 character
soup.
David
On 02.06.2011, at 18:04, Martin Scotta martinsco...@gmail.com wrote:
Could we first go out with fully JSON compatible version for 5.4?
and then later decide the = stuff based on how that worked.
Native JSON is a big stuff for userland, and I'm pretty sure it will bring a
hole of core version upgrades.
Martin Scotta
On Wed, Jun 1, 2011 at 7:09 PM, Sean Coates s...@seancoates.com wrote:
Now, the only reason I would personally support the array shortcut is
if it was an implementation of JSON. I know that's not on the table
here
I don't think anything is officially off the table, unless we forego
discussion.
My application is largely JSON-powered. We pass data from back- to
front-end via JSON, we interact with MongoDB via the extension (which is an
altered JSON-like protocol (arrays instead of objects), but would be a lot
more fluent with actual objects—they're just too hard to make in current
PHP), and we interface with ElasticSearch. The paste I linked earlier is
our
primary ElasticSearch query.
The benefits of first-class JSON are important and wide-reaching;
especially when interacting with systems like the ones I've mentioned.
There's a huge amount of value in being able to copy JSON out of PHP and
into e.g. CURL to make a query to ElasticSearch without worrying that I've
accidentally nested one level too deep or shallow, or accidentally
mistranslating my arrays into JSON.
This is not about saving five characters every time I type array(), it's
about making my systems all work together in a way that's a little less
abstracted, and a lot less prone to error.
S
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
smime.p7s
Description: S/MIME cryptographic signature
Re: [PHP-DEV] DOMNode::getAttribute()
On 03.06.2011, at 22:38, Matt Pelmear wrote: Hello, I discovered today that the DOMNode::getAttribute() function (which is undocumented on the php site) It's DOMElement::getAttribute()... returns an empty string if the requested attribute doesn't exist in the node. Yes, but that's in line with the W3C DOM spec! David smime.p7s Description: S/MIME cryptographic signature
Re: [PHP-DEV] RFC: Short syntax for Arrays (redux)
No we can't; I already explained why in another email last night. Copypasta:
json_decode() can deal with Unicode sequences because decodes to UTF-8. That is
not possible in a language construct:
What if I do this, in a latin1 encoded file:
$x = {foo: ä, bar: \u0123}
Should that then give mixed encodings? The ä in foo in latin1 and the stuff
in bar in UTF-8?
And what if I do:
$x = {foo: ä\u0123}
I'll either end up with an invalid UTF-8 sequence, or with latin1 character
soup.
David
On 02.06.2011, at 18:04, Martin Scotta martinsco...@gmail.com wrote:
Could we first go out with fully JSON compatible version for 5.4?
and then later decide the = stuff based on how that worked.
Native JSON is a big stuff for userland, and I'm pretty sure it will bring a
hole of core version upgrades.
Martin Scotta
On Wed, Jun 1, 2011 at 7:09 PM, Sean Coates s...@seancoates.com wrote:
Now, the only reason I would personally support the array shortcut is
if it was an implementation of JSON. I know that's not on the table
here
I don't think anything is officially off the table, unless we forego
discussion.
My application is largely JSON-powered. We pass data from back- to
front-end via JSON, we interact with MongoDB via the extension (which is an
altered JSON-like protocol (arrays instead of objects), but would be a lot
more fluent with actual objects—they're just too hard to make in current
PHP), and we interface with ElasticSearch. The paste I linked earlier is our
primary ElasticSearch query.
The benefits of first-class JSON are important and wide-reaching;
especially when interacting with systems like the ones I've mentioned.
There's a huge amount of value in being able to copy JSON out of PHP and
into e.g. CURL to make a query to ElasticSearch without worrying that I've
accidentally nested one level too deep or shallow, or accidentally
mistranslating my arrays into JSON.
This is not about saving five characters every time I type array(), it's
about making my systems all work together in a way that's a little less
abstracted, and a lot less prone to error.
S
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] RFC: Short syntax for Arrays (redux)
Just because the MongoDB developers were stupid enough to build a query
language on top of JSON does not mean that JSON or JavaScript object literals
need to be supported in PHP. And it wouldn't be possible anyway since JSON
allows Unicode escape sequences, and PHP cannot even represent those as it is
not aware of runtime encodings.
Besides, outside the use case of json_decode(), stdClass is rarely ever useful,
so I don't understand why we're even discussing {} shorthands here. It's not in
the RFC either, so good job on focusing on the issue and not diluting the
discussion.
Getting back to the RFC: I think it's problematic to have two separate syntaxes
for the key/value separator. For consistency's sake, I'd rather just have =
but not :. Just my $0.02.
David
On 02.06.2011, at 00:09, John Crenshaw wrote:
For small linear arrays, neither format is more readable but for even
mildly complex structures, there is a clear difference. Consider the
following Mongo query:
$query = array(
'time'=array('$and'=array(
array('$gt'=strtotime('-1 day')),
array('$lt'=time()),
)),
'$or'=array(
array('foo'='bar'),
array('hello'='world')
)
);
Vs. the JSON form:
$query = {
time: {'$and': [
{'$gt': strtotime('-1 day')},
{'$lt': time()},
]},
'$or': [
{foo: 'bar'},
{hello: 'world'}
]
};
Because of the clear readability difference I'll take anything, but JSON
would be much better than just an array shorthand.
John Crenshaw
Priacta, Inc.
-Original Message-
From: Anthony Ferrara [mailto:ircmax...@gmail.com]
Sent: Wednesday, June 01, 2011 5:18 PM
To: PHP internals
Subject: Re: [PHP-DEV] RFC: Short syntax for Arrays (redux)
Personally, I think focusing on a character savings is the wrong
reason to take on any problem. I don't care how long it takes for me
to type code. I don't care how much extra hdd space it takes. But
what I do care about is how readable it is.
To me, the array shortcut syntax is pointless. Do you really mean to
tell me that `[1, 2]` is more readable/easier to understand than
`array(1,2)`? To me, it's about a wash.
However, the object shortcut syntax is a major win. For example:
$person = new stdClass();
$person-city = 'ogden';
$person-state = 'ut';
$perspn-country = 'usa';
$person-favoriteNumbers = array(4, 12, 37, 42);
$person-somethingWithNumbers();
$person-unluckyNumbers = array(6, 13, 21);
$person-likesPhp = 'very much so';
vs
$person = { 'name' = 'Justin',
'city' = 'ogden',
'state' = 'ut',
'country' = 'usa',
'favoriteNumbers' = [ 4, 12, 37, 42],
'unluckyNumbers' = [ 6, 13, 21],
'likesPhp' = 'very much so'
}
Did you notice what happened there? There's two differences. Try to
find them. Neither would be possible with the shortcut syntax.
Now, the only reason I would personally support the array shortcut is
if it was an implementation of JSON. I know that's not on the table
here, but that's the only benefit I can see to implementing a shortcut
for arrays (that would save 5 characters per instance).
Just my $0.02...
Anthony
On Wed, Jun 1, 2011 at 5:02 PM, Justin Carmony jus...@justincarmony.com
wrote:
To address the soapbox:
Its not just to reduce the five characters at the beginning, but when you
have more complex structures as well. There was already a great example
shown (http://paste.roguecoders.com/p/0747f2363c228a09e0ddd6f8ec52f2e8.html)
of that. Also, if object support is added (which we need to add to the RFC),
you can cut down on a lot more verbose code, especially with objects.
$person = { 'name' = 'Justin',
'city' = 'ogden',
'state' = 'ut',
'country' = 'usa',
'favoriteNumbers' = [ 4, 12, 37, 42],
'unluckyNumbers' = [ 6, 13, 21],
'likesPhp' = 'very much so'
};
Characters: 192
Current way:
$person = new stdClass();
$person-city = 'ogden';
$person-state = 'ut';
$person-country = 'usa';
$person-favoriteNumbers = array(4, 12, 37, 42);
$person-unluckyNumbers = array(6, 13, 21);
$person-likesPhp = 'very much so';
Characters: 229
That is a 37 character difference. But the real driving factor is given
PHP's lack of named parameter syntax, passing objects and arrays (or
sometimes a mix, depending on the framework) is becoming very popular. So
not only do you save some typing just once, but if you use this pattern a
lot, you save a lot of typing over your entire project. Also, when dealing
with objects, I have to make sure I retype person correctly each time. If
I don't, I'll get a notice error. But with the new syntax, it'll throw a
parsing error so I can know a lot quicker what my issue is.
As for syntax highlighters, IDEs, books, etc all being outdated, first off
no one is suggesting to deprecate the array() function. So you will only use
this new syntax if you choose to do so. Second, we broke syntax
Re: [PHP-DEV] RFC: Short syntax for Arrays (redux)
On 02.06.2011, at 00:53, Marcel Esser wrote:
Hrm. It seems to me that it's not just Mongo that has chosen that as a
query definition language. A fair number of other projects have, too. If
not as a query language, then related things.
It's the worst idea of this decade, and just because others have repeated it,
it's not automatically a good one. {foo: 1, bar: 1} works fine, so they
implemented that, and then they realized that they had to do ORs as well, so
they invented $or and a whole bunch of other workarounds.
As for decoding Unicode, well, json_decode seems to do a pretty good job.
And if I am not mistaken, they are always in quotation marks, so it
shouldn't really be such a terrible issue to delimit as such. I am not
certain about that, but, again, json_decode seems to manage.
json_decode() decodes to UTF-8.
What if I do this, in a latin1 encoded file:
$x = {foo: ä, bar: \u0123}
Should that then give mixed encodings? The ä in foo in latin1 and the stuff
in bar in UTF-8?
And what if I do:
$x = {foo: ä\u0123}
I'll either end up with an invalid UTF-8 sequence, or with latin1 character
soup.
David
- M.
--
Marcel Esser
Vice President of Engineering, CROSCON
+1 (202) 470-6090
marcel.es...@croscon.com
Before printing this e-mail, please consider the rainforest.
On 6/1/11 6:47 PM, David Zülke david.zue...@bitextender.com wrote:
Just because the MongoDB developers were stupid enough to build a query
language on top of JSON does not mean that JSON or JavaScript object
literals need to be supported in PHP. And it wouldn't be possible anyway
since JSON allows Unicode escape sequences, and PHP cannot even represent
those as it is not aware of runtime encodings.
Besides, outside the use case of json_decode(), stdClass is rarely ever
useful, so I don't understand why we're even discussing {} shorthands
here. It's not in the RFC either, so good job on focusing on the issue
and not diluting the discussion.
Getting back to the RFC: I think it's problematic to have two separate
syntaxes for the key/value separator. For consistency's sake, I'd rather
just have = but not :. Just my $0.02.
David
On 02.06.2011, at 00:09, John Crenshaw wrote:
For small linear arrays, neither format is more readable but for even
mildly complex structures, there is a clear difference. Consider the
following Mongo query:
$query = array(
'time'=array('$and'=array(
array('$gt'=strtotime('-1 day')),
array('$lt'=time()),
)),
'$or'=array(
array('foo'='bar'),
array('hello'='world')
)
);
Vs. the JSON form:
$query = {
time: {'$and': [
{'$gt': strtotime('-1 day')},
{'$lt': time()},
]},
'$or': [
{foo: 'bar'},
{hello: 'world'}
]
};
Because of the clear readability difference I'll take anything, but
JSON would be much better than just an array shorthand.
John Crenshaw
Priacta, Inc.
-Original Message-
From: Anthony Ferrara [mailto:ircmax...@gmail.com]
Sent: Wednesday, June 01, 2011 5:18 PM
To: PHP internals
Subject: Re: [PHP-DEV] RFC: Short syntax for Arrays (redux)
Personally, I think focusing on a character savings is the wrong
reason to take on any problem. I don't care how long it takes for me
to type code. I don't care how much extra hdd space it takes. But
what I do care about is how readable it is.
To me, the array shortcut syntax is pointless. Do you really mean to
tell me that `[1, 2]` is more readable/easier to understand than
`array(1,2)`? To me, it's about a wash.
However, the object shortcut syntax is a major win. For example:
$person = new stdClass();
$person-city = 'ogden';
$person-state = 'ut';
$perspn-country = 'usa';
$person-favoriteNumbers = array(4, 12, 37, 42);
$person-somethingWithNumbers();
$person-unluckyNumbers = array(6, 13, 21);
$person-likesPhp = 'very much so';
vs
$person = { 'name' = 'Justin',
'city' = 'ogden',
'state' = 'ut',
'country' = 'usa',
'favoriteNumbers' = [ 4, 12, 37, 42],
'unluckyNumbers' = [ 6, 13, 21],
'likesPhp' = 'very much so'
}
Did you notice what happened there? There's two differences. Try to
find them. Neither would be possible with the shortcut syntax.
Now, the only reason I would personally support the array shortcut is
if it was an implementation of JSON. I know that's not on the table
here, but that's the only benefit I can see to implementing a shortcut
for arrays (that would save 5 characters per instance).
Just my $0.02...
Anthony
On Wed, Jun 1, 2011 at 5:02 PM, Justin Carmony
jus...@justincarmony.com wrote:
To address the soapbox:
Its not just to reduce the five characters at the beginning, but when
you have more complex structures as well. There was already a great
example shown
(http://paste.roguecoders.com/p/0747f2363c228a09e0ddd6f8ec52f2e8.html)
of that. Also, if object support is added (which we need to add to the
RFC
Re: [PHP-DEV] Making SimpleXML more useful
On 29.04.2011, at 09:44, Tom Samplonius wrote: While I think this would make SimpleXML more stupid, not less, as it seems braindead to me to allow users to create documents ambiguously and/or which essentially violate the XML namespace spec, I think the way to do Allowing child elements to be unqualified is neither braindead or ambiguous. All standalone XML documents are ambiguous, because XML is just structured information without a definition of the structure (let alone the semantics of the information). XMLSchemas precisely define the structure, including allowable elements, child elements, quantities of elements and data types. And if that schema includes the attribute 'elementFormDefault=unqualified', then child elements have to be unqualified. And that is certainly strictly specified, unlike a schemaless XML. The elementFormDefault=qualified attribute simply acts as a shortcut in Schemas so that you don't have to use form=qualified on every element declaration. It makes no difference to instance documents which method you use. Again, xmlns= puts an element in no namespace. That already works in SimpleXML. There is no issue here that needs fixing. David smime.p7s Description: S/MIME cryptographic signature
Re: [PHP-DEV] Making SimpleXML more useful
On 30.04.2011, at 22:05, Ben Schmidt wrote:
This adds a certain ambiguity to document creation if it is used, but it
does add functionality not currently there. I guess it's only worth
doing if there are specs out there in the wild that (wrongly IMHO)
require unqualified names in XMLNames-conforming documents.
So, if the OP or his associates are in control of his schema, I suggest
he should change it; if he can point to a respectable public schema that
does this, it would be worthy of greater consideration.
There is no such schema, because from a processing model perspective,
foo xmlns=http://lol.com/burp; /
and
bar:foo xmlns:bar=http://lol.com/burp; /
are identical; they both yield an element {http://lol.com/burp}foo.
You cannot through a schema require an element in an instance document to be in
a namespace, but not have a prefix (that is *not* what elementFormDefault in an
XML is for), and it's not necessary, because the prefix doesn't matter. The
reason why namespace prefixes exist is that they make things more readable for
humans, and they decrease the file size.
David
smime.p7s
Description: S/MIME cryptographic signature
Re: [PHP-DEV] Making SimpleXML more useful
That patch is not a good idea.
Assume you have this situation:
foo xmlns=urn:lol
x:bar xmlns:x=urn:hai
/x:bar
/foo
Adding a child baz to bar and have it default to no namespace prefix would
result in this:
foo xmlns=urn:lol
x:bar xmlns:x=urn:hai
baz /
/x:bar
/foo
Now baz / would be in the namespace urn:lol.
Keep in mind that xmlns= is, as per the XML spec, a perfectly valid way to
reset the namespace of an element.
Also keep in mind that namespace prefixes are not what you should be looking
at. They are just a way to make things easier to read. What matters is the
namespace URI of an element.
SimpleXML is supposed to be simple (I find it more stupid than simple, but
that's my personal opinion). I guess that's why it, by default, inherits the
parent namespace.
David
On 27.04.2011, at 01:23, Tom Samplonius wrote:
It is not possible to use SimpleXML to add a child element without a
namespace prefix to a parent element that has a namespace element. Instead,
the child element inherits the namespace prefix of the parent. So this XML
fragment:
ns1:parent
childabc/child
/ns1:parent
is impossible to construct with SimpleXML. The SimpleXML extension would add
the child element with the ns1 namespace prefix. This is a problem for me,
as I have an XML schema that specifies that the child elements must not
namespace qualified.
I looked into the SimpleXML code, and I believe this is actually a bug, as
the code goes through some effort to distinguish between a set but blank
namespace, and a set but not blank namespace. I believe the design intent was
that specifying a blank namespace, would mean that no namespace would be
used, rather than inheriting the namespace of the parent.
?php
header('Content-Type: text/plain');
$r = new SimpleXMLElement('r /');
$c1 = $r-addChild('ns1:child1', NULL, 'urn:myspace1');
$c1-addChild('child2');
echo $r-asXML(), \n;
$r = new SimpleXMLElement('r /');
$r-addChild('Thing1', 100, '');
echo $r-asXML(), \n;
Expected result:
?xml version=1.0?
rns1:child1 xmlns:ns1=urn:myspace1ns1:child2//ns1:child1/r
?xml version=1.0?
rThing1100/Thing1/r
Actual result:
--
?xml version=1.0?
rns1:child1 xmlns:ns1=urn:myspace1ns1:child2//ns1:child1/r
?xml version=1.0?
rThing1 xmlns=100/Thing1/r
The current behavior of specifying a blank namespace, is to add a literal
blank namespace (xmlns=), which isn't a useful result. No one would be
depending on using a blank namepspace to get xmlns=.
The patch is pretty simple:
--- simplexml.c.orig 2011-04-26 16:00:31.0 -0700
+++ simplexml.c 2011-04-26 16:00:41.0 -0700
@@ -1619,12 +1619,14 @@
localname = xmlStrdup((xmlChar *)qname);
}
+ /* Add new child with no namespace */
newnode = xmlNewChild(node, NULL, localname, (xmlChar *)value);
if (nsuri != NULL) {
+ /* If namespace is not NULL but blank, use no namespace
+ Use this to prevent inheriting the name space of the parent */
if (nsuri_len == 0) {
newnode-ns = NULL;
- nsptr = xmlNewNs(newnode, (xmlChar *)nsuri, prefix);
} else {
nsptr = xmlSearchNsByHref(node-doc, node, (xmlChar *)nsuri);
if (nsptr == NULL) {
(see also http://bugs.php.net/bug.php?id=54354)
If this patch is accepted, I'll also submit patches to clarify the
documentation and add some tests. SimpleXML with the above patch, passes the
existing tests. It is hard to know for sure what the design intent was, as
the code has few comments, few tests, and the documentation is pretty thin.
But I believe the above is correct.
Tom
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
smime.p7s
Description: S/MIME cryptographic signature
[PHP-DEV] [PATCH] Allow loading of arbitrary resource bundles when fallback is disabled.
ResourceBundle::__construct() uses ures_open(), which performs validity checks on the given locale identifier. That's reasonable, as the fallback functionality only works with proper locale IDs (example: you pass de_DE, but no such bundle exist, it will then use the bundle de if that exists). With the fallback flag off (third ctor argument), ures_open is still used. This won't allow loading of data in invalid identifiers, such as some of ICU's built-in data (e.g. supplementalData). http://bugs.php.net/bug.php?id=54540 has a patch, but I wanted to run it by Hans-Peter and Stas again in case they want to discuss this. David smime.p7s Description: S/MIME cryptographic signature
Re: [PHP-DEV] [PATCH] #52563: Adding E_NONE and/or E_EVERYTHING constants
On 25.08.2010, at 15:51, Tyler Lawson wrote: Sebastian Bergmann wrote: So nobody will use E_DEVELOPMENT or E_NONE or whatever. We can only add options to PHP that offer choices to developers. If they do not use them ... what can we do? As a regular user of PHP, I like the idea of E_DEVELOPMENT and E_PRODUCTION. They're clear and will do what I would expect them to. Why not change the default php.inis to those values instead? I'm a against E_NONE, though. Now, I understand what a bit mask is, but imagine for a second that I didn't. Imagine that I want no messages except for E_ERROR. As a theoretically less experienced developer, I might assume that I should explicitly turn off all errors except for E_ERROR. What does that get me? error_reporting(E_NONE E_ERROR). Oops. That doesn't work as I expect it to! That's because you're doing it wrong: error_reporting(E_NONE | E_ERROR); - David smime.p7s Description: S/MIME cryptographic signature
Re: [PHP-DEV] Static initialization block support in Class?
On 17.08.2010, at 10:46, Ferenc Kovacs wrote:
Tue, Aug 17, 2010 at 10:04 AM, Richard Quadling rquadl...@gmail.comwrote:
On 17 August 2010 08:39, Jingcheng Zhang dio...@gmail.com wrote:
Hello internals,
I wonder whether it is possible to implement static initialization
block
feature in PHP, for example:
?php
class Foo {
}
class Bar {
public static $baz = 'baz';
public static $foo;
static {
// After loading this file, self::$foo is initialized as a Foo
instance.
self::$foo = new Foo();
}
}
?
Currently we have to do this outside the class definition as static
variable
initialization is only limited to constant values.
However in some circumstance, dynamic initialization of static variable
is
expected and meaningful.
Thanks in advance!
--
Best regards,
Jingcheng Zhang
P.R.China
Implementing a singleton method is a common solution and one that is
well understood and documented.
Another option would be to put the initialisation immediately after
the class definition, so once the class is loaded, a static instance
is prepared. This saves the consumer of the class from having to do 1
additional line of code.
Or you could load the public static methods with a JIT call to prepare
the static instance. Overhead is that every call will have to test
self::$instance
There is probably some argument against statics being dynamic
though ... not my area of expertise to argue either way.
--
Richard Quadling.
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
This was brought up in the past:
http://www.mail-archive.com/internals@lists.php.net/msg46458.html
I still think that it's weird, that I can define a constant to a dynamic
value (eg. by a complex expression or a function's return value), but I
can't do that with the class consts. and with 5.3, we have two different
kind of consts, you can define constants in compile time with const where
you can't use expressions, and you can use the define method, where you can
use expressions.
and you can combine them:
define(NOW, time());
var_dump(NOW);
const BAR = NOW;
var_dump(BAR);
class baz{
const BAR = NOW;
}
var_dump(baz::BAR);'
with that in mind, I think we could allow complex expression to the const:
the expression will be stored as-is, and when it's referenced (JIT) then it
will be evaluated.
and this could be used also for variables also:
class foo{
public $now = time();
}
$foo = new foo;
echo $foo-now;
ps: I predict somebody will say: can of worms! :)
Tyrael
Can do: can of worms.
To the original poster: use a singleton or add the init declarations after the
class declaration, works just fine with autoloads (I recommend the singleton
approach).
- David
smime.p7s
Description: S/MIME cryptographic signature
Re: [PHP-DEV] TODO List
http://thread.gmane.org/gmane.comp.php.devel/60563 and http://thread.gmane.org/gmane.comp.php.devel/57369 ;) On 12.05.2010, at 22:23, Mathias Grimm wrote: What is the correct todo list ? I want to help us but a need to see the todo list to select my work! Any sugestion to start? -- Att. Mathias Grimm http://mathiasgrimm.com.br http://phpempregos.com.br smime.p7s Description: S/MIME cryptographic signature
Re: [PHP-DEV] Bug 44383 in ext/soap
On 25.03.2010, at 22:05, Michael Maclean wrote: Currently, DateTime objects aren't properly mapped to and from xsd:datetime objects when sending them via ext/soap. David Zülke wrote a patch to fix this, and filed it under bug 44383, and mailed the list with it - http://article.gmane.org/gmane.comp.php.devel/ 57369 - but it seems not to have been applied. I tried it earlier on current trunk and noticed it had a couple of problems compiling on a ZTS PHP, which led me to my anti-TSRMLS_FETCH() rampage earlier on today. I've now updated the patch and applied it to my trunk, and it appears to work and pass the tests - does anyone have a problem with me applying it to trunk? Did you also succeed in compiling it as a standalone extension? Could you try? There were some dependencies on ext/date symbols that gave me a hard time when trying that back then... and I lack(ed) the C-fu to fix that. The updated version of David's patch is available here: http://mgdm.net/~michael/patches/bug44383.txt (I noticed a couple of problems with the schema tests, 089 and 091 - it seemed that the test originally expected the timezone offsets to be applied in the wrong direction - I could do with a second opinion on this.) Yes, I think I remember something in that direction. Some timezone offsets behaved weird; back then I think I concluded that the tests must have been wrong as a bug related to that in ext/date was unlikely. Could you list the tested values with expected and actual results? It's only a few IIRC, and it'd make it easier to discuss. - David smime.p7s Description: S/MIME cryptographic signature
Re: [PHP-DEV] Regarding constructions like func()[0]
It's already on the list for PHP6: http://wiki.php.net/summits/pdmnotesmay09 (see Day 2, PHP 6, #13). No need to discuss this further, I think. You might also want to have that bug closed, it's redundant. - David On 07.11.2009, at 12:42, melfar wrote: Hello! I have filed a bug (suggestion) at http://bugs.php.net/bug.php? id=50003 What do you think about enabling such a constructions in future versions of php? Br, -melfar -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php smime.p7s Description: S/MIME cryptographic signature
Re: [PHP-DEV] Bug #49325 Error in domdocument-schemaValidate
On 05.10.2009, at 18:11, Israel Ekpo wrote: This was actually not a bug with the PHP code. The error was in the instance XML document. I just closed the bug. That should probably be closed as bogus, not closed. - David smime.p7s Description: S/MIME cryptographic signature
Re: [PHP-DEV] Re: SOAP_MARSHAL_DATETIME (or: bug #44383)
On 28.07.2009, at 19:14, Jani Taskinen wrote: Dmitry Stogov wrote: David Zülke wrote: On 28.07.2009, at 13:32, Dmitry Stogov wrote: Hi David, I took only a quick look, but I like the patch. In case it doesn't break any tests, it should be committed at least into HEAD. I agree to commit it into 5.3 too, but RMs take the final decision. The only thing I didn't understood - why win32/php_stdint.h is needed. Ah, yes, that's probably an oversight. Good catch. The headers were copy-pasted from some ext/date file :) Another thing that just occured to me is that we now have a dependency on ext/date; I think I had trouble compiling ext/soap as a standalone extension like this. Must check again. Any hints? I think ext/date can't be removed or compiled as shared extension. If it's the case, the only problem may be with unexported symbols. Just try to compile/test it as shared extension on Linux and Windows. ext/date is not an extension, it's part of core, just like ext/ standard so you shouldn't have any problems with it. Attached (and also posted here: http://pastie.org/575559 and here: http://bugs.php.net/44383) is an update of the patch. It has the following updates: 1) all tests adjusted, reviewed and changed to work in sequence (only one of the several variants was not commented out before) 2) fixed handling of unix timestamp longs There are the following outstanding issues (I'm going on a holiday tomorrow, so I figured I'd shoot you an update in the meantime): 1) there seem to be problems with negative timezone offsets (see tests ext/soap/tests/schema/schema0(89|91).phpt) unless I'm confused 2) at the minute, it breaks ext/soap/tests/schema/schema064.phpt. Except for one of the cases where the formatting is indeed wrong, it's due to time zones not being included. That obviously needs fixing, but I'd like to point out that the current tests do not seem to be in compliance with the XML Schema specification, which for gMonthDay, gDay and gMonth states: An optional following time zone qualifier is allowed as for date. The rule for date and timezone postfixes is For timezoned values, append the canonical representation of the ·recoverable timezone·. A recoverable timezone is an offset value in the format [+-]hh:mm. http://www.w3.org/TR/xmlschema-2/ has all the details, but maybe I'm missing something. For gYearMonth and gYear, I think the dateTime timezone rules apply, which means the canonical representation must always be in UTC (and thus carry Z as the timezone identifier, which is what the tests currently expect, so those are correct). Finally, when I compile as an extension, I get the following error once I reach tests that execute code relying on timelib: dyld: lazy symbol binding failed: Symbol not found: _timelib_time_ctor Referenced from: .../extensions/no-debug-non-zts-20090626/soap.so Expected in: flat namespace dyld: Symbol not found: _timelib_time_ctor Referenced from: .../extensions/no-debug-non-zts-20090626/soap.so Expected in: flat namespace I compiled without --enable-soap, then used the correct phpize in ext/soap, ran configure with the correct --with-php-config=.../blah/ php-config, make install and enabled the extension in php.ini. Feedback/thoughts/advice appreciated. I'll be back in ~2 weeks. Cheers, - David Index: ext/soap/soap.c === --- ext/soap/soap.c (Revision 286909) +++ ext/soap/soap.c (Arbeitskopie) @@ -828,6 +828,7 @@ REGISTER_LONG_CONSTANT(SOAP_SINGLE_ELEMENT_ARRAYS, SOAP_SINGLE_ELEMENT_ARRAYS, CONST_CS | CONST_PERSISTENT); REGISTER_LONG_CONSTANT(SOAP_WAIT_ONE_WAY_CALLS, SOAP_WAIT_ONE_WAY_CALLS, CONST_CS | CONST_PERSISTENT); REGISTER_LONG_CONSTANT(SOAP_USE_XSI_ARRAY_TYPE, SOAP_USE_XSI_ARRAY_TYPE, CONST_CS | CONST_PERSISTENT); + REGISTER_LONG_CONSTANT(SOAP_MARSHAL_DATETIME, SOAP_MARSHAL_DATETIME, CONST_CS | CONST_PERSISTENT); REGISTER_LONG_CONSTANT(WSDL_CACHE_NONE, WSDL_CACHE_NONE, CONST_CS | CONST_PERSISTENT); REGISTER_LONG_CONSTANT(WSDL_CACHE_DISK, WSDL_CACHE_DISK, CONST_CS | CONST_PERSISTENT); Index: ext/soap/php_soap.h === --- ext/soap/php_soap.h (Revision 286909) +++ ext/soap/php_soap.h (Arbeitskopie) @@ -143,6 +143,7 @@ #define SOAP_SINGLE_ELEMENT_ARRAYS (10) #define SOAP_WAIT_ONE_WAY_CALLS (11) #define SOAP_USE_XSI_ARRAY_TYPE (12) +#define SOAP_MARSHAL_DATETIME(13) #define WSDL_CACHE_NONE 0x0 #define WSDL_CACHE_DISK 0x1 Index: ext/soap/tests/schema/schema091.phpt === --- ext/soap/tests/schema/schema091.phpt(Revision 0) +++ ext/soap/tests/schema/schema091.phpt(Revision 0) @@ -0,0 +1,36 @@ +--TEST-- +SOAP XML Schema 91: xsd:dateTime DateTime to XML conversion +--SKIPIF-- +?php
Re: [PHP-DEV] Re: SOAP_MARSHAL_DATETIME (or: bug #44383)
On 28.07.2009, at 19:14, Jani Taskinen wrote: Dmitry Stogov wrote: David Zülke wrote: On 28.07.2009, at 13:32, Dmitry Stogov wrote: Hi David, I took only a quick look, but I like the patch. In case it doesn't break any tests, it should be committed at least into HEAD. I agree to commit it into 5.3 too, but RMs take the final decision. The only thing I didn't understood - why win32/php_stdint.h is needed. Ah, yes, that's probably an oversight. Good catch. The headers were copy-pasted from some ext/date file :) Another thing that just occured to me is that we now have a dependency on ext/date; I think I had trouble compiling ext/soap as a standalone extension like this. Must check again. Any hints? I think ext/date can't be removed or compiled as shared extension. If it's the case, the only problem may be with unexported symbols. Just try to compile/test it as shared extension on Linux and Windows. ext/date is not an extension, it's part of core, just like ext/ standard so you shouldn't have any problems with it. Not attached (because the draconian police state filters at lists.php.net didn't like the patch attachment or something :)), but posted here: http://pastie.org/575559 and here: http://bugs.php.net/44383 , is an update of the patch. It has the following updates: 1) all tests adjusted, reviewed and changed to work in sequence (only one of the several variants was not commented out before) 2) fixed handling of unix timestamp longs There are the following outstanding issues (I'm going on a holiday tomorrow, so I figured I'd shoot you an update in the meantime): 1) there seem to be problems with negative timezone offsets (see tests ext/soap/tests/schema/schema0(89|91).phpt) unless I'm confused 2) at the minute, it breaks ext/soap/tests/schema/schema064.phpt. Except for one of the cases where the formatting is indeed wrong, it's due to time zones not being included. That obviously needs fixing, but I'd like to point out that the current tests do not seem to be in compliance with the XML Schema specification, which for gMonthDay, gDay and gMonth states: An optional following time zone qualifier is allowed as for date. The rule for date and timezone postfixes is For timezoned values, append the canonical representation of the ·recoverable timezone·. A recoverable timezone is an offset value in the format [+-]hh:mm. http://www.w3.org/TR/xmlschema-2/ has all the details, but maybe I'm missing something. For gYearMonth and gYear, I think the dateTime timezone rules apply, which means the canonical representation must always be in UTC (and thus carry Z as the timezone identifier, which is what the tests currently expect, so those are correct). Finally, when I compile as an extension, I get the following error once I reach tests that execute code relying on timelib: dyld: lazy symbol binding failed: Symbol not found: _timelib_time_ctor Referenced from: .../extensions/no-debug-non-zts-20090626/soap.so Expected in: flat namespace dyld: Symbol not found: _timelib_time_ctor Referenced from: .../extensions/no-debug-non-zts-20090626/soap.so Expected in: flat namespace I compiled without --enable-soap, then used the correct phpize in ext/soap, ran configure with the correct --with-php-config=.../blah/ php-config, make install and enabled the extension in php.ini. Feedback/thoughts/advice appreciated. I'll be back in ~2 weeks. Cheers, - David -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Re: SOAP_MARSHAL_DATETIME (or: bug #44383)
On 28.07.2009, at 19:14, Jani Taskinen wrote: Dmitry Stogov wrote: David Zülke wrote: On 28.07.2009, at 13:32, Dmitry Stogov wrote: Hi David, I took only a quick look, but I like the patch. In case it doesn't break any tests, it should be committed at least into HEAD. I agree to commit it into 5.3 too, but RMs take the final decision. The only thing I didn't understood - why win32/php_stdint.h is needed. Ah, yes, that's probably an oversight. Good catch. The headers were copy-pasted from some ext/date file :) Another thing that just occured to me is that we now have a dependency on ext/date; I think I had trouble compiling ext/soap as a standalone extension like this. Must check again. Any hints? I think ext/date can't be removed or compiled as shared extension. If it's the case, the only problem may be with unexported symbols. Just try to compile/test it as shared extension on Linux and Windows. ext/date is not an extension, it's part of core, just like ext/ standard so you shouldn't have any problems with it. Not attached (because the draconian police state filters at lists.php.net didn't like the patch attachment or something :)), but posted here: http://pastie.org/575559 and here: http://bugs.php.net/44383 , is an update of the patch. It has the following updates: 1) all tests adjusted, reviewed and changed to work in sequence (only one of the several variants was not commented out before) 2) fixed handling of unix timestamp longs There are the following outstanding issues (I'm going on a holiday tomorrow, so I figured I'd shoot you an update in the meantime): First, there seem to be problems with negative timezone offsets (see tests ext/soap/tests/schema/schema0(89|91).phpt) unless I'm confused Second, at the minute, it breaks ext/soap/tests/schema/schema064.phpt. Except for one of the cases where the formatting is indeed wrong, it's due to time zones not being included. That obviously needs fixing, but I'd like to point out that the current tests do not seem to be in compliance with the XML Schema specification, which for gMonthDay, gDay and gMonth states: An optional following time zone qualifier is allowed as for date. The rule for date and timezone postfixes is For timezoned values, append the canonical representation of the ·recoverable timezone·. A recoverable timezone is an offset value in the format [+-]hh:mm. http://www.w3.org/TR/xmlschema-2/ has all the details, but maybe I'm missing something. For gYearMonth and gYear, I think the dateTime timezone rules apply, which means the canonical representation must always be in UTC (and thus carry Z as the timezone identifier, which is what the tests currently expect, so those are correct). Finally, when I compile as an extension, I get the following error once I reach tests that execute code relying on timelib: dyld: lazy symbol binding failed: Symbol not found: _timelib_time_ctor Referenced from: .../extensions/no-debug-non-zts-20090626/soap.so Expected in: flat namespace dyld: Symbol not found: _timelib_time_ctor Referenced from: .../extensions/no-debug-non-zts-20090626/soap.so Expected in: flat namespace I compiled without --enable-soap, then used the correct phpize in ext/soap, ran configure with the correct --with-php-config=.../blah/ php-config, make install and enabled the extension in php.ini. Feedback/thoughts/advice appreciated. I'll be back in ~2 weeks. Cheers, - David smime.p7s Description: S/MIME cryptographic signature
[PHP-DEV] Re: [SOAP] SOAPClient authentication problem
On 24.07.2009, at 12:48, David Zülke wrote:
Yes, thanks, I realize that, but I need to test it in a .phpt unit
test, which is a bit trickier. But as I said, I already have an
idea. Will do it this later and open a ticket.
Issue: http://bugs.php.net/49144
.phpt: http://pastie.org/569897 (also attached)
- David
--TEST--
Bug #49144 (import of schemas from different hosts transmits original
authentication details)
--SKIPIF--
?php
require_once('skipif.inc');
###
### THIS RE-USES TESTING CODE FROM ext/standard/tests/http/, BEWARE
###
require dirname(__FILE__) . '../../../../standard/tests/http/server.inc';
http_server_skipif('tcp://127.0.0.1:12342'); ?
?
--FILE--
?php
###
### THIS RE-USES TESTING CODE FROM ext/standard/tests/http/, BEWARE
###
require dirname(__FILE__) . '../../../../standard/tests/http/server.inc';
$responses = array(
data://text/plain,HTTP/1.1 200 OK\r\nContent-Type: application/xml;
charset=UTF-8\r\n\r\n . '?xml version=1.0 encoding=utf-8?
wsdl:definitions xmlns:wsdl=http://schemas.xmlsoap.org/wsdl/;
xmlns:xsd=http://www.w3.org/2001/XMLSchema;
xmlns:soap=http://schemas.xmlsoap.org/wsdl/soap/;
xmlns:soapenc=http://schemas.xmlsoap.org/soap/encoding/;
xmlns=http://schemas.xmlsoap.org/wsdl/;
xmlns:tns=http://agavi.org/sampleapp/types;
xmlns:asa=http://agavi.org/sampleapp; name=AgaviSampleApplication
targetNamespace=http://agavi.org/sampleapp;
wsdl:types
xsd:schema
xmlns:soap-enc=http://schemas.xmlsoap.org/soap/encoding/;
xmlns=http://agavi.org/agavi/config/parts/routing/1.0;
targetNamespace=http://agavi.org/sampleapp/types;
xs:import
namespace=http://www.w3.org/XML/1998/namespace;
schemaLocation=http://localhost:12342/xml.xsd/
xsd:complexType name=Product
xsd:sequence
xsd:element name=id type=xsd:int/
xsd:element name=name
type=xsd:string/
xsd:element name=price
type=xsd:float/
/xsd:sequence
/xsd:complexType
/xsd:schema
/wsdl:types
wsdl:portType name=AgaviSampleApplicationPortType
wsdl:operation name=getProduct
wsdl:input message=asa:getProductRequest/
wsdl:output message=asa:getProductResponse/
/wsdl:operation
/wsdl:portType
binding name=AgaviSampleApplicationBinding
type=asa:AgaviSampleApplicationPortType
soap:binding style=rpc
transport=http://schemas.xmlsoap.org/soap/http/
wsdl:operation name=getProduct
soap:operation
soapAction=http://agavi.org/sampleapp#getProduct/
wsdl:input
soap:body
namespace=http://agavi.org/sampleapp; use=literal/
/wsdl:input
wsdl:output
soap:body
namespace=http://agavi.org/sampleapp; use=literal/
/wsdl:output
/wsdl:operation
/binding
service name=AgaviSampleApplicationService
port name=AgaviSampleApplicationPort
binding=asa:AgaviSampleApplicationBinding
soap:address
location=http://localhost/YOUR/PATH/TO/samples/pub/soap.php/
/port
/service
wsdl:message name=getProductRequest
wsdl:part
xmlns=http://agavi.org/agavi/config/parts/routing/1.0; name=id
type=xsd:int/
/wsdl:message
wsdl:message name=getProductResponse
wsdl:part
xmlns=http://agavi.org/agavi/config/parts/routing/1.0; name=product
type=tns:Product/
/wsdl:message
/wsdl:definitions',
data://text/plain,HTTP/1.1 200 OK\r\nContent-Type: application/xml;
charset=UTF-8\r\n\r\n . '?xml version=1.0 encoding=utf-8?
xs:schema targetNamespace=http://www.w3.org/XML/1998/namespace;
xmlns:xs=http://www.w3.org/2001/XMLSchema;
xmlns=http://www.w3.org/1999/xhtml; xml:lang=en
xs:attribute name=base type=xs:anyURI /
/xs:schema',
);
$pid = http_server(tcp://127.0.0.1:12342, $responses, $output);
ini_set(soap.wsdl_cache_enabled, 0);
$client = new SoapClient(http://127.0.0.1:12342/bug.wsdl;, array('login' =
'foo', 'password' = 'bar'));
fseek($output, 0, SEEK_SET);
var_dump(stream_get_contents($output));
http_server_kill($pid);
?
--EXPECTF--
string(%s) GET /bug.wsdl HTTP/1.1
Host: 127.0.0.1:12342
Authorization: Basic Zm9vOmJhcg==
Connection: close
GET /xml.xsd HTTP/1.1
Host: localhost:12342
Connection: close
smime.p7s
Description: S/MIME cryptographic signature
[PHP-DEV] Re: [SOAP] SOAPClient authentication problem
On 24.07.2009, at 12:48, David Zülke wrote: Yes, thanks, I realize that, but I need to test it in a .phpt unit test, which is a bit trickier. But as I said, I already have an idea. Will do it this later and open a ticket. Issue: http://bugs.php.net/49144 .phpt: http://pastie.org/569897 (tried to attach it but the message didn't make it through) - David -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] Re: [SOAP] SOAPClient authentication problem
On 24.07.2009, at 12:48, David Zülke wrote: Yes, thanks, I realize that, but I need to test it in a .phpt unit test, which is a bit trickier. But as I said, I already have an idea. Will do it this later and open a ticket. I finally got around to writing a test case and opening a ticket (which contains the .phpt): http://bugs.php.net/49144 Cheers, - David smime.p7s Description: S/MIME cryptographic signature
[PHP-DEV] Re: SOAP_MARSHAL_DATETIME (or: bug #44383)
*bump* Dmitry, did you have a chance to review this patch yet? - David On 22.06.2009, at 15:21, David Zülke wrote: Hi folks, attached is a patch (with the respective test cases) that implements DateTime marshalling from and to xsd:dateTime in ext/soap as requested in http://bugs.php.net/44383 Right now, it is implemented for xsd:date, xsd:time and xsd:dateTime, but not for other types defined in W3C XML Schema such as gDayMonth; I don't really think it makes sense mapping from and to DateTimes in this case (from DateTime to gDayMonth would work, but the other way round would prove rather difficult). Some notes about this patch: - it conforms strictly to the XML Schema specification by only producing canonical representations of values when generating xsd:dateTime and xsd:time values. Specifically: - it will not generate trailing zeroes on microseconds (in other words, it simply generates a fractional second part as mandated by the specification), but it will accept such values - UTC is always used as the timezone (one of the tests in ext/date/ tests that mirrors SBR1-echoDate from http://www.w3.org/TR/2007/REC-soap12-testcollection-20070427/#SBR1-echoDate currently does this wrong), but it will accept any timezone - xsd:time produces current date when generating a DateTime object - xsd:date is relatively straightfoward as well: - produces 00:00:00 as the time when creating a DateTime object - accepts any time when parsing - also supports timezones - as a side effect of the patch, microseconds are now supported in time values (for xsd:time and xsd:dateTime), hence the removed comment in to_xml_time The tests have several permutations, but all but one is commented out each. The test_schema() function does some odd (but understandable) stunts with output buffering and global variables that make it impossible to test more than one case at a time. We didn't want to produce a million test files for the several variants; is there a nicer way to test this properly? This feature is enabled by a SoapClient feature called SOAP_MARSHAL_DATETIME. I think this is a reasonable choice. Greetings, David schema089 .phpt soap_marshal_datatype .diff .txt schema087 .phptschema088.phptschema086.phptschema090.phptschema091.phpt smime.p7s Description: S/MIME cryptographic signature
Re: [PHP-DEV] Re: SOAP_MARSHAL_DATETIME (or: bug #44383)
On 28.07.2009, at 13:32, Dmitry Stogov wrote: Hi David, I took only a quick look, but I like the patch. In case it doesn't break any tests, it should be committed at least into HEAD. I agree to commit it into 5.3 too, but RMs take the final decision. The only thing I didn't understood - why win32/php_stdint.h is needed. Ah, yes, that's probably an oversight. Good catch. The headers were copy-pasted from some ext/date file :) Another thing that just occured to me is that we now have a dependency on ext/date; I think I had trouble compiling ext/soap as a standalone extension like this. Must check again. Any hints? - David smime.p7s Description: S/MIME cryptographic signature
[PHP-DEV] Fwd: [SOAP] SOAPClient authentication problem
This sounds like a serious issue, but I'm not sure if it's in libxml or in ext/soap. Will have a look later; but maybe Dmitry or someone else knows off the top of their heads? - David Begin forwarded message: From: Davide Romanini davide.roman...@gmail.com Date: 30. Juni 2009 11:49:30 MESZ To: s...@lists.php.net Subject: [SOAP] SOAPClient authentication problem Reply-To: d.roman...@cineca.it Hi, Today I found a nasty problem with a simple php SOAP client. Never had problems before, but today I have the following error at SOAPClient constructor line: SoapClient::SoapClient(http://www.w3.org/2001/xml.xsd): failed to open stream: HTTP request failed! HTTP/1.1 401 Authorization Required The source is as simple as: $client = new SoapClient(http://my.host.com/my_web_service?wsdl;, array( 'trace' = TRUE, 'login'='mylogin', 'password'='secret' ) ); It seems that the php xml parser tries to fetch the url http://www.w3.org/2001/xml.xsd at wsdl parsing time. Sniffing the network operations I found that php uses my login and password (for the web service) also to access external references! :-O GET /2001/xml.xsd HTTP/1.0 Authorization: Basic bXlsb2dpbjpzZWNyZXQ= Host: www.w3.org In the past probably w3.org just ignored the issue, but now I receive an HTTP 401 Unauthorized error in response... In any case it is a serious security issue if SOAPClient sends password around the web, when the intent is that they are used only for the web service host! I tried the following PHP versions: PHP 5.2.3-1ubuntu6.5 (cli) (built: Feb 11 2009 19:55:53) Copyright (c) 1997-2007 The PHP Group Zend Engine v2.2.0, Copyright (c) 1998-2007 Zend Technologies PHP 5.2.8 (cli) (built: Dec 17 2008 00:54:27) Copyright (c) 1997-2008 The PHP Group Zend Engine v2.2.0, Copyright (c) 1998-2008 Zend Technologies with Zend Extension Manager v1.0.11, Copyright (c) 2003-2006, by Zend Technologies with Zend Optimizer v3.2.0, Copyright (c) 1998-2006, by Zend Technologies with Zend Debugger v5.2.2, Copyright (c) 1999-2006, by Zend Technologies Regards, Davide -- PHP Soap Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php smime.p7s Description: S/MIME cryptographic signature
[PHP-DEV] Re: [SOAP] SOAPClient authentication problem
Can do, but I wanted to figure out a way to create a reproduce case first (I already have an idea). - David On 24.07.2009, at 12:20, Dmitry Stogov wrote: Hi David, Please report a bug on bugs.php.net (assign it to dmitry). I'll look into it later. Thanks. Dmitry. David Zülke wrote: This sounds like a serious issue, but I'm not sure if it's in libxml or in ext/soap. Will have a look later; but maybe Dmitry or someone else knows off the top of their heads? - David Begin forwarded message: From: Davide Romanini davide.roman...@gmail.com Date: 30. Juni 2009 11:49:30 MESZ To: s...@lists.php.net Subject: [SOAP] SOAPClient authentication problem Reply-To: d.roman...@cineca.it Hi, Today I found a nasty problem with a simple php SOAP client. Never had problems before, but today I have the following error at SOAPClient constructor line: SoapClient::SoapClient(http://www.w3.org/2001/xml.xsd): failed to open stream: HTTP request failed! HTTP/1.1 401 Authorization Required The source is as simple as: $client = new SoapClient(http://my.host.com/my_web_service?wsdl;, array( 'trace' = TRUE, 'login'='mylogin', 'password'='secret' ) ); It seems that the php xml parser tries to fetch the url http://www.w3.org/2001/xml.xsd at wsdl parsing time. Sniffing the network operations I found that php uses my login and password (for the web service) also to access external references! :-O GET /2001/xml.xsd HTTP/1.0 Authorization: Basic bXlsb2dpbjpzZWNyZXQ= Host: www.w3.org In the past probably w3.org just ignored the issue, but now I receive an HTTP 401 Unauthorized error in response... In any case it is a serious security issue if SOAPClient sends password around the web, when the intent is that they are used only for the web service host! I tried the following PHP versions: PHP 5.2.3-1ubuntu6.5 (cli) (built: Feb 11 2009 19:55:53) Copyright (c) 1997-2007 The PHP Group Zend Engine v2.2.0, Copyright (c) 1998-2007 Zend Technologies PHP 5.2.8 (cli) (built: Dec 17 2008 00:54:27) Copyright (c) 1997-2008 The PHP Group Zend Engine v2.2.0, Copyright (c) 1998-2008 Zend Technologies with Zend Extension Manager v1.0.11, Copyright (c) 2003-2006, by Zend Technologies with Zend Optimizer v3.2.0, Copyright (c) 1998-2006, by Zend Technologies with Zend Debugger v5.2.2, Copyright (c) 1999-2006, by Zend Technologies Regards, Davide -- PHP Soap Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php smime.p7s Description: S/MIME cryptographic signature
[PHP-DEV] Re: [SOAP] SOAPClient authentication problem
On 24.07.2009, at 12:45, Davide Romanini wrote:
David Zülke ha scritto:
Can do, but I wanted to figure out a way to create a reproduce case
first (I already have an idea).
- David
On 24.07.2009, at 12:20, Dmitry Stogov wrote:
Hi David,
Please report a bug on bugs.php.net (assign it to dmitry).
I'll look into it later.
Thanks. Dmitry.
David Zülke wrote:
This sounds like a serious issue, but I'm not sure if it's in
libxml or
[ 8 ]
It's really simple to reproduce. Take this example wsdl:
?xml version=1.0 encoding=UTF-8 standalone=no?
wsdl:definitions xmlns:wsdl=http://schemas.xmlsoap.org/wsdl/;
xmlns:sch=http://mycompany.com/hr/schemas;
xmlns:soap=http://schemas.xmlsoap.org/wsdl/soap/;
xmlns:tns=http://mycompany.com/hr/schemas;
targetNamespace=http://mycompany.com/hr/schemas;
wsdl:types
xs:schema xmlns:hr=http://mycompany.com/hr/schemas;
xmlns:xs=http://www.w3.org/2001/XMLSchema;
elementFormDefault=qualified
targetNamespace=http://mycompany.com/hr/schemas;
xs:import namespace=http://www.w3.org/XML/1998/namespace;
schemaLocation=http://www.w3.org/2001/xml.xsd/
[ 8 ]
/wsdl:definitions
The important part is
xs:import namespace=http://www.w3.org/XML/1998/namespace;
schemaLocation=http://www.w3.org/2001/xml.xsd/
I just copied this file in my local apache doc root and tried to run
this script:
?php
$client = new SoapClient(http://localhost/test/holiday.wsdl;,
array( 'trace' = TRUE,
'login'='mylogin',
'password'='secret'
)
);
?
And the output is:
Warning: SoapClient::SoapClient(http://www.w3.org/2001/xml.xsd):
failed
to open stream: HTTP request failed! HTTP/1.1 401 Authorization
Required
in /home/romaz/tmp/soapFail.php on line 7
Warning: SoapClient::SoapClient(): I/O warning : failed to load
external
entity http://www.w3.org/2001/xml.xsd; in /home/romaz/tmp/
soapFail.php
on line 7
Fatal error: Uncaught SoapFault exception: [WSDL] SOAP-ERROR: Parsing
Schema: can't import schema from 'http://www.w3.org/2001/xml.xsd' in
/home/romaz/tmp/soapFail.php:7
Stack trace:
#0 /home/romaz/tmp/soapFail.php(7):
SoapClient-SoapClient('http://localhos...', Array)
#1 {main}
thrown in /home/romaz/tmp/soapFail.php on line 7
Note that login and password here are completely useless, because on
my
local apache I haven't any access restriction.
Bye,
Davide
Yes, thanks, I realize that, but I need to test it in a .phpt unit
test, which is a bit trickier. But as I said, I already have an idea.
Will do it this later and open a ticket.
- David
smime.p7s
Description: S/MIME cryptographic signature
Re: [PHP-DEV] Patch for Bug #
On 20.07.2009, at 12:42, Jani Taskinen wrote: On 07/15/2009 08:49 PM, David Zülke wrote: Hi there, attached are patches for http://bugs.php.net/48929. Big kudos to Tjerk Anne and Arnaud, this forking HTTP server stuff for testing the stream wrapper is genius. Ehem..was this ever committed? And don't you have svn access yourself anyway? No and no :) - David -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] Patch for Bug #
Hi there,
attached are patches for http://bugs.php.net/48929.
Big kudos to Tjerk Anne and Arnaud, this forking HTTP server stuff for
testing the stream wrapper is genius.
- David
Index: ext/standard/tests/http/bug48929.phpt
===
--- ext/standard/tests/http/bug48929.phpt (Revision 0)
+++ ext/standard/tests/http/bug48929.phpt (Revision 0)
@@ -0,0 +1,56 @@
+--TEST--
+Bug #: duplicate \r\n sent after last header line
+--SKIPIF--
+?php require 'server.inc'; http_server_skipif('tcp://127.0.0.1:12342'); ?
+--FILE--
+?php
+require 'server.inc';
+
+function do_test($context_options) {
+
+ $context = stream_context_create(array('http' = $context_options));
+
+ $responses = array(
+ data://text/plain,HTTP/1.0 200 OK\r\n\r\n,
+ );
+
+ $pid = http_server(tcp://127.0.0.1:12342, $responses, $output);
+
+ foreach($responses as $r) {
+
+ $fd = fopen('http://127.0.0.1:12342/', 'rb', false, $context);
+
+ fseek($output, 0, SEEK_SET);
+ var_dump(stream_get_contents($output));
+ fseek($output, 0, SEEK_SET);
+ }
+
+ http_server_kill($pid);
+}
+
+echo -- Test: requests with 'header' as array --\n;
+
+do_test(array('header' = array('X-Foo: bar', 'Content-Type: text/plain'),
'method' = 'POST', 'content' = 'ohai'));
+
+echo -- Test: requests with 'header' as string --\n;
+
+do_test(array('header' = X-Foo: bar\r\nContent-Type: text/plain, 'method'
= 'POST', 'content' = 'ohai'));
+
+?
+--EXPECT--
+-- Test: requests with 'header' as array --
+string(103) POST / HTTP/1.0
+Host: 127.0.0.1:12342
+Content-Length: 4
+X-Foo: bar
+Content-Type: text/plain
+
+ohai
+-- Test: requests with 'header' as string --
+string(103) POST / HTTP/1.0
+Host: 127.0.0.1:12342
+Content-Length: 4
+X-Foo: bar
+Content-Type: text/plain
+
+ohai
Index: ext/standard/http_fopen_wrapper.c
===
--- ext/standard/http_fopen_wrapper.c (Revision 283975)
+++ ext/standard/http_fopen_wrapper.c (Arbeitskopie)
@@ -391,7 +391,8 @@
}
}
smart_str_0(tmpstr);
- tmp = tmpstr.c;
+ /* Remove newlines and spaces from start and end.
there's at least one extra \r\n at the end that needs to go. */
+ tmp = php_trim(tmpstr.c, strlen(tmpstr.c), NULL, 0,
NULL, 3 TSRMLS_CC);
}
if (Z_TYPE_PP(tmpzval) == IS_STRING Z_STRLEN_PP(tmpzval)) {
/* Remove newlines and spaces from start and end
php_trim will estrndup() */
Index: ext/standard/tests/http/bug48929.phpt
===
--- ext/standard/tests/http/bug48929.phpt (Revision 0)
+++ ext/standard/tests/http/bug48929.phpt (Revision 0)
@@ -0,0 +1,56 @@
+--TEST--
+Bug #: duplicate \r\n sent after last header line
+--SKIPIF--
+?php require 'server.inc'; http_server_skipif('tcp://127.0.0.1:12342'); ?
+--FILE--
+?php
+require 'server.inc';
+
+function do_test($context_options) {
+
+ $context = stream_context_create(array('http' = $context_options));
+
+ $responses = array(
+ data://text/plain,HTTP/1.0 200 OK\r\n\r\n,
+ );
+
+ $pid = http_server(tcp://127.0.0.1:12342, $responses, $output);
+
+ foreach($responses as $r) {
+
+ $fd = fopen('http://127.0.0.1:12342/', 'rb', false, $context);
+
+ fseek($output, 0, SEEK_SET);
+ var_dump(stream_get_contents($output));
+ fseek($output, 0, SEEK_SET);
+ }
+
+ http_server_kill($pid);
+}
+
+echo -- Test: requests with 'header' as array --\n;
+
+do_test(array('header' = array('X-Foo: bar', 'Content-Type: text/plain'),
'method' = 'POST', 'content' = 'ohai'));
+
+echo -- Test: requests with 'header' as string --\n;
+
+do_test(array('header' = X-Foo: bar\r\nContent-Type: text/plain, 'method'
= 'POST', 'content' = 'ohai'));
+
+?
+--EXPECT--
+-- Test: requests with 'header' as array --
+string(103) POST / HTTP/1.0
+Host: 127.0.0.1:12342
+Content-Length: 4
+X-Foo: bar
+Content-Type: text/plain
+
+ohai
+-- Test: requests with 'header' as string --
+string(103) POST / HTTP/1.0
+Host: 127.0.0.1:12342
+Content-Length: 4
+X-Foo: bar
+Content-Type: text/plain
+
+ohai
Index: ext/standard/http_fopen_wrapper.c
===
--- ext/standard/http_fopen_wrapper.c (Revision 283973)
+++ ext/standard/http_fopen_wrapper.c (Arbeitskopie)
@@ -347,7 +347,8 @@
}
}
smart_str_0(tmpstr);
- tmp = tmpstr.c;
+ /* Remove newlines and spaces from start and end.
there's at least one extra \r\n at the end that needs to go. */
+
Re: [PHP-DEV] Soap over SSL and
On 07.07.2009, at 16:18, Brian A. Seklecki wrote: On Tue, 2009-07-07 at 15:42 +0200, endrazine wrote: It is lacking any type of authentication of the payment gateway, which is not acceptable. I agree+++. The problem is that PHP SOAP uses an internal streams library instead of libcurl; the former lacks, the later has, client/server PKI support. Nonsense. ext/soap has support for all of this through PHP's https stream which wraps the ssl stream. Please RT(F)M: http://php.net/manual/en/soapclient.soapclient.php http://php.net/manual/en/context.ssl.php In short: $c = new SoapClient( 'https://foo/bar.wsdl', array( 'stream_context = stream_context_create(array( 'ssl' = array( 'verify_peer' = true ) )) ) ); There is the whole range of options related to certs, including for CA certs etc. SoapClient itself has an option for a 'local_cert' as well. - David smime.p7s Description: S/MIME cryptographic signature
Re: [PHP-DEV] Soap over SSL and
On 10.07.2009, at 17:00, Hannes Magnusson wrote: On Fri, Jul 10, 2009 at 16:58, Uwe Schindlertheta...@php.net wrote: As far as I know, SOAP does not use the HTTP wrappers directly, it uses only sockets/ssl for communication (so the context applies only to the lower level SSL socket). So CURL is not used, because PHP's HTTP streams are not used. A. You are right. But that was because PHP streams didn't support chunked encoding, wasn't it? Dmitry: There is no reason why SOAP should be doing its own magic anylonger? Yes, that was the reason. http://article.gmane.org/gmane.comp.php.devel/53763 - David smime.p7s Description: S/MIME cryptographic signature
Re: [PHP-DEV] weak and strict type checking RFC
On 04.07.2009, at 14:27, Derick Rethans der...@php.net wrote:
So I would propose to:
1. have ilia's strict typing patch (minus scalar and numeric)
2. have a patch that also adds for casting type hints from your RFC.
Those could (and should) be considered as *two* new features.
As for syntax, I believe the following would be best:
function add_user(string $name, string $phone_number, (int) $age)
{ .. }
because:
1. the casting type hint (int) $var is used for normal casting
already
2. the strict type hint int $var is already used for class names
+1
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] SOAP_MARSHAL_DATETIME (or: bug #44383)
Hi folks,
attached is a patch (with the respective test cases) that implements
DateTime marshalling from and to xsd:dateTime in ext/soap as requested
in http://bugs.php.net/44383
Right now, it is implemented for xsd:date, xsd:time and xsd:dateTime,
but not for other types defined in W3C XML Schema such as gDayMonth; I
don't really think it makes sense mapping from and to DateTimes in
this case (from DateTime to gDayMonth would work, but the other way
round would prove rather difficult).
Some notes about this patch:
- it conforms strictly to the XML Schema specification by only
producing canonical representations of values when generating
xsd:dateTime and xsd:time values. Specifically:
- it will not generate trailing zeroes on microseconds (in other
words, it simply generates a fractional second part as mandated by the
specification), but it will accept such values
- UTC is always used as the timezone (one of the tests in ext/date/
tests that mirrors SBR1-echoDate from http://www.w3.org/TR/2007/REC-soap12-testcollection-20070427/#SBR1-echoDate
currently does this wrong), but it will accept any timezone
- xsd:time produces current date when generating a DateTime object
- xsd:date is relatively straightfoward as well:
- produces 00:00:00 as the time when creating a DateTime object
- accepts any time when parsing
- also supports timezones
- as a side effect of the patch, microseconds are now supported in
time values (for xsd:time and xsd:dateTime), hence the removed comment
in to_xml_time
The tests have several permutations, but all but one is commented out
each. The test_schema() function does some odd (but understandable)
stunts with output buffering and global variables that make it
impossible to test more than one case at a time. We didn't want to
produce a million test files for the several variants; is there a
nicer way to test this properly?
This feature is enabled by a SoapClient feature called
SOAP_MARSHAL_DATETIME. I think this is a reasonable choice.
Greetings,
David
schema089.phpt
Description: Binary data
? .DS_Store
? run-tests.php
? soap_marshal_datatype.diff.txt
? wsdlj2ZAlf
? tests/.DS_Store
? tests/bugs/.DS_Store
? tests/bugs/bug48557.phpt
? tests/bugs/bug48557.wsdl
? tests/schema/.DS_Store
? tests/schema/schema086.phpt
? tests/schema/schema087.phpt
? tests/schema/schema088.phpt
? tests/schema/schema089.phpt
? tests/schema/schema090.phpt
? tests/schema/schema091.phpt
Index: php_encoding.c
===
RCS file: /repository/php-src/ext/soap/php_encoding.c,v
retrieving revision 1.103.2.21.2.37.2.14
diff -u -r1.103.2.21.2.37.2.14 php_encoding.c
--- php_encoding.c 15 Jun 2009 17:31:02 - 1.103.2.21.2.37.2.14
+++ php_encoding.c 22 Jun 2009 12:42:22 -
@@ -27,6 +27,12 @@
#include libxml/parserInternals.h
#include zend_strtod.h
#include zend_interfaces.h
+#include ext/date/lib/timelib.h
+#include ext/date/php_date.h
+
+#ifdef PHP_WIN32
+# include win32/php_stdint.h
+#endif
/* zval type decode */
static zval *to_zval_double(encodeTypePtr type, xmlNodePtr data);
@@ -39,6 +45,7 @@
static zval *to_zval_null(encodeTypePtr type, xmlNodePtr data);
static zval *to_zval_base64(encodeTypePtr type, xmlNodePtr data);
static zval *to_zval_hexbin(encodeTypePtr type, xmlNodePtr data);
+static zval *to_zval_datetime(encodeTypePtr type, xmlNodePtr data);
static xmlNodePtr to_xml_long(encodeTypePtr type, zval *data, int style,
xmlNodePtr parent);
static xmlNodePtr to_xml_double(encodeTypePtr type, zval *data, int style,
xmlNodePtr parent);
@@ -60,7 +67,7 @@
static xmlNodePtr to_xml_list1(encodeTypePtr enc, zval *data, int style,
xmlNodePtr parent);
/* Datetime encode/decode */
-static xmlNodePtr to_xml_datetime_ex(encodeTypePtr type, zval *data, char
*format, int style, xmlNodePtr parent);
+static xmlNodePtr to_xml_datetime_ex(encodeTypePtr type, zval *data, int
style, xmlNodePtr parent, void (*format_func)(timelib_time *, smart_str *));
static xmlNodePtr to_xml_datetime(encodeTypePtr type, zval *data, int style,
xmlNodePtr parent);
static xmlNodePtr to_xml_time(encodeTypePtr type, zval *data, int style,
xmlNodePtr parent);
static xmlNodePtr to_xml_date(encodeTypePtr type, zval *data, int style,
xmlNodePtr parent);
@@ -146,9 +153,9 @@
{{XSD_FLOAT, XSD_FLOAT_STRING, XSD_NAMESPACE, NULL}, to_zval_double,
to_xml_double},
{{XSD_DOUBLE, XSD_DOUBLE_STRING, XSD_NAMESPACE, NULL}, to_zval_double,
to_xml_double},
- {{XSD_DATETIME, XSD_DATETIME_STRING, XSD_NAMESPACE, NULL},
to_zval_stringc, to_xml_datetime},
- {{XSD_TIME, XSD_TIME_STRING, XSD_NAMESPACE, NULL}, to_zval_stringc,
to_xml_time},
- {{XSD_DATE, XSD_DATE_STRING, XSD_NAMESPACE, NULL}, to_zval_stringc,
to_xml_date},
+ {{XSD_DATETIME, XSD_DATETIME_STRING, XSD_NAMESPACE, NULL},
to_zval_datetime, to_xml_datetime},
+ {{XSD_TIME, XSD_TIME_STRING,
[PHP-DEV] zend_hash_update question
Hi folks,
while fixing http://bugs.php.net/bug.php?id=48557 I was wondering why
zend_hash_update doesn't automatically convert numeric strings to
integers.
Doing $foo = array('1' = 'bar'); actually results in an integer key
with value 1, not in a string. The problem in the bug above was that
when ext/soap decodes keys from a hashmap, it won't convert numeric
string keys to integers. As a result, such items in an array were
never accessible from PHP code (that is, unless you did some
array_keys()/array_values() stunts, of course).
Is this intentional? It seems that every internal feature that would
like to deal with hashes needs to implement this string-int casting
behavior of PHP itself. Why doesn't zend_hash_update() do it
automatically?
Cheers,
David
smime.p7s
Description: S/MIME cryptographic signature
Re: [PHP-DEV] zend_hash_update question
On 15.06.2009, at 15:40, Matt Wilmas wrote:
Hi David,
Hey Matt,
- Original Message -
From: David Zülke
Sent: Monday, June 15, 2009
Hi folks,
while fixing http://bugs.php.net/bug.php?id=48557 I was wondering
why zend_hash_update doesn't automatically convert numeric strings
to integers.
Doing $foo = array('1' = 'bar'); actually results in an integer
key with value 1, not in a string. The problem in the bug above
was that when ext/soap decodes keys from a hashmap, it won't
convert numeric string keys to integers. As a result, such items
in an array were never accessible from PHP code (that is, unless
you did some array_keys()/array_values() stunts, of course).
Is this intentional? It seems that every internal feature that
would like to deal with hashes needs to implement this string-int
casting behavior of PHP itself. Why doesn't zend_hash_update() do
it automatically?
I saw the patch there for Bug #48557, and the is_numeric_string() +
zend_hash/index/_update() isn't necessary -- that's what
zend_symtable_update() is for. :-) It's used elsewhere and takes
care of checking for numeric string keys.
Aaah!
hash_update() used to do that until the symtable variation was
added several years ago, and there were places in PHP that weren't
updated and had this issue. Obviously there's still one at least!
(Or maybe that's newer code that simply used the wrong function in
the first place...)
Yeah I guess that's the case here.
I'm assuming hash_update() is intended to be an optimized version by
only working with strings, in places where it's already known -- in
the engine, walking through arrays where the type of key is already
known, etc.
Kinda confusing, but hope that helps. Seems like they should've
*added* a new function that does what hash_update() now does,
instead of basically renaming the old version to
symtable_update(). :-/
It does help, absolutely. Thanks a lot!
- David
smime.p7s
Description: S/MIME cryptographic signature
Re: [PHP-DEV] zend_hash_update question
Patch updated to reflect the change. It's against 5.3 btw. Now who
will commit it so it makes it into the next RC? :)
- David
On 15.06.2009, at 15:47, David Zülke wrote:
On 15.06.2009, at 15:40, Matt Wilmas wrote:
Hi David,
Hey Matt,
- Original Message -
From: David Zülke
Sent: Monday, June 15, 2009
Hi folks,
while fixing http://bugs.php.net/bug.php?id=48557 I was wondering
why zend_hash_update doesn't automatically convert numeric strings
to integers.
Doing $foo = array('1' = 'bar'); actually results in an integer
key with value 1, not in a string. The problem in the bug above
was that when ext/soap decodes keys from a hashmap, it won't
convert numeric string keys to integers. As a result, such items
in an array were never accessible from PHP code (that is, unless
you did some array_keys()/array_values() stunts, of course).
Is this intentional? It seems that every internal feature that
would like to deal with hashes needs to implement this string-
int casting behavior of PHP itself. Why doesn't
zend_hash_update() do it automatically?
I saw the patch there for Bug #48557, and the is_numeric_string() +
zend_hash/index/_update() isn't necessary -- that's what
zend_symtable_update() is for. :-) It's used elsewhere and takes
care of checking for numeric string keys.
Aaah!
hash_update() used to do that until the symtable variation was
added several years ago, and there were places in PHP that weren't
updated and had this issue. Obviously there's still one at least!
(Or maybe that's newer code that simply used the wrong function in
the first place...)
Yeah I guess that's the case here.
I'm assuming hash_update() is intended to be an optimized version
by only working with strings, in places where it's already known --
in the engine, walking through arrays where the type of key is
already known, etc.
Kinda confusing, but hope that helps. Seems like they should've
*added* a new function that does what hash_update() now does,
instead of basically renaming the old version to
symtable_update(). :-/
It does help, absolutely. Thanks a lot!
- David
smime.p7s
Description: S/MIME cryptographic signature
Re: [PHP-DEV] Re: Is it true that short_open_tag is deprecated in PHP 6?
As Jani put it:
PLEASE, let the dead horse be!
- David
On 14.04.2009, at 17:11, Arvids Godjuks wrote:
Hello everyone.
I've been writing ?php echo get('something')? for some time now at
the
last project and it really sucks. I understand reason on depricating
short_open_tag and I agree. But I have a proposal witch can ease
templating.
Remove short open tag, but leave ?=get('blah')?. Bacicaly PHP parser
should look for ?php or ?=, single ? is not allowed. That way:
1). short_open_tag is gone for good as an option in .ini.
2). Making templates doesn't suck
3). Backwards compability with old templates is preserved (old
templates
with ?= work fine).
4). ? in code is broken as you want it to be and makes coders fix
it with
?php
Everyone is happy, XML and others are safe.
Yes, it's really irritating to write ?php echo every time!
smime.p7s
Description: S/MIME cryptographic signature
Re: [PHP-DEV] New INIs, Round Two.
On 17.02.2009, at 08:02, Eric Stewart wrote: 10. The production value of error_reporting has been changed to E_ALL | ~E_DEPRECATED. I guess you mean E_ALL ~E_DEPRECATED smime.p7s Description: S/MIME cryptographic signature
Re: [PHP-DEV] RFC for new INI's
Am 10.02.2009 um 03:27 schrieb Eric Stewart: A new RFC for PHP's proposed INI files have been added to the wiki. Below is a direct link to the page. http://wiki.php.net/rfc/newinis For -development, display_errors should *definitely* be on, and error_reporting should be E_ALL | E_STRICT. auto_globals_jit shouldn't be on, IMO. - David smime.p7s Description: S/MIME cryptographic signature
Re: [PHP-DEV] towards the next 5.3 release
On 05.02.2009, at 17:32, Johannes Schlüter wrote:
On Wed, 2009-02-04 at 13:12 +0100, David Zülke wrote:
Am 03.02.2009 um 14:41 schrieb Lukas Kahwe Smith:
http://bugs.php.net/bug.php?id=47206 - XSLT
I looked through the CVS logs, could you confirm I understand it
right:
The type hint was added in 5.2.6, and will be gone again in 5.2.9, so
the only PHP releases with DOMDocument type hints there are 5.2.6,
5.2.7 and 5.2.8?
I think independently from what we do in 5.3 we will have
incompatibilities between versions here which can't be worked-around
in
userland (I don't consider if (version_compare(...)) { class ... }
else
{ class ... } a proper workaround)
So here are three choices:
- The DOMDoument typehint is certainly wrong.
- Adding an interface is lots of additional trouble (user code will
break again, no proper way for users to be 5.2 and 5.3 compatible)
- No typehint, as it is now, #47206 Expected / to be documented,
incompatible with 5.2.6-5.2.8 but compatible with most other 5.2
versions
After reading this thread and some limited private discussion I think
the last option is the best.
+1
smime.p7s
Description: S/MIME cryptographic signature
Re: [PHP-DEV] towards the next 5.3 release
Am 03.02.2009 um 14:41 schrieb Lukas Kahwe Smith: http://bugs.php.net/bug.php?id=47206 - XSLT I looked through the CVS logs, could you confirm I understand it right: The type hint was added in 5.2.6, and will be gone again in 5.2.9, so the only PHP releases with DOMDocument type hints there are 5.2.6, 5.2.7 and 5.2.8? Thanks, - David smime.p7s Description: S/MIME cryptographic signature
Re: [PHP-DEV] GSoC 2009
Am 25.01.2009 um 14:29 schrieb Lukas Kahwe Smith: On 24.01.2009, at 17:40, Ilia Alshanetsky wrote: I think our bug current tracker is pretty good and most importantly makes it easy to report and update bugs which is conducive to more issues being reported. Often extra features of bug trackers make them overly complex to use and people just get frustrated with them and don't report bugs as the result. Personally I think it would be nice to have some sort of milestone support. I think we already had that for a brief moment. I think it would make the bug tracker a very useful tool to see when something will be fixed and more importantly also for historical reasons. Then again we often shuffle around fixes from one branch to another .. so the trick is to make it possible prevent things to get out of whack. Maybe the bug tracker should be our interface to the NEWS file .. then again in order to be that, the solution would need to be super duper rock solid. But it could make the life of the RM's a lot easier. Absolutely. Also, a fix version would be really good, so people can know when a bug was fixed. Also, CVS/SVN post-commit hooks would be nice, so the tickets are annotated with links to the changesets. Right now, if I see someone's comment Fixed in CVS HEAD and PHP_5_3, I need to look at the date, then go to the cvs mailing list or logs and find the respective commit. Cumbersome. - David smime.p7s Description: S/MIME cryptographic signature
Re: [PHP-DEV] Re: GSoC 2009
I think that's a great idea. The normal weekly/bi-weekly reports could be CCed to internals@, with all discussion happening on gsoc@ - David Am 22.01.2009 um 09:04 schrieb Hannes Magnusson: On Thu, Jan 22, 2009 at 00:03, Elizabeth M Smith auroraeosr...@gmail.com wrote: I think we really should encourage at least two active mentors for each project this year. I think it helps both the students (always someone to annoy) and the mentors (less stress and time out of their lives) and provides a safety net if a mentor has real life issues come up. But for that we need more people willing to mentor ;) If we create a php-gsoc@ mailinglist where all the students and mentors, and everyone else who wants to follow the student work, and require students to post weekly/by-weekly status updates then there is no need. The community can then help the mentor out and we get more information about the projects. I still don't know what happened to many of the gsoc projects last year, despite my multiple inquires to the mentors of the projects, and haven't heard a beep from most of the students :( Lets keep it in the OSS style. Communicate in the open. -Hannes -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php smime.p7s Description: S/MIME cryptographic signature
Re: [PHP-DEV] [RFC] prototyping
Am 20.01.2009 um 18:41 schrieb Christian Seiler: Hi, maybe an IRC meeting is the easiest way to come to an agreement. How about tomorrow evening 21:00 CEST in #php.closures on freenode? Just for clarification: I assume you mean Wednesday, January 21st, 19:00 UTC (CEST == UTC+2) and thus 20:00 CET? Would be fine with me. I'm pretty confident he didn't mean summer time, so it's likely 21:00 CET or 20:00 UTC. smime.p7s Description: S/MIME cryptographic signature
Re: [PHP-DEV] [RFC] prototyping
Am 13.01.2009 um 22:58 schrieb Marcus Boerger:
5) A closure assigned to a property can be called directly rather
than just by a temporary variable:
$obj-property = function() {}
$obj-property(); // valid call
This will get us into trouble IMHO, as it would not behave too well
with
__get/__set and __call. I.e. if we have $foo-nosuchproperty() -
should we call __get or __call? So far variables implemented through
__get behave exactly like ones implemented through definition - but I
don't understand how to reconcile it with this.
Why would you call __get() here? Becasue I did that by mistake in my
very
first mail? You clearly have a function call and thus you only go for
__call(). As of today you can already do:
function __call($name, $args) {
if ($this-properties[$name] instanceof 'Closure') {
return call_user_func_array($this-property[$name], $args);
}
}
Now we already have callable properties - directly callable.
1. method
2. __call()
3. property
4. __get()
that would be a reasonable calling order, or:
1. method
2. property
3. __call()
4. __get()
In any case, a real method (existing one or __call() overload)
should have precedence over a closure in a property.
Wouldn't that work?
- David
smime.p7s
Description: S/MIME cryptographic signature
Re: [PHP-DEV] $_GET['a.b.c']
Am 13.01.2009 um 11:09 schrieb Alexey Zakhlestin: On Tue, Jan 13, 2009 at 12:32 PM, troels knak-nielsen troel...@gmail.com wrote: In a recent mail, some kind of issue regarding queryparams was mentioned (Possibly related to namespaces). Could anybody explain what the issue is, or point to where it's discussed? Currently, php replaces dots in paramter-names with underscores. This is a legacy of register_globals. Sure? foo|bar, foo-bar etc. don't get the same treatment... smime.p7s Description: S/MIME cryptographic signature
Re: [PHP-DEV] display_errors = on
Am 06.01.2009 um 16:52 schrieb Lukas Kahwe Smith: On 16.12.2006, at 19:50, Hannes Magnusson wrote: On 12/16/06, Derick Rethans der...@php.net wrote: On Fri, 15 Dec 2006, Andi Gutmans wrote: Time to turn it off in php.ini-dist in addition to php.ini- recommended? I would instead change them to php.ini-development and php.ini-production. In development you'd want to have this stuff on.. I think its time for a vote on that. We've been talking about it long enough. +1 ! ok warming up an old topic. it seems most people are in agreement that the above is a good idea. (so speak up if you think its a bad idea .. otherwise it just might happen ..) so it would be ok with us RM's if someone starts working on this ASAP .. this would essentially entail reviewing the current php.ini files we ship and giving good defaults for development and production. ideally this should be done with the beta1 release, because i envision there will be a bit of a need for discussion (especially from the side of the end users). I think this -development and -production approach is a good idea. Setting error_reporting to E_ALL | E_STRICT for development might be goood, too, while we're at it ;) - David smime.p7s Description: S/MIME cryptographic signature
Re: [PHP-DEV] [RFC] Re: [PHP-DEV] __invoke() weirdness
On 03.01.2009, at 15:47, Marcus Boerger wrote: However if that is the intention, then something we might want to look into in order to make it easier for those people is to fix something that propbably looks wrong to them. That is binding a closure to a property outside of the scope of the object does not bind the object to the this_ptr as it would in case the assignment is done inside the object scope (a class method). But once again this is somethign to be fixed whether or not we apply the patch. Yes, I was actually going to write another reply to one of your last mails about exactly that. Could that be done? I suppose it would be a good idea. However, what happens if you do the assignment from inside another class? Or is that $this currently not bound in such a case (I suppose it isn't, because that would be pretty confusing, but also pretty interesting in terms of what you can do with it). - David smime.p7s Description: S/MIME cryptographic signature
Re: [PHP-DEV] [RFC] Re: [PHP-DEV] __invoke() weirdness
Marcus,
thanks!
Why is it
Test::{closure}()
{closure}()
and not
Test::{closure}()
Test::{closure}()
in that test, though? Is it because func1() was there from the
Engine's POV after the ctor was called? AFAICT, that's the only
difference between the two.
Cheers,
- David
On 01.01.2009, at 17:50, Marcus Boerger wrote:
Hello David,
I added test closure_037.phpt to demonstrate this.
marcus
Thursday, January 1, 2009, 5:23:08 PM, you wrote:
Hi folks,
first of all, thank you Marcus for implementing this. Very cool.
As for the __get()/__getClosure() stuff, I don't think it's necessary
or even an issue. One can never simply do $this-
getOverloadPropertyWithInvoke() anyway, because if the prop is not
there, a fatal error would be the result. An __isset() call has to be
made first along with an (instanceof Closure ||
method_exists('__invoke')) check in userspace code.
Which brings me to the next question - will
$method = 'something';
$bar-$method();
work? Not sure if it's necessary; just curious for the most part.
- David
On 01.01.2009, at 17:06, Marcus Boerger wrote:
Hello Hannes,
as discussed online. At the moment we should not have any __get()
calls during method resolution. The newly updated patch does that
now. And I think we are now safe to submit.
In the future we could think of adding __getClosure() which would be
called to resolve a dynamic closure. But for the moment we do not
need
it badly and the patch with the increased consistency is good
enough.
marcus
Thursday, January 1, 2009, 4:09:39 PM, you wrote:
Hello Hannes,
Wednesday, December 31, 2008, 8:33:43 PM, you wrote:
On Wed, Dec 31, 2008 at 20:12, Marcus Boerger he...@php.net
wrote:
Hello Lars,
Wednesday, December 31, 2008, 6:59:08 PM, you wrote:
Hi Markus,
have you measured the performance impact in a class with - say -
ten
methods? And what to do with __get() and __call()? How are the
prioritized in the method resolve order?
Translated into user code we now have:
public function __zend_call($name, $args) {
// Added property lookup
if (isset($this-$name)) {// may call __isset
$callable = $this-$name; // may call __get
Uhmm. I hope I got this wrong as:
Well yes, there are no __isset() calls unless you call isset() of
course.
I have updated the patch and added a test to demonstrate it better
(closure_036.phpt). I also added debug information to closures
which makes
development much easier. The next step is to fix an issue in the
engine and
then submit unless there is a bigger issue with this.
class foo {
function __isset() {
return true;
}
function __get() {
return hello world;
}
function __call() {
}
}
$foo = new foo;
$foo-foobar();
will first execute __isset(), then __get() and then __call()? That
is
a major backwards compatibility break, and increases the
inconsistency
and decreases readability 10times
-Hannes
Best regards,
Marcus
Best regards,
Marcusze2-callable-properties-5.3-20090101-b.diff.txt--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Best regards,
Marcusze2-callable-properties-5.3-20090101-d.diff.txtze2-callable-
properties-6.0-20090101-d.diff.txt--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] __invoke() weirdness
On 25.12.2008, at 06:11, Lars Strojny wrote:
Hi David,
Am Dienstag, den 23.12.2008, 17:02 +0100 schrieb David Zülke:
[...]
This gives a fatal Call to undefined method DateTime::getAtom()
$d = new DateTime();
$d-getAtom = Curry::create(array($d, 'format'), DATE_ATOM);
echo $d-getAtom();
This is the same as the following:
$obj = new stdClass();
$obj-method = function() {
return foo;
};
$obj-method();
The first method is a property, the call to method is - well - a
method call. Because PHP separates methods and properties in the class
entry structure - and because we have magic methods like __set, __get
and __call, there is no efficient and logical way how to search for
properties with closure instances when a method is not found. We
discussed that before and decided to let closures go out into the wild
and think about adding a solution for prototype alike inheritance
later.
I realize that, but I guess it's pretty inconsistent, as I can do
- $func();
- $func-__invoke();
- $obj-func-__invoke();
but not
- $obj-func();
That was my point; I'm aware of potential reasons for this behavior
(like what Stas pointed out). Sorry for the confusion ;)
Is it going to be like this forever? Stas said there is no way to
distinguish. Isn't that a parser issue that should be gone now with
the switch to re2c? Wouldn't it be possible to just do a lookup for a
property that is an object with __invoke if the method was not found?
- David
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] __invoke() weirdness
Hi folks,
I played with __invoke today:
class Curry
{
protected $callable;
protected $args;
public static function create($callable)
{
$curry = new self($callable, array_slice(func_get_args(), 1));
return $curry;
}
protected function __construct($callable, $args)
{
$this-callable = $callable;
$this-args = $args;
}
public function __invoke()
{
return call_user_func_array($this-callable, array_merge($this-
args, func_get_args()));
}
}
However, it doesn't work consistently.
This works fine:
$d = new DateTime();
$getAtom = Curry::create(array($d, 'format'), DATE_ATOM);
echo $getAtom();
This gives a fatal Call to undefined method DateTime::getAtom()
$d = new DateTime();
$d-getAtom = Curry::create(array($d, 'format'), DATE_ATOM);
echo $d-getAtom();
Is that intentional?
Cheers,
David
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [RFC] Iteration tools
Am 03.11.2008 um 16:41 schrieb Marcus Boerger: 2) Ther are iterator_apply() owww that sounds like it really needs docs : smime.p7s Description: S/MIME cryptographic signature
Re: [PHP-DEV] namespaces and alpha3
Am 15.10.2008 um 09:04 schrieb Derick Rethans: As we're getting really close to 5.3, I would suggest to remove namespaces from this release as we're simply not done with even agreeing on how things should work. PHP 5.3 has many other cool things, and leaving namespaces for PHP 6 means we're actually introducing functionality there as well (for the folks that don't care about Unicode). We've done with namespaces for a lng time, and they've never really been *required*. Many people won't be able to use it any way as they have to support older PHP versions in their code base as well. PHP 6 is a much more natural switch for something like this. If we *absolutely *have* to* have namespaces, then we should go with the Namespaces without functions/constants proposal, with some tweaks. However, I still think it's not ready enough to put even that into 5.3. My thoughts exactly. I realize it's a bold move, but it's a much better alternative than the fuzz about an implementation that doesn't work, or is incomplete, or needs to be broken in the future to add new stuff. - David smime.p7s Description: S/MIME cryptographic signature
Re: [PHP-DEV] namespaces and alpha3
Am 14.10.2008 um 14:39 schrieb Steph Fox: Many people have starting working on top level application using namespaces, so there will a very bad buzz over the php community if namespaces are ripped out... People working with a development branch take their own chances. We keep BC for released code, not for dev code. I agree 100% smime.p7s Description: S/MIME cryptographic signature
Re: [PHP-DEV] namespaces and alpha3
Am 14.10.2008 um 14:10 schrieb Steph Fox: On 10 Oct 2008, at 06:03, Lukas Kahwe Smith wrote: 1) rip them out I'm +1 on this. We simply don't have consensus, and I don't see anyway we can have consensus by the time 5.3 has to be frozen. Once namespaces are in, we're gonna have to stick with whatever we choose, unless we totally break BC. I'd agree with this, leave something with such a big impact to version 6. At least it gives time to get it right. I'm +1 on ripping out and leaving til 6.0. +1 from me, too. Getting it right takes time. If that means 6.0, fine. smime.p7s Description: S/MIME cryptographic signature
Re: [PHP-DEV] namespaces and alpha3
I recommend you and your fellow programmers read the discussion again. It's nost just about syntax. On 14.10.2008, at 21:53, Arvids Godjuks wrote: People, why you just don't change the namespace separator to something except :: and sole all the problems one and for all? God damn, use : if you need - just push it out working! Most of my fellow programmers are just sick with reading internals discussing how to throw a feathure away because ambitity problem with :: can't be solved totaly. Me too, mostly I just skip namespace topics. Make a solid decision. Find the guts to change that misserable :: separator to something else (: for example) and be done with it - you are like children who can't deside whose toy is it with thouse namespaces! Take a break for 2-3 days and look back on what you are arguing about - you made a problem from nothing! Originaly no one thought about :: can be used with namespaces,now you are trying to fix it but you can't.This is a design issue, you can't solve it without breaking BC and getting everybody happy. By changing separator you will reach all goals at one shot - functions, classes, constants will be alowed in namespaces. That is what userland developers what. Give that to them! smime.p7s Description: S/MIME cryptographic signature
Re: [PHP-DEV] namespaces and alpha3
On 14.10.2008, at 21:20, Lukas Kahwe Smith wrote: On 14.10.2008, at 21:01, Steph Fox wrote: We are in alpha indeed, and still looking at proposals, and still without consensus. The last thing I'd want is to see namespace support pushed under the carpet, but I'd rather see it at this stage of development as part of the PHP 6 development cycle (as originally Why? What would happen then that can't happen now? What would happen if we give the namespace implementation a chance to mature is that it can be delivered as a fully-fledged language element rather than a partially-fledged and potentially flawed one. Both of these approaches have some uncleanness to them. If functions and constants get pushed to the global namespace while classes end up in the current namespace on include it can lead to some surprises. At the same time offering an ambiguous syntax to solve ambiguity when it occurs is also not beautiful. If we try out one of them in alpha3 and are unhappy I would not want an alpha4 to try out yet another one. But we will have the alpha3 either way at this point. So we could say lets try out the one that most people prefer for alpha3. If it sucks, we kick it out and move on. My fear is that once this is in a release (and even if it's just an alpha), the public pressure to keep it will be too big. Then we can alternatively push it to PHP 6 or drop the idea all together. I know that Dmitry and Greg were both thinking over alternative approaches, which did not yet come to a conclusion. Most of that revolves around other separators between or around namespaces. So we can keep cooking that. I believe everyone here will agree that this decision is pretty crucial. And if Dmitry and Greg have alternative approaches in the pipeline that need further pondering, then we should wait until they either finalized their proposals or declared them infeasible themselves. Why the rush. I really don't understand it. Please, no half-arsed compromises. Or, as this little green dude once said, do, or do not. there is no try. - David smime.p7s Description: S/MIME cryptographic signature
Re: [PHP-DEV] Disable PHAR by default
Totally hating to bring this up again (and hijacking this thread), but can we please enable ext/xsl by default in 5.3? : - David Am 29.09.2008 um 13:24 schrieb Marcus Boerger: Hello Jani, we're in alpha and fix all of those issues. in contrast to 99.9% of our users it is very easy for you to disable it. But the majority will only get the extension when we enable by default. And it is one of the big plans for 5.3 to finally support native packaging to make a lot of things easier. Once again if you don't like it, just disable it like you configure any of your installations specifically for your needs - others cannot. marcus Monday, September 29, 2008, 1:15:16 PM, you wrote: Seems like PHAR causes quite unexpected things, f.e. http://bugs.php.net/bug.php?id=46194 where PHP crashes if file does not exist. Please, can this crap be disabled by default (ALWAYS) and only those who actually need it can enable it? --Jani Best regards, Marcus -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php smime.p7s Description: S/MIME cryptographic signature
Re: [PHP-DEV] ext/soap and http header
just curious, why is ext/soap internally duplicating this http stuff
instead of using the http stream stuff directly? or did I
misunderstand something?
Am 29.09.2008 um 10:11 schrieb Dmitry Stogov:
Hi Brian,
I think you patch does the things you like properly, but why do we
need
such ability? I don't see a use-case.
In case of accepting this patch, we also need to care about duplicate
headers.
Thanks. Dmitry.
Brian J. France wrote:
After some more testing I needed to tweak the patch and the example,
here is version 2.
$opts = array('http' = array('header' = 'X-foo: bar'));
$ctx = stream_context_create($opts);
Brian
--- ext/soap/php_http.c.orig2008-09-26 05:39:50.0 -0700
+++ ext/soap/php_http.c2008-09-26 06:42:34.0 -0700
-391,7 +391,8 @@
PG(allow_url_fopen) = old_allow_url_fopen;
if (stream) {
-zval **cookies, **login, **password;
+php_stream_context *context = NULL;
+zval **cookies, **login, **password, **tmpzval = NULL;
int ret = zend_list_insert(phpurl, le_url);
add_property_resource(this_ptr, httpurl, ret);
-638,6 +639,19 @@
proxy_authentication(this_ptr, soap_headers TSRMLS_CC);
}
+/* get context to check for http headers */
+if (SUCCESS == zend_hash_find(Z_OBJPROP_P(this_ptr),
+ _stream_context,
sizeof(_stream_context),
(void**)tmp)) {
+context = php_stream_context_from_zval(*tmp, 0);
+}
+
+/* Send http headers from context */
+if (context
+php_stream_context_get_option(context, http, header,
tmpzval) == SUCCESS
+Z_TYPE_PP(tmpzval) == IS_STRING
Z_STRLEN_PP(tmpzval)) {
+smart_str_appendl(soap_headers, Z_STRVAL_PP(tmpzval),
Z_STRLEN_PP(tmpzval));
+}
+
/* Send cookies along with request */
if (zend_hash_find(Z_OBJPROP_P(this_ptr), _cookies,
sizeof(_cookies), (void **)cookies) == SUCCESS) {
zval **data;
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
smime.p7s
Description: S/MIME cryptographic signature
Re: [PHP-DEV] alpha3
+1, or: Do, or do not. There is no 'try.' - David On 28.09.2008, at 16:29, Steph Fox wrote: Hi Greg, The patch I posted here: http://pear.php.net/~greg/ns.element.patch.txt does exactly what you are talking about. For some reason, some people find this too difficult to digest. I've already expressed my opinion on the matter (after all, I did spend almost a week developing the patch). OK, I'll bite. First off, I find '-' just as much as potential source of confusion as '::', and for the exact same reason: it's already used to express a relationship in PHP. All this says to me is we still don't have the right ns separator. It's clear that PHP 5.3 shouldn't go out with '::' as the ns separator even if only classes are supported, despite the fact that the current implementation appears solid in every other respect at that level. It can't go out that way because we already know there will be huge user pressure to extend namespace support beyond classes. This wasn't part of the original remit, but we now know we need to allow for it before ns support is part of an official release. It's equally clear (to me at least) that having two ways to express a namespaced element depending on context would be a Bad Thing [TM]. The only reason that's even come up for consideration is the ambiguity caused by the ns separator we already have. Basically, I think you're trying to find solutions to the wrong problem, since at present ns support doesn't exist in any official PHP release. Your approach assumes a BC consideration that (thankfully) doesn't exist yet. I don't want to see that whole ns separator debate all over again any more than you do, but I really don't see a good way to avoid it... sorry. And if that means introducing a new symbol... it can't really be staved off until 6.0, unless we don't care about 6.0 code not running under 5.3. The other option of course would be to say ns support will **never** be extended beyond classes, and actually mean it. - Steph -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php smime.p7s Description: S/MIME cryptographic signature
Re: [PHP-DEV] namespace issues
Am 22.09.2008 um 21:45 schrieb Stanislav Malyshev: On the ZendCon, we (Marcus, Elizabeth, Andi and myself) had a talk about what we'd like to do with namespaces, and we arrived at the following conclusions, which we propose to implement in 5.3: 1. Allow braces for namespaces. So, the syntax for namespaces will be: 2. Simplify resolution order for classes in the namespace: unqualified names are resolved this way: 3. Functions will not be allowed inside namespaces. Comments? +1 - David -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [Fwd: [PATCH] Backport of HEADs output API]
Am 18.09.2008 um 21:02 schrieb Michael Wallner: In case the original with patches attached doesn't get through: http://dev.iworks.at/PATCHES/php53-backport_output.txt http://dev.iworks.at/PATCHES/pecl-backport_output.txt Isn't there a typo in colorer.cpp: +php_outout_get_contents(return_value); shouldn't that be + php_output_get_contents(return_value); - David smime.p7s Description: S/MIME cryptographic signature
Re: [PHP-DEV] How does a PHP array become an XML document for use by a SoapClient?
On 17.09.2008, at 22:24, Richard Quadling wrote: Hi. Where can I find out how a PHP array gets converted to an XML document for transmission using SOAP using a WDSL file? Ideally I would like to see some sort of trace of the conversion process. I'm helping someone else. They seem to be doing everything correctly but a chunk of the XML file is missing and this is generating an error when it gets to the other end. Richard, there's a dedicated SOAP mailing list, as well as the general mailing list, for these specific questions. Having used SOAP extensively both as client and server, I can say that PHP's SOAP support has come a long way in terms of stability. It's pretty likely a mistake on their end. I'll be happy to look at the problem if you (or they) post it over at the SOAP list. Cheers, David smime.p7s Description: S/MIME cryptographic signature
Re: [PHP-DEV] ext/soap ctor errors
Am 29.08.2008 um 13:11 schrieb Lukas Kahwe Smith:
On 13.08.2008, at 14:31, David Zülke wrote:
Am 08.08.2008 um 09:39 schrieb Dmitry Stogov:
Hi,
I took a quick look into the issue and I didn't found a problem.
SoapClient constructor already throws exceptions in case of WSDL
errors.
?php
try {
new SoapClient(non-existent);
} catch (Exception $e) {
echo CATCHED: .$e-getMessage().\n;
}
Warning: SoapClient::SoapClient(): I/O warning : failed to load
external entity non-existent in Command line code on line 1
CATCHED: SOAP-ERROR: Parsing WSDL: Couldn't load from 'non-
existent' : failed to load external entity non-existent
SoapServer does fatal errors, but it souldn't be a problem,
because servers use their own WSDL files which may be fixed.
Thanks. Dmitry.
True, it indeed does since 5.3... but what about that warning; does
it have to be raised at all? if the exceptions option is passed?
Maybe a general question (not sure if its in time to address this
stuff for 5.3.0).
We are getting more and more extensions with an exception mode. I
guess PDO is the rolemodel here and in absence of a discussion about
this it seems like we have accepted this sort of behavior. But what
I wonder is if such exception modes should mean that if an
exception is thrown for a specific issue, if this should then
disable warnings/notices/errors that would be raised for the same
issue.
Yes, it should IMO.
David
smime.p7s
Description: S/MIME cryptographic signature
Re: [PHP-DEV] __getStatic
Am 22.08.2008 um 14:08 schrieb George Antoniadis: I thought this had allready been denied, or am I wrong? Also can new features still be implemented for 5.3? Isn't that closed? Don't get me wrong, I SO want this feature! :P The mail below explicitly states that both release managers have given their okay for implementing any missing __magicStatic() methods... read the mail again! - David P.S: top posting is evil G. On Wed, Aug 20, 2008 at 7:39 PM, Lukas Kahwe Smith [EMAIL PROTECTED]wrote: On 15.08.2008, at 12:06, Marcus Boerger wrote: Hello Timm, Friday, August 15, 2008, 12:44:19 AM, you wrote: Hi again, Attached you'll find an incomplete patch against PHP_5_3 to add this functionality. If you like it let me know and I can finish it. Darn, seems the list didn't like my text/plain attachment. Well, here we go: http://sitten-polizei.de/php/get-static.diff Patch looks pretty good. Plaease add __issetStatic and __unsetStatic. Then provide tests and submit to HEAD. For 5.3 Lukas and Johannes have to agree but I am sure they first want to see it in HEAD. Hope we havent missed any other we need to make this stuff complete .. But here is the blessing of the two RM's to have this committed before the alpha2 release .. regards, Lukas Kahwe Smith [EMAIL PROTECTED] -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] bug #43941
Am 21.08.2008 um 03:34 schrieb William A. Rowe, Jr.: Stanislav Malyshev wrote: Hi! Are there any objections to incorporating bugfix for #43941 (fix for how json handles invalid UTF-8 sequences) into 5.2? I had some requests about it, right now it's only in 5.3+. Is there the alternative of substituting an unmappable character FFFD in place of the invalid sequence? This a a reasonable alternative behavior for some less stringent cases. (Yes, the fix is better than the status quo, but just taking this a step further). I agree, that would be quite reasonable and also more consistent with how UTF-8 works in other apps (browsers etc). David -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] bug #43941
Am 21.08.2008 um 18:08 schrieb Rasmus Lerdorf: David Zülke wrote: Am 21.08.2008 um 03:34 schrieb William A. Rowe, Jr.: Stanislav Malyshev wrote: Hi! Are there any objections to incorporating bugfix for #43941 (fix for how json handles invalid UTF-8 sequences) into 5.2? I had some requests about it, right now it's only in 5.3+. Is there the alternative of substituting an unmappable character FFFD in place of the invalid sequence? This a a reasonable alternative behavior for some less stringent cases. (Yes, the fix is better than the status quo, but just taking this a step further). I agree, that would be quite reasonable and also more consistent with how UTF-8 works in other apps (browsers etc). Well, using browsers as the benchmark here is a bad idea. IE is absolutely braindead about dealing with illegal UTF-8 chars. It will accept just about any sequence of bytes as a valid UTF-8 char which causes all sorts of problems. I was talking about the common representation of an invalid sequence. That's the question mark sign you usually see in a browser when the encoding is incorrect. According to the Unicode standard, U+FFFD is supposed to be used as the replacement character instead of simply stripping invalid ones: Replacement Character. A character used as a substitute for an uninterpretable character from another encoding. The Unicode Standard uses U+FFFD replacement character for this function. says http://unicode.org/glossary/#replacement_character Rendering software which cannot process a Unicode character appropriately most often display it as only an open rectangle, or the Unicode “replacement character” (U+FFFD, �), to indicate the position of the unrecognized character. says http://en.wikipedia.org/wiki/Unicode#Standardized_subsets Also see http://www.fileformat.info/info/unicode/char/fffd/index.htm As always, I consider sticking to specs good practice, so doing it in the above case would be wise :) Hope that helps, David -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] bug #43941
Am 21.08.2008 um 18:41 schrieb Rasmus Lerdorf: David Zülke wrote: Am 21.08.2008 um 18:08 schrieb Rasmus Lerdorf: David Zülke wrote: Am 21.08.2008 um 03:34 schrieb William A. Rowe, Jr.: Stanislav Malyshev wrote: Hi! Are there any objections to incorporating bugfix for #43941 (fix for how json handles invalid UTF-8 sequences) into 5.2? I had some requests about it, right now it's only in 5.3+. Is there the alternative of substituting an unmappable character FFFD in place of the invalid sequence? This a a reasonable alternative behavior for some less stringent cases. (Yes, the fix is better than the status quo, but just taking this a step further). I agree, that would be quite reasonable and also more consistent with how UTF-8 works in other apps (browsers etc). Well, using browsers as the benchmark here is a bad idea. IE is absolutely braindead about dealing with illegal UTF-8 chars. It will accept just about any sequence of bytes as a valid UTF-8 char which causes all sorts of problems. I was talking about the common representation of an invalid sequence. That's the question mark sign you usually see in a browser when the encoding is incorrect. Yes, but it all comes down to how you do it. Say you have a 3 byte sequence that starts with 0xE0 (E0 indicates the start of a 3-byte utf-8 char) but the 3 bytes together don't actually make up a valid utf-8 char. Id you substitute those 3 bytes with a ? or some other character you have just created a nasty XSS vector for web apps. You don't substitute it with a ? or some other character, you replace it with U+FFFD (0xEF 0xBF 0xBD in UTF-8). I'd love to hear how that causes an attack vector. David -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
