[PHP-DEV] making var_dump and var_export even better
Hi, If var_dump would dump the type info into PHP comments then var_dump would be also valid PHP code. That'd be very cool. I guess this would be rather easy to code as we already have var_export. Also, about circular references. Isn't it possible to reuse the circular recognition from print_r and actually write out a reference to the offending piece? Regards, Karoly Negyesi -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Inconsistencies when accessing protected members
Hello Internals, This discussion was very interesting to me so I made some research about all languages OOP. Each time I saw definition of public, protected, private there was an explanation which never mentioned instances, but classes. I certainly thought that Richard is right saying: Surely it shouldn't work at all unless the $foo === $this? I was even amazed that I haven't thought about this ever...and the conclusion of my research is that as, like Stanislav said, this keywords(public, etc) are for classes not for instances... I learned something new today :) Thanks for this discussion. Best Regards, Dimitar Isusov
Re: [PHP-DEV] Re: [php-icu] Re: [PHP-DEV] Re: [php-icu] Graphemes and unicode vs intl extension
Stanislav Malyshev wrote: Hi! I meant to duplicate the code from ext/date (where it belongs) in pecl/intl. Please notice the pecl/intl not php-src/ext. The goal is to provide the DateFormatter feature to php 5.2 users. Great, right now 5.2 users can use intl extension from pecl, including DateFormatter. As Derick said, it should be in ext/date. I quickly reviewed the dateformat/* code and did not catch any stopping point to actually move the code in ext/date. I agree that it will add some tiny extra You'll also need to copy error handling and charset conversion, at least. work but it is really worth the effort. Having the date code in one place will benefit the users, from a quality and usability point of view. Actually, the users couldn't care less in which directory the source code was located. They care about the API provided - so do you propose to provide different API? If so, which one? As for quality, I don't see what extra quality would copying this code provide. That could work as well as long as it is: - completely transparent to the users (no worry here) - team work and (very) good communication between ext/date maintainers and intl maintainers (I worry more here ;), that means ext/date maintainers should have a word/voice in intl :) As I already said, anybody who wants to contribute is welcome. Actually, only discussion on date (or any non-bug-related matters for that matter :) is held for now right here. If you want to move it, say, to php-i18n, I'm OK with that too. Personally I see this as another totally irrelevant side track from getting PHP6 out! *I* have a perfectly functional date system that I have no intention of changing until I *CAN* go to a stable unicode based system. Blasting 'Date' into earlier versions broke that for many of us without actually offering anything practical and as yet I see no reason to waste time changing !!! PLEASE can all this effort on YET ANOTHER VERSION OF PHP (5.3) be directed to getting a stable build of PHP6 out of the door so we can all have something to aim for. Changing and extending PHP5 yet again is distracting from getting all the PHP4 users on board, so can we please nail PHP5 down NOW and keep all this potentially nice stuff until we HAVE a new flat platform. I can see peoples arguments for not standardising on unicode but nowadays with international trade ALL of my web site activity HAS to cope with names and addresses from around the world so even ascii luddites will get caught out sometime unless they have found a way to block all overseas access :( -- Lester Caine - G8HFL - Contact - http://home.lsces.co.uk/lsces/wiki/?page=contact L.S.Caine Electronic Services - http://home.lsces.co.uk EnquirySolve - http://enquirysolve.com/ Model Engineers Digital Workshop - http://medw.co.uk// Firebird - http://www.firebirdsql.org/index.php -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] BC break with php 5.2.6
Hi,
i noticed that some changes was made that 100% break all apps that do such
stuff:
class x extends y
{
public static function foo()
{
new self();
}
}
class y
{
private function __construct()
{
echo 'y::__construct()' . PHP_EOL;
}
}
x::foo();
with php 5.2.5 i works so that i get an output y::__construct() but with
5.2.6RC and -DEV
it throws an fatal error:
Fatal error: Call to private y::__construct() from context 'x'
i can remember that i asked a related question last year and someone told me
it is ok so and its a know behavior.
This change will ie. break ZF too. Any suggestions to this behavior?
--
Marco Kaiser
Re: [PHP-DEV] BC break with php 5.2.6
Hello Marco, May be you should check the [PHP-DEV] Inconsistencies when accessing protected members thread. It's said there: Private means this API belongs to this class only, protected means this API belongs to this class and the children. and you can find there a lot of useful thoughts about your question there.
Re: [PHP-DEV] short_open_tag
Hello Jared, in theory, if you could make sure the instance gets destructoed prior to the end of the main script. After script end the order of destructor calls is not deterministic or better said it is but not depending on memory management. marcus Wednesday, March 26, 2008, 11:57:46 PM, you wrote: -Original Message- From: Stanislav Malyshev [mailto:[EMAIL PROTECTED] Sent: 26 March 2008 20:28 To: Lukas Kahwe Smith Cc: Derick Rethans; Marcus Boerger; Hannes Magnusson; PHP Internals Subject: Re: [PHP-DEV] short_open_tag Hi! do note that we have increasingly large numbers of way to jump out of the scope (exceptions, recoverable errors). this obviously makes these kinds of cleanups potentially easier to forget. You'd need to catch and process exceptions anyway, and recoverable errors, as far as I understand, are not meant as jumping out of scope (you can run the handler, but the you're back to where the error was, right?). However, exceptions are a good point - actually, the first good objection to this thing. Need to think if this can be solved easily. -- Stanislav Malyshev, Zend Software Architect [EMAIL PROTECTED] http://www.zend.com/ (408)253-8829 MSN: [EMAIL PROTECTED] -- You use a class constructor to change the ini setting, and the destructor to revert it back. That way once the instance is out of scope the change will be automatically reverted? Jared Best regards, Marcus -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] Re: [PHP-QA] BC break with php 5.2.6
Hello Marco,
Thursday, March 27, 2008, 9:25:48 AM, you wrote:
Hi,
i noticed that some changes was made that 100% break all apps that do such
stuff:
class x extends y
{
public static function foo()
{
new self();
}
}
class y
{
private function __construct()
{
echo 'y::__construct()' . PHP_EOL;
}
}
x::foo();
with php 5.2.5 i works so that i get an output y::__construct() but with
5.2.6RC and -DEV
it throws an fatal error:
Fatal error: Call to private y::__construct() from context 'x'
The behavior is correct. Maybe something with $this is broken in earlier
versions. I checked the basic issue here calling an inherited private
constructor directly without anything else involved:
[EMAIL PROTECTED] PHP_5_0]$ php -r 'class R{private function __construct(){}}
class D extends R{} new D;'
make: `sapi/cli/php' is up to date.
Fatal error: Call to private R::__construct() from context '' in Command line
code on line 1
[EMAIL PROTECTED] PHP_5_0]$ cd ../PHP_5_1
[EMAIL PROTECTED] PHP_5_1]$ php -r 'class R{private function __construct(){}}
class D extends R{} new D;'
make: `sapi/cli/php' is up to date.
Fatal error: Call to private R::__construct() from context '' in Command line
code on line 1
[EMAIL PROTECTED] PHP_5_1]$ cd ../PHP_5_2
[EMAIL PROTECTED] PHP_5_2]$ php -r 'class R{private function __construct(){}}
class D extends R{} new D;'
make: `sapi/cli/php' is up to date.
Fatal error: Call to private R::__construct() from invalid context in Command
line code on line 1
[EMAIL PROTECTED] PHP_5_2]$ cd ../PHP_5_3
[EMAIL PROTECTED] PHP_5_3]$ php -r 'class R{private function __construct(){}}
class D extends R{} new D;'
make: `sapi/cli/php' is up to date.
Fatal error: Call to private R::__construct() from invalid context in Command
line code on line 1
[EMAIL PROTECTED] php-cvs]$ cd ../php-cvs
[EMAIL PROTECTED] php-cvs]$ php -r 'class R{private function __construct(){}}
class D extends R{} new D;'
make: `sapi/cli/php' is up to date.
Fatal error: Call to private R::__construct() from invalid context in Command
line code on line 1
Apparently all of 5.0, 5.1, 5.2, 5.3 and HEAD behave in the same way and issue a
Fatal error as expected.
Now your code uses self winthin class X which is derived from Y which has a
private constructor. Let's see whether the ctor is illegally called in this
example:
[EMAIL PROTECTED] PHP_5_0]$ cd ../PHP_5_0
[EMAIL PROTECTED] PHP_5_0]$ php -r 'class R{private function __construct(){echo
R\n;}} class D extends R{static function f(){var_dump(new self);}} D::f();'
make: `sapi/cli/php' is up to date.
R
object(D)#1 (0) {
}
[EMAIL PROTECTED] PHP_5_0]$ cd ../PHP_5_1
[EMAIL PROTECTED] PHP_5_1]$ php -r 'class R{private function __construct(){echo
R\n;}} class D extends R{static function f(){var_dump(new self);}} D::f();'
make: `sapi/cli/php' is up to date.
R
object(D)#1 (0) {
}
[EMAIL PROTECTED] PHP_5_1]$ cd ../PHP_5_2
[EMAIL PROTECTED] PHP_5_2]$ php -r 'class R{private function __construct(){echo
R\n;}} class D extends R{static function f(){var_dump(new self);}} D::f();'
make: `sapi/cli/php' is up to date.
Fatal error: Call to private R::__construct() from context 'D' in Command line
code on line 1
So yes, there is a bug with the inheritance rules in older versions.
i can remember that i asked a related question last year and someone told me
it is ok so and its a know behavior.
This change will ie. break ZF too. Any suggestions to this behavior?
Fix the code by finding the correct way that works with both old and new
versions.
Best regards,
Marcus
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Backporting to 5_3
On 26.03.2008, at 17:56, Pierre Joye wrote: On Wed, Mar 26, 2008 at 5:39 PM, Stanislav Malyshev [EMAIL PROTECTED] wrote: Hi! - Added runtime JIT auto-globals fetching and caching. (Dmitry, Sara) Does this change any semantics, etc? Any reason why it wasn't merged in the first place? It was initially done for the input encoding in head as the runtime encoding may change after RINIT and inside the script. By the way, the JIT fetchde/encode part is still to be done in HEAD. I have added this to the php60 todo list. hope you dont mind that i put your name behind this item. at the very least you would know what to do if someone wants to take on this item. regards, Lukas -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] REMINDER - stream wrappers in include_path
Hi Greg,
in php_resolve_path()
- you removed (p - filename 1) check but it means that c://tmp will be
used as stream wrapper
- you added check for !wrapper, but we don't need to do any filesystem
search for filename with wrong wrapper
I've removed this modifications.
I also added proper assignment to opened_path.
I've committed the patch into PHP_5_3 and HEAD.
Thanks. Dmitry.
Gregory Beaver wrote:
Marcus Boerger wrote:
Hello Gregory,
+ for (p = ptr; isalnum((int)*p) || *p == '+' || *p == '-' || *p
== '.'; p++);
+ /* p - ptr 1 allows us to skip things like C:\whatever */
+ if ((*p == ':') (p - ptr 1) (path_len - (p - path) 2)
(p[1] == '/') (p[2] == '/')) {
+ /* .:// or ..:// is not a stream wrapper */
+ if (p[-1] != '.' || p[-2] != '.' || p - 2 != ptr) {
+ p += 3;
+ is_stream_wrapper = 1;
+ }
+ }
You missed one part though. C stops execution of a boolean expression on
the first one that decides on the result. So if p[1] is '\0' then p[2] will
never be accessed. So there is no access violation at all.
good point (i.e. duh on my part). attached patch removes that
unnecessary paranoia.
Analyzing the check for '..:', took a long time :-) And I like that we
check for this common case without going to the wrapper list. And we do not
need to check for the common case '.' either as you require two chars in
front of the ':', cool!
I found a few minor optimizations of this code just now, attached patch
should be even better.
However with the check below:
+ if ((*p == ':') (filename_length - (p - filename) 2) (p[1] == '/')
(p[2] == '/')) {
+ wrapper = php_stream_locate_url_wrapper(filename, actual_path, STREAM_OPEN_FOR_INCLUDE TSRMLS_CC);
+ if (wrapper == php_plain_files_wrapper) {
+ if (tsrm_realpath(actual_path, resolved_path
TSRMLS_CC)) {
+ return estrdup(resolved_path);
+ }
+ }
return NULL;
Don't we need to check for wrapper being NULL as in:
if (!wrapper || wrapper == php_plain_files_wrapper) {
Probably, I've added that in too.
Greg
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Inconsistencies when accessing protected members
Hi all, thanks for thinking about this.
On 26/03/2008, Marcus Boerger [EMAIL PROTECTED] wrote:
On 26/03/2008, Alexey Zakhlestin [EMAIL PROTECTED] wrote:
use case for protected is similiar, but relates to cases when you
have hierarchy of classes, which still have some common functionality,
which might be usable for multi-instance operations
Thanks. This is the exact way we see this. Anything that violates this rule
is a bug.
Ok, good. So to get back to the original question
(http://turl.ca/kfanjo), in the following case, should B1::f() be
visible from B2 in the code example below? Note that:
- B1 and B2 both extend A. B2 is neither an ancestor nor a
descendant of B1, but I suppose they could be considered to be part of
the same class hierarchy because they are siblings.
- f() is declared as protected in A and B1, but not declared at all in B2.
- The docs state: Protected limits access to inherited and parent
classes (and to the class that defines the item) -
http://php.net/manual/en/language.oop5.visibility.php .
Currently, B1::f() is visible from B2.
-- If this is a bug, Felipe's patch
(http://ecl.mediain.com.br/diff/protected.diff) fixes the issue. Let's
commit it! :)
-- If this is not a bug then the docs need to be clarified.
Furthermore, callbacks, is_callable(), lookups to the clone destruct
magic methods and possibly property access should all be changed,
because they currently do not adhere to this rule (as illustrated in
the code snippets in http://turl.ca/kfanjo ).
The code:
?php
class A {
static protected function f() {return 'In A::f';}
}
class B1 extends A {
static protected function f() {return 'In B1::f';}
}
class B2 extends A {
static public function test() {echo B1::f();} // Currently, this works.
}
B2::test();
?
Regards,
Robin.
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] RE: [PHP-QA] BC break with php 5.2.6
Hi Marcus,
thanks for this conclusion. I just asked this because this changed in this
release and should noticed in the readme or upgrade process because most
singleton pattern implementations in some frameworks, for ie. ZF are using
this code:
class My_Controller_Front extends Zend_Controller_Front
{
public static function getInstance()
{
if (null === self::$_instance) {
self::$_instance = new self();
}
return self::$_instance;
}
}
The __constructor in Zend_Controller_Front is private.
I asked a, i think, similar question last nov. About private properties.
http://news.php.net/php.internals/33543
Johannes replied to this:
http://news.php.net/php.internals/33544
Johannes: That's a feature: Extended classes know nothing about private
stuff in
the parent class. Without that the encapsulation won't be complete.
This means this was maybe a bug, that i allread talked about but its now
changed so we should raise a notice about this. That will BREAK
Many many apps out there.
For example, PHPUNIT, ZendFramework, ezComponents.
-- Marco
-Original Message-
From: Marcus Boerger [mailto:[EMAIL PROTECTED]
Sent: Thursday, March 27, 2008 10:51 AM
To: Marco Kaiser
Cc: PHP Developers Mailing List; [EMAIL PROTECTED]
Subject: Re: [PHP-QA] BC break with php 5.2.6
Hello Marco,
Thursday, March 27, 2008, 9:25:48 AM, you wrote:
Hi,
i noticed that some changes was made that 100% break all apps that do
such
stuff:
class x extends y
{
public static function foo()
{
new self();
}
}
class y
{
private function __construct()
{
echo 'y::__construct()' . PHP_EOL;
}
}
x::foo();
with php 5.2.5 i works so that i get an output y::__construct() but
with
5.2.6RC and -DEV
it throws an fatal error:
Fatal error: Call to private y::__construct() from context 'x'
The behavior is correct. Maybe something with $this is broken in
earlier
versions. I checked the basic issue here calling an inherited private
constructor directly without anything else involved:
[EMAIL PROTECTED] PHP_5_0]$ php -r 'class R{private function
__construct(){}} class D extends R{} new D;'
make: `sapi/cli/php' is up to date.
Fatal error: Call to private R::__construct() from context '' in
Command line code on line 1
[EMAIL PROTECTED] PHP_5_0]$ cd ../PHP_5_1
[EMAIL PROTECTED] PHP_5_1]$ php -r 'class R{private function
__construct(){}} class D extends R{} new D;'
make: `sapi/cli/php' is up to date.
Fatal error: Call to private R::__construct() from context '' in
Command line code on line 1
[EMAIL PROTECTED] PHP_5_1]$ cd ../PHP_5_2
[EMAIL PROTECTED] PHP_5_2]$ php -r 'class R{private function
__construct(){}} class D extends R{} new D;'
make: `sapi/cli/php' is up to date.
Fatal error: Call to private R::__construct() from invalid context in
Command line code on line 1
[EMAIL PROTECTED] PHP_5_2]$ cd ../PHP_5_3
[EMAIL PROTECTED] PHP_5_3]$ php -r 'class R{private function
__construct(){}} class D extends R{} new D;'
make: `sapi/cli/php' is up to date.
Fatal error: Call to private R::__construct() from invalid context in
Command line code on line 1
[EMAIL PROTECTED] php-cvs]$ cd ../php-cvs
[EMAIL PROTECTED] php-cvs]$ php -r 'class R{private function
__construct(){}} class D extends R{} new D;'
make: `sapi/cli/php' is up to date.
Fatal error: Call to private R::__construct() from invalid context in
Command line code on line 1
Apparently all of 5.0, 5.1, 5.2, 5.3 and HEAD behave in the same way
and issue a
Fatal error as expected.
Now your code uses self winthin class X which is derived from Y which
has a
private constructor. Let's see whether the ctor is illegally called in
this
example:
[EMAIL PROTECTED] PHP_5_0]$ cd ../PHP_5_0
[EMAIL PROTECTED] PHP_5_0]$ php -r 'class R{private function
__construct(){echo R\n;}} class D extends R{static function
f(){var_dump(new self);}} D::f();'
make: `sapi/cli/php' is up to date.
R
object(D)#1 (0) {
}
[EMAIL PROTECTED] PHP_5_0]$ cd ../PHP_5_1
[EMAIL PROTECTED] PHP_5_1]$ php -r 'class R{private function
__construct(){echo R\n;}} class D extends R{static function
f(){var_dump(new self);}} D::f();'
make: `sapi/cli/php' is up to date.
R
object(D)#1 (0) {
}
[EMAIL PROTECTED] PHP_5_1]$ cd ../PHP_5_2
[EMAIL PROTECTED] PHP_5_2]$ php -r 'class R{private function
__construct(){echo R\n;}} class D extends R{static function
f(){var_dump(new self);}} D::f();'
make: `sapi/cli/php' is up to date.
Fatal error: Call to private R::__construct() from context 'D' in
Command line code on line 1
So yes, there is a bug with the inheritance rules in older versions.
i can remember that i asked a related question last year and someone
told me
it is ok so and its a know behavior.
This change will ie. break ZF too. Any suggestions to this behavior?
Fix the code by finding the correct way that works with
Re: [PHP-DEV] Comments on #44393, ISAPI module patch?
On 3/26/08, Jani Taskinen [EMAIL PROTECTED] wrote: Richard Krehbiel kirjoitti: [...] http://bugs.php.net/44393 [...] It might help a bit if you put that patch online somewhere available for download. A patch in the bug report is messed up and kinda unreadable.. Provide the url to the patch here and also in the bug report! :) --Jani Very good point - word-wrapped, it was. Um - all three were. It's like I wasn't paying attention, or something. :-( Here: http://home.comcast.net/~krehbiel3/php5isapi.c.patchhttp://home.comcast.net/%7Ekrehbiel3/php5isapi.c.patch
[PHP-DEV] phar API
Hi,
i just read the phar examples in the manual and found things like this:
$p = new Phar('coollibrary.phar');
if (Phar::canWrite()) {
$fp = fopen('hugefile.dat', 'rb');
$p['data/hugefile.dat'] = $fp;
if (Phar::canCompress()) {
$p['data/hugefile.dat']-setCompressedGZ();
}
$p['images/wow.jpg'] = file_get_contents('images/wow.jpg');
$p['images/wow.jpg']-setMetaData(array('mime-type' = 'image/
jpeg'));
$p['index.php'] = file_get_contents('index.php');
}
First thing: yes i fully understand what the code is doing but i still
think that it doesn't need to be so hackish.
One thing is that i think there is no point in using ArrayAccess here,
in my oppinion ArrayAccess is great to hack stuff but it doesn't
belong in such (maybe soon?) core functionality.
The second thing that looks weird to me is that the setter (offsetSet)
sets the file content but the getter (offsetGet) retrieves a file
object.
What about changing this into something more OO like this (just a
proposal):
$p = new Phar('coollibrary.phar');
/* What about creating a non-static pendant to canWrite()?
Maybe there is an archive file that has only read permissions on
the filesystem or
phar will be able to generate readonly-archives later? (Might be
interesting for
companies that want to provide readonly and signed archives for
the customers)
if ($p-canWrite()) {
// Create a file instance
$hugeFile = $p-createFile();
$fp = fopen('hugefile.dat', 'rb');
// Set the content
$hugeFile-setContent($fp); (or maybe even
setContentResourceHandle(...))
if (Phar::canCompress()) {
/* how is the compression implemented? through streamfilters?
than how about a -setCompression('bzip')
that internally resolves to the bzip.(de)compress:// stuff?
$p['data/hugefile.dat']-setCompressedGZ();
}
// add the file to the archive
$p-addFile($hugeFile, 'data/hugefile.dat');
// another option would be to pass the file path to the
createFile() method and
// implicitely create it in the archive
$indexPhp = $p-createFile('index.php');
$indexPhp-setContent(...);
}
Regards,
Benjamin
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] phar API
Hi Benjamin,
Am Donnerstag, den 27.03.2008, 14:34 +0100 schrieb Benjamin Schulz:
Hi,
i just read the phar examples in the manual and found things like this:
[...]
First thing: yes i fully understand what the code is doing but i still
think that it doesn't need to be so hackish. One thing is that i
think there is no point in using ArrayAccess here, in my oppinion
ArrayAccess is great to hack stuff but it doesn't belong in such
(maybe soon?) core functionality.
ArrayAccess is not hackish per se, but it just does not feels right for
working with archives.
[...]
$p = new Phar('coollibrary.phar');
/* What about creating a non-static pendant to canWrite()?
Maybe there is an archive file that has only read permissions on
the filesystem or
phar will be able to generate readonly-archives later? (Might be
interesting for companies that want to provide readonly and signed archives
for
the customers)
if ($p-canWrite()) {
// Create a file instance
$hugeFile = $p-createFile();
$fp = fopen('hugefile.dat', 'rb');
// Set the content
$hugeFile-setContent($fp); (or maybe even
setContentResourceHandle(...))
if (Phar::canCompress()) {
/* how is the compression implemented? through streamfilters?
than how about a -setCompression('bzip')
that internally resolves to the bzip.(de)compress:// stuff?
$p['data/hugefile.dat']-setCompressedGZ();
}
// add the file to the archive
$p-addFile($hugeFile, 'data/hugefile.dat');
// another option would be to pass the file path to the
createFile() method and
// implicitely create it in the archive
$indexPhp = $p-createFile('index.php');
$indexPhp-setContent(...);
}
I second your proposal, but a bit more flexible:
// Creating files
$phar = new Phar();
$file = $phar-createFile('/filename'); // Phar acts as a factory and returns
an object PharFile or something
$file-setContent('string'); // Polymorph signature, can either take a string
...
$file-setContent(fopen('file', 'r')); // ... or a resource
$file-setContent('foo', $data); // ... or a string and data
$file-setContent('bar', array('line1', 'line2')); // ... or an array of lines
$file-setContent('baz', fopen('file', 'r')); // ... or a name and a resource
if (!$phar-isReadonly()) {
$phar-save(); // Writes the newly create file to the filesystem
}
$phar = new Phar();
$phar-add('foo');
$phar-add('bar', $data);
$phar-add(new SplFileInfo('bar'));
Creating directories:
$phar = new Phar();
$dir = $phar-createDirectory('/foo'); // Return PharDirectory object
$dir-add(new DirectoryIterator(mydir)); // Adds every file in the directory
mydir
$dir-add(new RecursiveDirectoryIterator('otherdir')); // Adds every item
recursivly
$dir-add(new SplFile(foo)); // Adds the file foo
$dir-add('bar'); // Adds bar
$dir-add('baz', $data)
$file = $dir-createFile('bla')
$file-setContent($data);
$dir2 = $dir-createDirectory('foo');
...
$phar-save();
No, with fluent interfaces:
$phar = new Phar();
$phar-createDirectory('foo')
-add('foo')
-add(new SplFileInfo('bar'))
-add('baz', $data);
$phar-save();
if PharFile would include a reference to the original Phar object, the
last Phar::save() could even be included in the chain.
About compression:
I would prefer to have Phar::setCompression(Phar::GZIP) or something
similiar. Or even Phar::setCompressionStrategy(PharCompressionInterface
$interface) but I have the feeling that would go too far :-)
cu, Lars
signature.asc
Description: Dies ist ein digital signierter Nachrichtenteil
[PHP-DEV] CVS Account Request: tswicegood
Various debauchery relating to php-src ;-) -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] BC break with php 5.2.6
Hi!
i noticed that some changes was made that 100% break all apps that do such
stuff:
class x extends y
{
public static function foo()
{
new self();
}
}
class y
{
private function __construct()
{
echo 'y::__construct()' . PHP_EOL;
}
}
I think that private ctor should mean nobody but this class can create
instances of this class. If somebody else is to create them, I'd say
protected ctor is in place.
--
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] REMINDER - stream wrappers in include_path
Hello Dmitry,
Thursday, March 27, 2008, 11:33:55 AM, you wrote:
Hi Greg,
in php_resolve_path()
- you removed (p - filename 1) check but it means that c://tmp will be
used as stream wrapper
Basically he doesn't need to. The code with your modifiactions is wrong now.
He changed it to verify that the potential wrapper indeed exists and if not
he continues as normal. Checking for '.' or '..' are only very extreme and
potential common cases. We however need to make sure that nothing that
really is no wrapper gets used as a wrapper. That means if wrapper is NULL,
then continue as we would have done without the check.
Right now, the following xx://root is seen as relative xx and absolute
//root. Becasue of your change we get xx as wrapper. That resolves to NULL
that is not equal to plain_wrapper so that we return NULL.
Please do not change patches that were reviewed by several people right
before commit. Becasue each and every reviewer will assume that you apply
as reviewed. And if you comment, then please do so before you commit and
not after. Even if you are right you first want to make sure and convince
the reviewers that you are. Otherwise we can spare the time for reviews.
marcus
- you added check for !wrapper, but we don't need to do any filesystem
search for filename with wrong wrapper
I've removed this modifications.
I also added proper assignment to opened_path.
I've committed the patch into PHP_5_3 and HEAD.
Thanks. Dmitry.
Gregory Beaver wrote:
Marcus Boerger wrote:
Hello Gregory,
+ for (p = ptr; isalnum((int)*p) || *p == '+' || *p == '-' ||
*p == '.'; p++);
+ /* p - ptr 1 allows us to skip things like C:\whatever
*/
+ if ((*p == ':') (p - ptr 1) (path_len - (p - path)
2) (p[1] == '/') (p[2] == '/')) {
+ /* .:// or ..:// is not a stream wrapper */
+ if (p[-1] != '.' || p[-2] != '.' || p - 2 != ptr) {
+ p += 3;
+ is_stream_wrapper = 1;
+ }
+ }
You missed one part though. C stops execution of a boolean expression on
the first one that decides on the result. So if p[1] is '\0' then p[2] will
never be accessed. So there is no access violation at all.
good point (i.e. duh on my part). attached patch removes that
unnecessary paranoia.
Analyzing the check for '..:', took a long time :-) And I like that we
check for this common case without going to the wrapper list. And we do not
need to check for the common case '.' either as you require two chars in
front of the ':', cool!
I found a few minor optimizations of this code just now, attached patch
should be even better.
However with the check below:
+ if ((*p == ':') (filename_length - (p - filename) 2) (p[1]
== '/') (p[2] == '/')) {
+ wrapper = php_stream_locate_url_wrapper(filename,
actual_path, STREAM_OPEN_FOR_INCLUDE TSRMLS_CC);
+ if (wrapper == php_plain_files_wrapper) {
+ if (tsrm_realpath(actual_path, resolved_path
TSRMLS_CC)) {
+ return estrdup(resolved_path);
+ }
+ }
return NULL;
Don't we need to check for wrapper being NULL as in:
if (!wrapper || wrapper == php_plain_files_wrapper) {
Probably, I've added that in too.
Greg
Best regards,
Marcus
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Inconsistencies when accessing protected members
Hi! - B1 and B2 both extend A. B2 is neither an ancestor nor a descendant of B1, but I suppose they could be considered to be part of the same class hierarchy because they are siblings. - f() is declared as protected in A and B1, but not declared at all in B2. Which means there exists A::f(), B1::f() and B2::f() (being the same as A::f()), all of which are protected. - The docs state: Protected limits access to inherited and parent classes (and to the class that defines the item) - http://php.net/manual/en/language.oop5.visibility.php . Currently, B1::f() is visible from B2. A::f() is visible from B2, and B1 can not have access to f() more restricted than A since it's violate the Liskov principle - objects of B1 couldn't be used the same way as objects of A in all contexts. Look at this also this way: suppose we had no B1::f. Then if we call f() from B2, we always get A::f() which is protected, so it works. Now we copy A::f definition to B1 verbatim - with same access, same everything. Should now code that calls f() on B1 start failing? -- 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] phar API
Hello Benjamin,
Thursday, March 27, 2008, 2:34:06 PM, you wrote:
Hi,
i just read the phar examples in the manual and found things like this:
$p = new Phar('coollibrary.phar');
if (Phar::canWrite()) {
$fp = fopen('hugefile.dat', 'rb');
$p['data/hugefile.dat'] = $fp;
if (Phar::canCompress()) {
$p['data/hugefile.dat']-setCompressedGZ();
}
$p['images/wow.jpg'] = file_get_contents('images/wow.jpg');
$p['images/wow.jpg']-setMetaData(array('mime-type' = 'image/
jpeg'));
$p['index.php'] = file_get_contents('index.php');
}
First thing: yes i fully understand what the code is doing but i still
think that it doesn't need to be so hackish.
I wouldn't call it hackish. I'd eventually call it new to people that
haven't used the new PHP 5.0 features yet.
One thing is that i think there is no point in using ArrayAccess here,
in my oppinion ArrayAccess is great to hack stuff but it doesn't
belong in such (maybe soon?) core functionality.
So you are basically saying we should remove ArrayAccess, right?
The second thing that looks weird to me is that the setter (offsetSet)
sets the file content but the getter (offsetGet) retrieves a file
object.
Right now the setter takes a resource or a string. Maybe we can allow an
SplFileInfo instance too. But note that this is even more wierd as we then
would need to convert this instance into another instance and still only
transfer the contents.
What about changing this into something more OO like this (just a
proposal):
$p = new Phar('coollibrary.phar');
/* What about creating a non-static pendant to canWrite()?
Maybe there is an archive file that has only read permissions on
the filesystem or
phar will be able to generate readonly-archives later? (Might be
interesting for
companies that want to provide readonly and signed archives for
the customers)
We can already create readonly archives. And obviously you cannot create
signed archives where only selected entries are readonly.
if ($p-canWrite()) {
// Create a file instance
$hugeFile = $p-createFile();
$fp = fopen('hugefile.dat', 'rb');
// Set the content
$hugeFile-setContent($fp); (or maybe even
setContentResourceHandle(...))
if (Phar::canCompress()) {
/* how is the compression implemented? through streamfilters?
than how about a -setCompression('bzip')
that internally resolves to the bzip.(de)compress:// stuff?
$p['data/hugefile.dat']-setCompressedGZ();
}
Hi? This makes no sense whatsover. Because:
Ther is no connection between your stuff.
- $hugeFile would be an anonymous entry in your file
- and then wher is $p['data/hugefile.dat'] coming from?
- and did you not just write ArrayAccess is wrong?
// add the file to the archive
$p-addFile($hugeFile, 'data/hugefile.dat');
Well I prefer the other order. Oh and then that is just what
$p-offsetSet('data/hugefile.dat', $fp); does already.
// another option would be to pass the file path to the
createFile() method and
// implicitely create it in the archive
$indexPhp = $p-createFile('index.php');
$indexPhp-setContent(...);
Well right now, you'd do $indexPhp = $p['index.php']; $indexPhp-...
Ok, all in all I would be ok with adding more functionality. But it needs
to work.
Best regards,
Marcus
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Inclusion of PHP LiteSpeed SAPI in the standard PHP distribution?
Hi Johannes,
Thank you for the quick reply.
Well, the idea is that all PHP-specific code is licensed under the same
license terms. PCRE and GD are external libraries which live outside
PHP's context and which are simply bundled. That's why the clear
preference there is PHP License.
OK, let me make some clarifications on this.
the main SAPI code, lsapi_main.c, which is specific for PHP, has been
licensed under PHP license.
Other c source code are our generic LSAPI library, which will be used
for all third parties integrations, those files are licensed under BSD
license.
I don't mind dual license those code under both BSD and PHP license if
required as long as it won't prevent us from using the same code
somewhere else under BSD license.
Additionally it would nice to follow the PHP coding standards. Like
always having { } after an if statement. This helps PHP developers who
might (possibly) help fixing reported (simple) bugs or apply API
changes.
No problem, will do. :-)
If there is other requirements, please just let me know.
Other than that we, again, have our problem about what's the best way to
bundle something from pecl. I guess the symlink on the CVS server is
the best option we currently have...
I have no problem with moving or recreating that directory at the right
place either.
Thanks,
George
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Inclusion of PHP LiteSpeed SAPI in the standard PHP distribution?
Hi George, On Thu, Mar 27, 2008 at 8:11 PM, George Wang [EMAIL PROTECTED] wrote: Hi Johannes, Thank you for the quick reply. Well, the idea is that all PHP-specific code is licensed under the same license terms. PCRE and GD are external libraries which live outside PHP's context and which are simply bundled. That's why the clear preference there is PHP License. OK, let me make some clarifications on this. the main SAPI code, lsapi_main.c, which is specific for PHP, has been licensed under PHP license. Other c source code are our generic LSAPI library, which will be used for all third parties integrations, those files are licensed under BSD license. I don't mind dual license those code under both BSD and PHP license if required as long as it won't prevent us from using the same code somewhere else under BSD license. I don't think it is necessary. If you like to bundle the LSAPI library, it is perfectly fine to keep it under the BSD license. Cheers, -- Pierre http://blog.thepimp.net | http://www.libgd.org -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] phar API
Hi Marcus,
First thing: yes i fully understand what the code is doing but i
still
think that it doesn't need to be so hackish.
I wouldn't call it hackish. I'd eventually call it new to people that
haven't used the new PHP 5.0 features yet.
I used PHP 5 when it had namespaces the first time ;) So i am not new
to PHP5
features, that's not the point.
One thing is that i think there is no point in using ArrayAccess
here,
in my oppinion ArrayAccess is great to hack stuff but it doesn't
belong in such (maybe soon?) core functionality.
So you are basically saying we should remove ArrayAccess, right?
In my personal oppinion: yes. There is no need for array syntax if you
provide
a OO api, why not setContent() or something else? There is no real
difference
in the implementation, right?
The second thing that looks weird to me is that the setter
(offsetSet)
sets the file content but the getter (offsetGet) retrieves a file
object.
Right now the setter takes a resource or a string. Maybe we can
allow an
SplFileInfo instance too. But note that this is even more wierd as
we then
would need to convert this instance into another instance and still
only
transfer the contents.
The point is that the getter does something completely different from
the
setter. The getter returns a file object but the setter sets the content
of the file, this is just not consistent.
What about changing this into something more OO like this (just a
proposal):
$p = new Phar('coollibrary.phar');
/* What about creating a non-static pendant to canWrite()?
Maybe there is an archive file that has only read permissions on
the filesystem or
phar will be able to generate readonly-archives later? (Might be
interesting for
companies that want to provide readonly and signed archives for
the customers)
We can already create readonly archives.
And how do i check if the archive is readonly? canWrite() just tells me
if the php.ini setting is enabled, right?
And obviously you cannot create
signed archives where only selected entries are readonly.
I don't see where this has to do with the point of my mail but i think
it could easily achieved with
$p-getFile('data/hugefile.dat')-canWrite()
if ($p-canWrite()) {
// Create a file instance
$hugeFile = $p-createFile();
$fp = fopen('hugefile.dat', 'rb');
// Set the content
$hugeFile-setContent($fp); (or maybe even
setContentResourceHandle(...))
if (Phar::canCompress()) {
/* how is the compression implemented? through streamfilters?
than how about a -setCompression('bzip')
that internally resolves to the bzip.(de)compress:// stuff?
$p['data/hugefile.dat']-setCompressedGZ();
}
Hi? This makes no sense whatsover. Because:
Ther is no connection between your stuff.
- $hugeFile would be an anonymous entry in your file
correct, it would be just some random file object related to the phar
archive until i use addFile() like below, if you need this relation one
could provide something like
$p-createFile('data/hugefile.dat');
$p-setContent('...');
- and then wher is $p['data/hugefile.dat'] coming from?
- and did you not just write ArrayAccess is wrong?
sorry, my fault - it should be $hugeFile
// add the file to the archive
$p-addFile($hugeFile, 'data/hugefile.dat');
Well I prefer the other order. Oh and then that is just what
$p-offsetSet('data/hugefile.dat', $fp); does already.
Do you think that is well named? It's what the ArrayAccess interface
prescribes but wouldn't a $p-setFile(), -addFile() describe better
what's happening? I mean we're talking about OO here.
// another option would be to pass the file path to the
createFile() method and
// implicitely create it in the archive
$indexPhp = $p-createFile('index.php');
$indexPhp-setContent(...);
Well right now, you'd do $indexPhp = $p['index.php']; $indexPhp-...
Yep, array syntax? but it's an object right? That is what i mean with
hackish - no
need for array syntax if i work with objects. I still believe that
ArrayAccess has
it's advantages but IMHO not in this case.
regards,
Benjamin
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [PATCH] date/timelib: use system timezone database
On Thu, March 20, 2008 12:40 pm, sean finney wrote: sorry for digging up this dead horse... On Thursday 10 January 2008 01:05:35 pm Joe Orton wrote: On Wed, Jan 09, 2008 at 09:03:02PM +0100, Derick Rethans wrote: On Wed, 9 Jan 2008, Joe Orton wrote: It's a bit of a maintenance headache for distributions when packages include their own copy of the timezone database, since this needs to be updated frequently. There is a PECL extension to provide those updates: http://pecl.php.net/package/timezonedb It is a drop-in replacement to update the rules. My aim is to eliminate the additional copies of the timezone database, rather than ship and maintain yet more. Just as I don't want to statically link all system libraries into PHP, nor have to build special copies of any of them for PHP. joe: did you ever get further on this? it seems this thread died off and nothing came of it, as far as I can tell. Sorry for beating on the dead horse that has been dragged up, and late to boot... Just recently, somebody wondered why PHP had the CORRECT time when their web-server didn't... As I understand the situation, if you can get ALL the sysadmins of the world to update their [bleep] timezonedb frequently, PHP can drop the internal timezonedb. :-) -- Some people have a gift link here. Know what I want? I want you to buy a CD from some indie artist. http://cdbaby.com/from/lynch Yeah, I get a buck. So? -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] Re: phar API
Benjamin Schulz wrote:
Hi,
i just read the phar examples in the manual and found things like this:
$p = new Phar('coollibrary.phar');
if (Phar::canWrite()) {
$fp = fopen('hugefile.dat', 'rb');
$p['data/hugefile.dat'] = $fp;
if (Phar::canCompress()) {
$p['data/hugefile.dat']-setCompressedGZ();
}
$p['images/wow.jpg'] = file_get_contents('images/wow.jpg');
$p['images/wow.jpg']-setMetaData(array('mime-type' = 'image/jpeg'));
$p['index.php'] = file_get_contents('index.php');
}
First thing: yes i fully understand what the code is doing but i still
think that it doesn't need to be so hackish.
One thing is that i think there is no point in using ArrayAccess here,
in my oppinion ArrayAccess is great to hack stuff but it doesn't belong
in such (maybe soon?) core functionality.
The second thing that looks weird to me is that the setter (offsetSet)
sets the file content but the getter (offsetGet) retrieves a file object.
What about changing this into something more OO like this (just a
proposal):
$p = new Phar('coollibrary.phar');
/* What about creating a non-static pendant to canWrite()?
Maybe there is an archive file that has only read permissions on the
filesystem or
phar will be able to generate readonly-archives later? (Might be
interesting for
companies that want to provide readonly and signed archives for the
customers)
snip example
Some notes:
1) if you want to know writability without Phar::canWrite(), you can
also use is_writeable('phar:///path/to/archive.phar/index.php') just
like you can with any other file
2) ArrayAccess is a very natural way of viewing an archive - archives
are a collection of files that can be accessed randomly, just like an
associative array. As such, it can be viewed abstractly as an array of
objects with attributes and methods (files with properties like
compression, checksum, size, metadata, contents and operations to modify
the file or query the contents).
3) Phar extends DirectoryIterator. As such, one needs to think of Phar
as an enhanced DirectoryIterator. This comes with the benefits of
DirectoryIterator (easy iteration, ability to iterate over a CSV file
quite easily, ability to iterate over lines of the file easily) and its
disadvantages (not designed for easy modification of the files or access
to their contents). Fortunately, Marcus is a lead maintainer of both
Phar and SPL, and so he has already fixed some of the missing pieces in SPL.
4) Phar does not force one-true-way of building the archive. The stream
wrapper is fully enabled with write capabilities as well.
Let's take a look at the ways you can populate the contents of a phar
archive:
1) file_put_contents('phar:///path/to/archive.phar/index.php', 'file
contents');
2) $phar = new Phar('/path/to/archive.phar');
$phar-buildFromIterator(new DirectoryIterator('/some/path'), '/some/path');
3) $phar = new Phar('/path/to/archive.phar'); $phar['index.php'] =
file_get_contents('/some/path/index.php');
There's plenty of flexibility here, and no need to be scared of the
arrayaccess option.
I do agree that although I am perfectly comfortable with the current
API, it may seem inconsistent to others who think the way you do to
directly set contents that way when offsetGet() does not return the
contents. However, the solution is quite simple, which is to make even
clearer what operation we are doing:
$contents = $phar['index.php']-contents;
$phar['index.php']-contents = 'something';
This way, it is even clearer that the archive is an array of
PharFileInfo objects. This would be very easy to implement and would
not require removing the existing functionality.
I see no problem in adding an alias to offsetSet() called addFile() and
another for addFromString() and a method for addEmptyDir(). In case it
isn't obvious, I will not do this change unless it adheres to the
existing ext/zip API to allow easy mental migration for developers
between the two extensions, so don't even think about suggesting other
possibilities, thank you :).
Also, as an important note, the only up-to-date manual is at
http://docs.php.net/manual/en/book.phar.php and furthermore the manual
is not yet completely updated to the 2.0 API, which is one of the
reasons I marked phar alpha on release. None of the code you quoted,
however, is out of date. Code that is out of date in the manual is in
compressAllFiles*() and some of the coding examples use the old syntax.
The changes missing from the manual are as follows:
1) compressAllFilesGZ() and compressAllFilesBZIP2() do nothing for
tar-based archives, as there is no way to individually compress files in
a tar archive. To compress an entire archive, use the new compress()
method. Formerly, compressAllFilesGZ() changed a .tar to a .tar.gz.
2) convertToTar/convertToZip/convertToPhar() all return a Phar or a
PharData object, allowing fluent interface niceness such as :
$phar =
Re: [PHP-DEV] [PATCH] date/timelib: use system timezone database
2008/3/27, Richard Lynch [EMAIL PROTECTED]: As I understand the situation, if you can get ALL the sysadmins of the world to update their [bleep] timezonedb frequently, PHP can drop the internal timezonedb. OS vendors release timezone updates frecuently, there is no need for such bundled tz database, just duplicates work. -- If debugging is the process of removing bugs, then programming must be the process of putting them in. – Edsger Dijkstra http://www.cristianrodriguez.net
[PHP-DEV] Re: Backporting to 5_3
Em Qua, 2008-03-26 às 23:43 -0300, Felipe Pena escreveu: 2008/3/26, Johannes Schlüter [EMAIL PROTECTED]: - Removed undocumented and incomplete support for strings in list() operator. (Dmitry) What exactly does that change? $a = foo; list($b) = $a; var_dump($b); Before: string(1) f After (HEAD): NULL Hmm, is that being used anywhere at the planet? :D Anyway... Patch: http://felipe.ath.cx/diff/list.diff -- Regards, Felipe Pena. -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Re: Backporting to 5_3
What exactly does that change? $a = foo; list($b) = $a; var_dump($b); This is weird... I wouldn't go as far as saying nobody uses it - since experience shows there's somebody somewhere using any weird combination of PHP features imaginable - but it's definitely a strange code. Even though, I think since it's functionality drop, we may want to wait with it, unless it doesn't work anyway (e.g. produces segfaults in some cases). -- 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] making var_dump and var_export even better
Also, about circular references. Isn't it possible to reuse the circular recognition from print_r and actually write out a reference to the offending piece? For var_export it isn't possible since there's no way to refer to the value being exported. -- 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] PHP 5.2.6RC3 Released
A bit later then anticipated, but the 5.2.6RC3 was released finally today and the sources for the release can be found here: http://downloads.php.net/ilia/php-5.2.6RC3.tar.bz2 (md5sum: c765de110a33eb7a666c68e795840b0e) Windows binaries should become available in short order as well. All in all the feedback on RC2 has been largely positive and there have been very few changes to the code base since, which usually is a sign we are ready for the final release. Please try RC3 against your code and let us know if you encounter any new problems or regressions. If no critical issues appear, the final release will come out next week. Ilia Alshanetsky 5.2 Release Master -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [PATCH] date/timelib: use system timezone database
hi, On Thursday 27 March 2008 10:26:57 pm Richard Lynch wrote: Just recently, somebody wondered why PHP had the CORRECT time when their web-server didn't... and vice versa. see for example: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=471104 if there were an *option* for php to use the system-bundled timezone database, then this would be a moot point. but instead, at this point to solve the problem someone will need to go digging through cvs, produce a changeset, possibly massage the patch to apply to an older release, ensure the software builds correctly, test the new packages locally, create a new official release for the stable distribution, wait for the users to get the update... this is a process that has been done once already for the system timezone database packages, why do it again for php? if the admin is using the packaged versions of php (and that is the point of this discussion), it won't magically fix itself... so *something* has to be upgraded. and either way they're usually running $packagemanager upgrade, taking whatever is new, whether it is just the timezonedb or the php packages too. it's merely a question of get the updates for free? vs get the updates when the system *and* php has been updated? As I understand the situation, if you can get ALL the sysadmins of the world to update their [bleep] timezonedb frequently, PHP can drop the internal timezonedb. usually that's a matter of $packagemanager upgrade but i digress. of course if you're in a hosted environment where you've built your own php but don't have root to update the system timezone db, then it can be very useful to have the bundled timezonedb too. but ultimately, what may be best for you may be least optimal for someone else... so why not provide an option to work both ways? i'm not even asking that this be made the default, in case you're worried about the clueless user/sysadmin factor. sean signature.asc Description: This is a digitally signed message part.
Re: [PHP-DEV] [PATCH] Allow unsetting headers previously set by header()
Richard Lynch wrote:
At the risk of incurring the wrath of everybody else, I'd prefer to
see a new function like header_unset (or unset_header) to undo a
header.
Currently header() supports adding, replacing and appending to existing
headers as well as specifying the response status code, so I think that
adding a header_unset() would break the current tradition. But I wouldn't
object to adding a new function, though this is probably above by skills.
If a header was not set, and then you unset it, is that an error or
E_NOTICE or anything?
No. I think that the current header() implementation relies on the
reasonable assumption that the user don't need to know or care what headers
are already set. For instance, by default existing headers are silently
overwritten.
If you try to unset a header after the headers have gone out,
presumably the same nifty message about WHERE the header was set would
be output.
Yes - the same error message is generated for header('Foo') and header('Foo:
bar').
But then to be truly pedantic, what if you unset a header that was
never set in the first place, after the headers have gone out? Is
this an error or any kind?
Yes - header() always generates an error when called after the headers have
gone out. This is analog to the current behaviour when setting a header that
was already set.
Just trying to anticipate all the edge cases. :-)
I appreciate that :-) I should probably add checks for these to the phpt.
Christian
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
