Re: [PHP-DEV] [HEADS UP] pecl/phar is now ext/phar
On Mon, May 12, 2008 at 11:45 PM, Gregory Beaver [EMAIL PROTECTED] wrote: * code coverage is pushing 80%, up from about 63% Are these known failures? Number of tests : 377 364 Tests skipped : 13 ( 3.4%) Tests warned:0 ( 0.0%) ( 0.0%) Tests failed: 256 ( 67.9%) ( 70.3%) Tests passed: 108 ( 28.6%) ( 29.7%) - Time taken : 52 seconds = = FAILED TEST SUMMARY - Phar::chmod [ext/phar/tests/033.phpt] Phar::chmod [ext/phar/tests/033a.phpt] Phar: addFile/addFromString [ext/phar/tests/addfuncs.phpt] Phar: alias edge cases [ext/phar/tests/alias_acrobatics.phpt] Phar: bad parameters to various methods [ext/phar/tests/badparameters.phpt] Phar: SLOW TEST bug #13727: Number of files in the Phar limited to 2042 [ext/phar/tests/bug13727.phpt] Phar: bug #13786: PHP crashes on phar recreate after unlink [ext/phar/tests/bug13786.phpt] Phar: create and modify phar [ext/phar/tests/create_new_and_modify.phpt] Phar: create a completely new phar [ext/phar/tests/create_new_phar.phpt] Phar: create a completely new phar [ext/phar/tests/create_new_phar_c.phpt] Phar: create with illegal path [ext/phar/tests/create_path_error.phpt] Phar: mkdir/rmdir test [ext/phar/tests/dir.phpt] Phar: test edge cases of file_get_contents() function interception [ext/phar/tests/fgc_edgecases.phpt] Phar: test file_get_contents() interception [ext/phar/tests/file_get_contents.phpt] Phar: test fopen() interception [ext/phar/tests/fopen.phpt] Phar: fopen/stat/fseek/unlink/rename edge cases [ext/phar/tests/fopen_edgecases.phpt] Phar: test edge cases of fopen() function interception #2 [ext/phar/tests/fopen_edgecases2.phpt] Phar front controller rewrite access denied [ext/phar/tests/frontcontroller10.phpt] Phar front controller mime type extension is not a string [ext/phar/tests/frontcontroller11.phpt] Phar front controller mime type unknown int [ext/phar/tests/frontcontroller12.phpt] Phar front controller mime type not string/int [ext/phar/tests/frontcontroller13.phpt] Phar front controller mime type override, Phar::PHPS [ext/phar/tests/frontcontroller15.phpt] Phar front controller mime type override, Phar::PHP [ext/phar/tests/frontcontroller16.phpt] Phar front controller PHP test [ext/phar/tests/frontcontroller2.phpt] Phar front controller $_SERVER munging success [ext/phar/tests/frontcontroller21.phpt] Phar front controller include from cwd test 1 [ext/phar/tests/frontcontroller22.phpt] Phar front controller with generic action router test [ext/phar/tests/frontcontroller23.phpt] Phar front controller with custom 404 php script [ext/phar/tests/frontcontroller24.phpt] Phar front controller with extra path_info [ext/phar/tests/frontcontroller25.phpt] Phar front controller with no extension [ext/phar/tests/frontcontroller27.phpt] Phar front controller with huge file [ext/phar/tests/frontcontroller28.phpt] Phar front controller with fatal error in php file [ext/phar/tests/frontcontroller29.phpt] Phar front controller phps [ext/phar/tests/frontcontroller3.phpt] Phar front controller with invalid callback for rewrites [ext/phar/tests/frontcontroller31.phpt] Phar front controller with valid callback that is not good [ext/phar/tests/frontcontroller32.phpt] Phar front controller with valid callback that does not return any value [ext/phar/tests/frontcontroller33.phpt] Phar front controller with cwd [ext/phar/tests/frontcontroller34.phpt] Phar front controller rewrite array [ext/phar/tests/frontcontroller9.phpt] Phar: include_path with phar:// wrapper [ext/phar/tests/include_path.phpt] Phar: set alias with invalid alias containing / \ : or ; [ext/phar/tests/invalid_alias.phpt] Phar: invalid set alias or stub via array access [ext/phar/tests/invalid_setstubalias.phpt] phar: mkdir/rmdir edge cases [ext/phar/tests/mkdir.phpt] Phar: mounted manifest directory test [ext/phar/tests/mounteddir.phpt] Phar: fopen a .phar for writing (existing file) [ext/phar/tests/open_for_write_existing.phpt] Phar: fopen a .phar for writing (new file) [ext/phar/tests/open_for_write_newfile.phpt] Phar: test opendir() interception [ext/phar/tests/opendir.phpt] Phar: test edge cases of opendir() function interception [ext/phar/tests/opendir_edgecases.phpt] Phar::startBuffering()/setStub()/stopBuffering() [ext/phar/tests/phar_begin_setstub_commit.phpt] Phar::buildFromDirectory() - readonly [ext/phar/tests/phar_buildfromdirectory1.phpt] Phar::buildFromDirectory() - non-directory passed as first parameter [ext/phar/tests/phar_buildfromdirectory2.phpt] Phar::buildFromDirectory() - object passed as second parameter [ext/phar/tests/phar_buildfromdirectory3.phpt] Phar::buildFromDirectory(), directory exists [ext/phar/tests/phar_buildfromdirectory4.phpt]
Re: [PHP-DEV] [HEADS UP] pecl/phar is now ext/phar
On 13.05.2008 01:45, Gregory Beaver wrote:
Thanks to all who have contributed, particularly Marcus, Steph, Lars,
and the others who chimed in with ideas on the list.
phar_detect_phar_fname_ext() fails if is_complete = 1 and filename contains ..
For example:
Breakpoint 1, phar_detect_phar_fname_ext (filename=0x124db80
/local/qa/5_3.zts/ext/phar/tests/DataArchive.phar, check_length=1,
ext_str=0x7fff44a08fd8,
ext_len=0x7fff44a08fcc, executable=1, for_create=0, is_complete=1,
tsrm_ls=0xf5b0c0) at /local/qa/5_3.zts/ext/phar/phar.c:1557
1557int filename_len = strlen(filename);
(gdb)
..skip..
1651switch (phar_check_str(filename, *ext_str, *ext_len,
executable, for_create TSRMLS_CC)) {
(gdb)
1656if (is_complete) {
(gdb)
1657return FAILURE;
(gdb) p *ext_str
$9 = 0x124db8d .zts/ext/phar/tests/DataArchive.phar
This causes numerous test failures:
Tests failed: 214 ( 56.8%) ( 58.8%)
Tests passed: 150 ( 39.8%) ( 41.2%)
--
Wbr,
Antony Dovgal
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] SplFileObject with include_path
Hi, I'm working on a SOAP project and as part of the checks I make are the existence and readability of the WSDL file. As far as I saw, SoapClient doesn't check include_path for the WSDL file, so I thought I could use fopen to check this and then find the real path which would be finally passed to the SoapClient constructor. The problem with fopen is that I don't know how to find the real path if the file does exist in the include_path. So I took a look at SplFileObject, whose constructor accepts the same parameters as fopen. Here's my issue. If I instantiate SplFileObject like: $file = new SplFileObject($filename, 'r', true); and $filename is found somewhere on the include_path, wouldn't be useful if a call to SplFileObject::getRealPath() would return the actual real path and not false? Because at this point it doesn't. -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [HEADS UP] pecl/phar is now ext/phar
Hannes, Are these known failures? Guess the configure line? I can't reproduce this with default settings. - Steph Number of tests : 377 364 Tests skipped : 13 ( 3.4%) Tests warned:0 ( 0.0%) ( 0.0%) Tests failed: 256 ( 67.9%) ( 70.3%) Tests passed: 108 ( 28.6%) ( 29.7%) - Time taken : 52 seconds = = FAILED TEST SUMMARY - Phar::chmod [ext/phar/tests/033.phpt] Phar::chmod [ext/phar/tests/033a.phpt] Phar: addFile/addFromString [ext/phar/tests/addfuncs.phpt] Phar: alias edge cases [ext/phar/tests/alias_acrobatics.phpt] Phar: bad parameters to various methods [ext/phar/tests/badparameters.phpt] Phar: SLOW TEST bug #13727: Number of files in the Phar limited to 2042 [ext/phar/tests/bug13727.phpt] Phar: bug #13786: PHP crashes on phar recreate after unlink [ext/phar/tests/bug13786.phpt] Phar: create and modify phar [ext/phar/tests/create_new_and_modify.phpt] Phar: create a completely new phar [ext/phar/tests/create_new_phar.phpt] Phar: create a completely new phar [ext/phar/tests/create_new_phar_c.phpt] Phar: create with illegal path [ext/phar/tests/create_path_error.phpt] Phar: mkdir/rmdir test [ext/phar/tests/dir.phpt] Phar: test edge cases of file_get_contents() function interception [ext/phar/tests/fgc_edgecases.phpt] Phar: test file_get_contents() interception [ext/phar/tests/file_get_contents.phpt] Phar: test fopen() interception [ext/phar/tests/fopen.phpt] Phar: fopen/stat/fseek/unlink/rename edge cases [ext/phar/tests/fopen_edgecases.phpt] Phar: test edge cases of fopen() function interception #2 [ext/phar/tests/fopen_edgecases2.phpt] Phar front controller rewrite access denied [ext/phar/tests/frontcontroller10.phpt] Phar front controller mime type extension is not a string [ext/phar/tests/frontcontroller11.phpt] Phar front controller mime type unknown int [ext/phar/tests/frontcontroller12.phpt] Phar front controller mime type not string/int [ext/phar/tests/frontcontroller13.phpt] Phar front controller mime type override, Phar::PHPS [ext/phar/tests/frontcontroller15.phpt] Phar front controller mime type override, Phar::PHP [ext/phar/tests/frontcontroller16.phpt] Phar front controller PHP test [ext/phar/tests/frontcontroller2.phpt] Phar front controller $_SERVER munging success [ext/phar/tests/frontcontroller21.phpt] Phar front controller include from cwd test 1 [ext/phar/tests/frontcontroller22.phpt] Phar front controller with generic action router test [ext/phar/tests/frontcontroller23.phpt] Phar front controller with custom 404 php script [ext/phar/tests/frontcontroller24.phpt] Phar front controller with extra path_info [ext/phar/tests/frontcontroller25.phpt] Phar front controller with no extension [ext/phar/tests/frontcontroller27.phpt] Phar front controller with huge file [ext/phar/tests/frontcontroller28.phpt] Phar front controller with fatal error in php file [ext/phar/tests/frontcontroller29.phpt] Phar front controller phps [ext/phar/tests/frontcontroller3.phpt] Phar front controller with invalid callback for rewrites [ext/phar/tests/frontcontroller31.phpt] Phar front controller with valid callback that is not good [ext/phar/tests/frontcontroller32.phpt] Phar front controller with valid callback that does not return any value [ext/phar/tests/frontcontroller33.phpt] Phar front controller with cwd [ext/phar/tests/frontcontroller34.phpt] Phar front controller rewrite array [ext/phar/tests/frontcontroller9.phpt] Phar: include_path with phar:// wrapper [ext/phar/tests/include_path.phpt] Phar: set alias with invalid alias containing / \ : or ; [ext/phar/tests/invalid_alias.phpt] Phar: invalid set alias or stub via array access [ext/phar/tests/invalid_setstubalias.phpt] phar: mkdir/rmdir edge cases [ext/phar/tests/mkdir.phpt] Phar: mounted manifest directory test [ext/phar/tests/mounteddir.phpt] Phar: fopen a .phar for writing (existing file) [ext/phar/tests/open_for_write_existing.phpt] Phar: fopen a .phar for writing (new file) [ext/phar/tests/open_for_write_newfile.phpt] Phar: test opendir() interception [ext/phar/tests/opendir.phpt] Phar: test edge cases of opendir() function interception [ext/phar/tests/opendir_edgecases.phpt] Phar::startBuffering()/setStub()/stopBuffering() [ext/phar/tests/phar_begin_setstub_commit.phpt] Phar::buildFromDirectory() - readonly [ext/phar/tests/phar_buildfromdirectory1.phpt] Phar::buildFromDirectory() - non-directory passed as first parameter [ext/phar/tests/phar_buildfromdirectory2.phpt] Phar::buildFromDirectory() - object passed as second parameter [ext/phar/tests/phar_buildfromdirectory3.phpt] Phar::buildFromDirectory(), directory exists [ext/phar/tests/phar_buildfromdirectory4.phpt] Phar::buildFromDirectory() with matching regex
Re: [PHP-DEV] [HEADS UP] pecl/phar is now ext/phar
On 13.05.2008 15:57, Steph Fox wrote: Hannes, Are these known failures? Guess the configure line? I can't reproduce this with default settings. See my mail about phar_detect_phar_fname_ext(), it might be the same problem. -- Wbr, Antony Dovgal -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [HEADS UP] pecl/phar is now ext/phar
On Tue, May 13, 2008 at 1:57 PM, Steph Fox [EMAIL PROTECTED] wrote: Hannes, Are these known failures? Guess the configure line? I can't reproduce this with default settings. './configure' \ '--enable-debug' \ '--with-zend-vm=GOTO' \ '--without-pear' \ '--with-zlib' \ '--with-bz2' \ '--with-openssl' \ '--with-mysql=mysqlnd' \ '--with-mysqli=mysqlnd' \ '--enable-intl' \ '--enable-phar' \ '--with-xsl' \ '--with-curl' \ '--enable-zip' \ and default php.ini. Yes. I did ./cvsclean and obviously ./buildconf Looks like the buildtest-process script (or php.qa.reports) is rejecting the failure report.. probably due to the size of the report -Hannes -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [HEADS UP] pecl/phar is now ext/phar
and default php.ini. Yes. I did ./cvsclean and obviously ./buildconf Looks like the buildtest-process script (or php.qa.reports) is rejecting the failure report.. probably due to the size of the report Sorry Hannes, should've kept it on-list. The clue was in Tony's mail, I'm just testing a fix now. - Steph -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
Re: [PHP-DEV] [HEADS UP] pecl/phar is now ext/phar
Sorry Hannes, should've kept it on-list. The clue was in Tony's mail, I'm just testing a fix now. Access denied, insufficient karma. Fix is in PECL CVS, what do I do now? Mail in a patch against 5_3? - Steph -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Class Properties in Interfaces?
Hello Richard,
Monday, May 12, 2008, 5:03:39 PM, you wrote:
2008/5/12 Marcus Boerger [EMAIL PROTECTED]:
Hello Richard,
Wednesday, May 7, 2008, 3:33:24 PM, you wrote:
2008/5/7 Jeff Moore [EMAIL PROTECTED]:
On May 6, 2008, at 12:45 PM, Marcus Boerger wrote:
public $property {
__get = getProperty;
__set = setProperty;
}
string public function getProperty() {
return $this-_property;
}
string protected function setProperty(string $value) {}
Hi Marcus,
I prefer this approach.
One advantage is that it is compatible with existing classes that have
done
the getXXX() style accessors already.
One thing That I am hoping to avoid, though, is the need to declare these
kinds of basic accessor methods at all. (the ones that do nothing but set
or read a backing property.) it seems like PHP should be able to generate
them, or just fallback into a simple property access on the backing store,
if that store is specified as part of the property.
This should be the same as the previous example replacing setProperty and
getProperty with direct references to the backing store:
protected $_property;
public $property {
__get = $_property;
__set = $_property;
}
Or do we force people to always specify
get,set,isset und unset? Or should we only enforce get/set and have isset
and unset emulated with them (isset()~isset(get()), unset()~set(NULL))?
it would be nice to have exactly this emulation for __isset and __unset
when they are not declared.
However, leaving out the __set should make the property read only and
leaving out the __get should make the property write only (less useful, but
symmetric).
Following the C# convention for declaring properties in interfaces would
declare the previous as
interface bar {
public $property {__set; __get;}
}
Best Regards,
Jeff
If the interface iFoo says property bar must be implemented, then it
would seem inappropriate to allow the unsetting of property bar.
Why? Unset would simply set the storage to NULL, not undeclare it.
My reasoning is that the interface says this is how all objects
implementing this interface look (the contract), then allowing one of
the instances to remove the property breaks the contract.
If you follow this (I hope someone does), then as a consequence, isset
now becomes slightly different in that it is behaving more like an
empty().
Regards,
Richard.
For scalars and accessible properties, unset() does indeed undeclare
the scalar/property.
?php
$foo = 'bar';
echo $foo;
unset($foo);
echo $foo;
?
results in Notice: Undefined variable: foo in C:\- on line 5
This is correct.
and
?php
class foo {
public $bar;
public function __construct() {
$this-bar = 'snafu';
}
}
$o_Foo = new foo();
echo $o_Foo-bar;
unset($o_Foo-bar);
echo $o_Foo-bar;
?
outputs ...
snafu
Notice: Undefined property: foo::$bar in C:\- on line 13
At this point you found an error. Because this allows unset() to modify an
instance in a way that it nolonger adheres to its class that means at this
point the following is nolonger valid: $o_Foo is-a foo. And that is the
basic design rule we chose for PHP. Please file as a bug!
But if the property is part of an interface, then allowing the
property to be undeclared would seem to me to be breaking the
contract.
Say $bar is in iFoo.
We would expect if ($someobj implements iFoo) then $someobj-bar to
exist. The interface says it does. If it has been removed, then the
interface is lying or the contract isn't as strong as is expected.
If we are saying that unset() on an interfaced property works
differently to unset on scalars/normal properties then seems
potentially confusing.
Richard.
Best regards,
Marcus
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] SplFileObject with include_path
Hello Ionut, file as bug please. marcus Tuesday, May 13, 2008, 12:37:45 PM, you wrote: Hi, I'm working on a SOAP project and as part of the checks I make are the existence and readability of the WSDL file. As far as I saw, SoapClient doesn't check include_path for the WSDL file, so I thought I could use fopen to check this and then find the real path which would be finally passed to the SoapClient constructor. The problem with fopen is that I don't know how to find the real path if the file does exist in the include_path. So I took a look at SplFileObject, whose constructor accepts the same parameters as fopen. Here's my issue. If I instantiate SplFileObject like: $file = new SplFileObject($filename, 'r', true); and $filename is found somewhere on the include_path, wouldn't be useful if a call to SplFileObject::getRealPath() would return the actual real path and not false? Because at this point it doesn't. Best regards, Marcus -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] Re: [HEADS UP] pecl/phar is now ext/phar
Hi, On Mon, 2008-05-12 at 16:45 -0500, Gregory Beaver wrote: It's time for helly's birthday present from me (and indirectly, Derick, who did the cp -r) :). As Johannes requested, pecl/phar has been copied to php-src/ext/phar, Great work! :-) johannes -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Class Properties in Interfaces?
Marcus Boerger wrote: unset($o_Foo-bar); echo $o_Foo-bar; ? outputs ... Notice: Undefined property: foo::$bar in C:\- on line 13 At this point you found an error. Because this allows unset() to modify an instance in a way that it nolonger adheres to its class that means at this point the following is nolonger valid: $o_Foo is-a foo. And that is the basic design rule we chose for PHP. Please file as a bug! So you are saying that $o_Foo-bar = array(42); is ok when the class expects a string but unset($o_Foo-bar); or (as as slight variation) $o-Foo-bar = null; is not? I'd ask not to change this behaviour as you'll just add another (IMHO bogus) restriction on how an object or class can be modified at runtime. An error possibly caused by this is already handled by the E_NOTICE message anyway. For comparison: Having to declare static class variables is a similar restriction which got in my way more often than it helped me. - Chris -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [HEADS UP] pecl/phar is now ext/phar
You should try again, karma should be there, now. Thanks Johannes :) Hannes, let me know if. - Steph -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [HEADS UP] pecl/phar is now ext/phar
On Tue, 2008-05-13 at 14:41 +0100, Steph Fox wrote: Sorry Hannes, should've kept it on-list. The clue was in Tony's mail, I'm just testing a fix now. Access denied, insufficient karma. Fix is in PECL CVS, what do I do now? Mail in a patch against 5_3? You should try again, karma should be there, now. johannes -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [HEADS UP] pecl/phar is now ext/phar
On Tue, May 13, 2008 at 4:14 PM, Steph Fox [EMAIL PROTECTED] wrote: You should try again, karma should be there, now. Thanks Johannes :) Hannes, let me know if. Munch better, only 42 failures now. 001+ Content-type: text/html; charset=utf-8 001- Content-type: text/html Looks like all of them are failing like this. -Hannes -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [HEADS UP] pecl/phar is now ext/phar
Hi Hannes, Munch better, only 42 failures now. 001+ Content-type: text/html; charset=utf-8 001- Content-type: text/html Looks like all of them are failing like this. That's really not a lot to go on. Which are 'all of them'? The frontcontrollers? Thanks, - Steph -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [HEADS UP] pecl/phar is now ext/phar
Hi Greg, I would guess all tests that have --EXPECT_HEADERS-- and text/html. We need to put default_charset= in the --INI-- section and then the tests will pass. Do you want to do this Steph, or should I? Would you mind? I'm caught up in HEAD right now :\ - Steph Greg -- 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] Extension_Dir: Proposal to offer multi-directory DLL loading
Hi! If the current change to PHP53 is kept, which breaks PHP52, then we only Here I must have missed something - which use case worked in 5.2 and not in 5.3? If we can make it work with 5.3 - we definitely should do it. So if you think the multi-path extension_dir= change isn't going to be accepted to PHP53, I might as well stop right here. I don't know - it depends how broad is the need for it and how other developers perceive it. PS: I must say that I find it incredible that breaking code seems to be the modus operandi around here. I think the team should be more It is not. Of course, nobody here is omniscient, so it may happen on occasion that we do changes that may break some setups. Then the person whose code is broken writes to the list or submits a bug and complains - soso worked before and doesn't work now. Then we see if the breakage was intentional (which happens sometimes - PHP is evolving and things that looked like good idea 5 years ago may not look so good now) or by mistake, and in the latter case we fix it. However nobody here does changes just for the heck of it. -- Stanislav Malyshev, Zend Software Architect [EMAIL PROTECTED] http://www.zend.com/ (408)253-8829 MSN: [EMAIL PROTECTED] -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] 5.3 and reflection
Hello, I'm installing a recent snap of 5.3 on my dev server. The app I'm working on makes heavy use of reflection. How has reflection changed in 5.3 to address namespaces? What resolution rules apply when creating a ReflectionClass? If I try to create a ReflectionClass for a class that is outside the current namespace, what will happen? Also, are there any plans to address namespaces themselves in the reflection API (i.e. ReflectionNamespace objects, getNamespace() method in the ReflectionClass object, etc)? Thanks, Jeremy -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] 5.3 and reflection
Hi! I'm installing a recent snap of 5.3 on my dev server. The app I'm working on makes heavy use of reflection. How has reflection changed in 5.3 to address namespaces? What resolution rules apply when creating a Namespaces should not have big influence on reflection, since namespace is just the logical partitioning of the class name - i.e. if the class name is Foo::Bar::Baz, you can say that Foo::Bar is the namespace, but for reflection you still use full class name. ReflectionClass? If I try to create a ReflectionClass for a class that is outside the current namespace, what will happen? You should be able to use any class name with ReflectionClass. Since namespaces are compile-time only, at runtime there's no such thing as current namespace. Also, are there any plans to address namespaces themselves in the reflection API (i.e. ReflectionNamespace objects, getNamespace() method in the ReflectionClass object, etc)? See above, it should answer these questions. -- Stanislav Malyshev, Zend Software Architect [EMAIL PROTECTED] http://www.zend.com/ (408)253-8829 MSN: [EMAIL PROTECTED] -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] 5.3 and reflection
Stanislav Malyshev wrote: Hi! I'm installing a recent snap of 5.3 on my dev server. The app I'm working on makes heavy use of reflection. How has reflection changed in 5.3 to address namespaces? What resolution rules apply when creating a Namespaces should not have big influence on reflection, since namespace is just the logical partitioning of the class name - i.e. if the class name is Foo::Bar::Baz, you can say that Foo::Bar is the namespace, but for reflection you still use full class name. ReflectionClass? If I try to create a ReflectionClass for a class that is outside the current namespace, what will happen? You should be able to use any class name with ReflectionClass. Since namespaces are compile-time only, at runtime there's no such thing as current namespace. Thanks for your response. Just to clarify, - Class names are translated at compile time to include the namespace. This composite is now considered to be the class name by the engine, and the class name alone (i.e. Baz) is no longer meaningful. - Therefore, to reflect a class at runtime, the namespace must be included. To continue your example, if I tried to do this: $reflect = new ReflectionClass(Baz); it would not work, regardless of the namespace of the file that statement appears in. I must instead do this: $reflect = new ReflectionClass(Foo::Bar::Baz); Furthermore, there will never be a way to reflect a namespace, since the concept of namespacing is essentially lost by the time the reflection code would be executed. Is this accurate? Thanks, Jeremy -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] 5.3 and reflection
Hi! To continue your example, if I tried to do this: $reflect = new ReflectionClass(Baz); it would not work, regardless of the namespace of the file that statement appears in. I must instead do this: $reflect = new ReflectionClass(Foo::Bar::Baz); Right. You can use __NAMESPACE__ compile-time constant to save yourself some typing and maintenance if you are doing it inside namespace declaration. So it'd be: $reflect = new ReflectionClass(__NAMESPACE__.::Baz); Furthermore, there will never be a way to reflect a namespace, since the concept of namespacing is essentially lost by the time the reflection code would be executed. Is this accurate? Yes. You can of course get class name and split it by :: and use the parts as you wish, but there's no such separate entity as namespace containing classes in the engine, so you can ask only what class names begin with Foo::Bar::. We could make reflection method that does just that - i.e. lists classes beginning with certain prefix - but we didn't see a need for it yet. If there would be some user demand for it, it might be added later. -- Stanislav Malyshev, Zend Software Architect [EMAIL PROTECTED] http://www.zend.com/ (408)253-8829 MSN: [EMAIL PROTECTED] -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Class Properties in Interfaces?
Hi! point the following is nolonger valid: $o_Foo is-a foo. And that is the basic design rule we chose for PHP. Please file as a bug! I don't think it's a bug. PHP as a dynamic language allows to do a lot of think that Java or C++ do not. This is one of them. -- Stanislav Malyshev, Zend Software Architect [EMAIL PROTECTED] http://www.zend.com/ (408)253-8829 MSN: [EMAIL PROTECTED] -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] SplFileObject with include_path
Done, http://bugs.php.net/bug.php?id=44987 Thank you, Ionut --- Marcus Boerger [EMAIL PROTECTED] wrote: Hello Ionut, file as bug please. marcus Tuesday, May 13, 2008, 12:37:45 PM, you wrote: Hi, I'm working on a SOAP project and as part of the checks I make are the existence and readability of the WSDL file. As far as I saw, SoapClient doesn't check include_path for the WSDL file, so I thought I could use fopen to check this and then find the real path which would be finally passed to the SoapClient constructor. The problem with fopen is that I don't know how to find the real path if the file does exist in the include_path. So I took a look at SplFileObject, whose constructor accepts the same parameters as fopen. Here's my issue. If I instantiate SplFileObject like: $file = new SplFileObject($filename, 'r', true); and $filename is found somewhere on the include_path, wouldn't be useful if a call to SplFileObject::getRealPath() would return the actual real path and not false? Because at this point it doesn't. Best regards, Marcus -- 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] Building PHP5TS.DLL (only) for Win32
Hi, I'm having a terrible time trying to get PHP5TS.DLL rebuilt with an exact configuration as the current official version release PHP 5.2.6. Of course, I need to put more time to figure this all out. But all I want to do is make a slight change to PHP5TS.DLL and rebuilt it with 100% exact imports and exports. The 5.2.6 official version date, time and size is: 05/02/2008 06:07 PM 4,874,301 php5ts.dll By following the PHP build web resources, wiki, the many blogs, etc, I can get a build but it exports are different and it requires ZLIB.DLL. What I did to figure out what configure.js was used, was to dump phpinfo() from a official 5.2.6 installation PHP run and it shows: Build Date = May 2 2008 18:01:20 Configure Command = cscript /nologo configure.js --enable-snapshot-build --with-gd=shared --with-extra-includes=C:\Program Files (x86)\Microsoft SDK\Include;C:\PROGRA~2\MICROS~2\VC98\ATL\INCLUDE;C:\PROGRA~2\MICROS~2\VC98\INCLUDE; C:\PROGRA~2\MICROS~2\VC98\MFC\INCLUDE --with-extra-libs=C:\Program Files (x86)\Microsoft SDK\Lib;C:\PROGRA~2\MICROS~2\VC98\LIB;C:\PROGRA~2\MICROS~2\VC98\MFC\LIB I use these configure.js options, of course, using my includes, lib reflecting my VS98 setup, and I don't get the exact image. But again, I don't get the exact build and it requires ZLIB.DLL: 05/13/2008 04:14 PM 4,624,437 php5ts.dll Please get me started with this. All I need is setup that will allow me to duplicate a release built. We can't continue with making changes if we can't make it a transparent change. Once I can duplicate it, I can take it from there. I just don't understand the entire PHP framework yet. I'm getting there, and spending all my time on this, but I'm getting no where. I would greatly appreciate the skinny of everything I need, what options in order to rebuild php5ts.dll. -- Hector Santos -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Class Properties in Interfaces?
Hello Christian, Stas, Tuesday, May 13, 2008, 4:08:09 PM, you wrote: Marcus Boerger wrote: unset($o_Foo-bar); echo $o_Foo-bar; ? outputs ... Notice: Undefined property: foo::$bar in C:\- on line 13 At this point you found an error. Because this allows unset() to modify an instance in a way that it nolonger adheres to its class that means at this point the following is nolonger valid: $o_Foo is-a foo. And that is the basic design rule we chose for PHP. Please file as a bug! So you are saying that $o_Foo-bar = array(42); is ok when the class expects a string but unset($o_Foo-bar); or (as as slight variation) $o-Foo-bar = null; is not? I Do not get the connection here? And since when can we 'expect' a string only for a property? My point is that an object should always have a property, whether it has the value NULL or not doesn't matter at all. And actually unsetting a property right now doesn't change much besides that it breaks inhereitance rules and affects reflection (maybe, not tested). Becasue when a defined property is unset() and that infact results in deletion than the property information ist still present in the class. The next access to that property now must not result in an error (not even E_NOTICE as even that would be misleading, people would try to find the error in the class). And anyway PHP happily recreates the property with value NULL if being accessed. And if the property is not declared than PHP will simply create a new property on access. This creation of undeclared properties does not affect any inheritance rules and was decided on. This is what Sats meant with what PHP allows beyond C++ and Java. Allowing anythign more breaks our basic design principles. I'd ask not to change this behaviour as you'll just add another (IMHO bogus) restriction on how an object or class can be modified at runtime. An error possibly caused by this is already handled by the E_NOTICE message anyway. For comparison: Having to declare static class variables is a similar restriction which got in my way more often than it helped me. - Chris Best regards, Marcus -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] Resending session cookies patch
Here is a patch that will add an ini setting (session.cookie_resend) to
resend session cookies whenever a session is started. The point of this
is to keep a cookie's expiration fresh as users use a site. Currently,
once a session is started, it will expire after cookie_lifetime no
matter what. For my applications, I need that cookie to only expire
after cookie_lifetime of non use. I also added a function called
session_send_cookie() that will send the cookie right then in case you
don't have access to the ini settings or want to make that customized
based on events in your application.
The only caveat of this is that currently session_send_cookie() will
send the Set-Cookie header every time it is called. There is no flag in
the _php_ps_globals struct to indicate that a cookie has been sent other
than PS(send_cookie). However, I can't rely on that because if the
session is found and session.cookie_resend is 0 PS(send_cookie) is set
to 0 already. I could add a new flag (cookie_sent?) and track that
anywhere that php_session_send_cookie is called or even inside
php_session_send_cookie. But, the coding style of this file did not
seem to favor altering PS() inside that function. It does not currently
check PS(send_cookie). It simply just fires off the Set-Cookie header.
Thoughts?
--
Brian Moon
Senior Developer/Engineer
--
When you care enough to spend the very least.
http://dealnews.com/
--- php_session.h.orig 2008-05-13 21:08:54.0 -0500
+++ php_session.h 2008-05-13 21:08:09.0 -0500
@@ -104,6 +104,7 @@
char *cookie_domain;
zend_bool cookie_secure;
zend_bool cookie_httponly;
+ zend_bool cookie_resend;
ps_module *mod;
void *mod_data;
php_session_status session_status;
@@ -153,6 +154,7 @@
PHP_FUNCTION(session_set_cookie_params);
PHP_FUNCTION(session_get_cookie_params);
PHP_FUNCTION(session_write_close);
+PHP_FUNCTION(session_send_cookie);
#ifdef ZTS
#define PS(v) TSRMG(ps_globals_id, php_ps_globals *, v)
--- session.c.orig 2008-05-13 21:09:00.0 -0500
+++ session.c 2008-05-13 21:06:20.0 -0500
@@ -77,6 +77,7 @@
PHP_FE(session_set_cookie_params, NULL)
PHP_FE(session_get_cookie_params, NULL)
PHP_FE(session_write_close, NULL)
+ PHP_FE(session_send_cookie, NULL)
PHP_FALIAS(session_commit, session_write_close, NULL)
{NULL, NULL, NULL}
};
@@ -194,6 +195,7 @@
STD_PHP_INI_ENTRY(session.cookie_domain, ,
PHP_INI_ALL, OnUpdateString, cookie_domain, php_ps_globals,ps_globals)
STD_PHP_INI_BOOLEAN(session.cookie_secure,,
PHP_INI_ALL, OnUpdateBool, cookie_secure, php_ps_globals,ps_globals)
STD_PHP_INI_BOOLEAN(session.cookie_httponly, ,
PHP_INI_ALL, OnUpdateBool, cookie_httponly,php_ps_globals,ps_globals)
+ STD_PHP_INI_BOOLEAN(session.cookie_resend,0,
PHP_INI_ALL, OnUpdateBool, cookie_resend, php_ps_globals,ps_globals)
STD_PHP_INI_BOOLEAN(session.use_cookies, 1,
PHP_INI_ALL, OnUpdateBool, use_cookies,php_ps_globals,ps_globals)
STD_PHP_INI_BOOLEAN(session.use_only_cookies, 0,
PHP_INI_ALL, OnUpdateBool, use_only_cookies, php_ps_globals,ps_globals)
STD_PHP_INI_ENTRY(session.referer_check, ,
PHP_INI_ALL, OnUpdateString, extern_referer_chk, php_ps_globals,ps_globals)
@@ -1148,6 +1150,17 @@
sapi_add_header_ex(ncookie.c, ncookie.len, 0, 0 TSRMLS_CC);
}
+/* {{{ proto void session_send_cookie(void)
+ Sends the cookie back to the browser */
+PHP_FUNCTION(session_send_cookie)
+{
+ if (PS(use_cookies)) {
+ php_session_send_cookie(TSRMLS_C);
+ PS(send_cookie) = 0;
+ }
+}
+/* }}} */
+
PHPAPI ps_module *_php_find_ps_module(char *name TSRMLS_DC)
{
ps_module *ret = NULL;
@@ -1259,7 +1272,9 @@
lensess + 1, (void **) ppid) ==
SUCCESS) {
PPID2SID;
PS(apply_trans_sid) = 0;
- PS(send_cookie) = 0;
+ if(!PS(cookie_resend)){
+ PS(send_cookie) = 0;
+ }
PS(define_sid) = 0;
}
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
