Re: [PHP-DEV] RFC: Traits for PHP
Stefan Marr wrote:
Hi Stanislav,
traits the included trait is using). Ok this is the scope. Now we
would need to adjust all those method bodies, find all method calls on
$this-oldMethodName() and change them to $this-newMethodName().
You can't - PHP has dynamic method resolution (think $this-$foo()).
Also, it has callbacks - what happens if method is registered as
callback is renamed?
thanks, this is very good reason not to allow renaming, but aliasing.
:)
Aliasing doesn't make a lot of sense, as you can always :
function newMethod() {
return $this-oldMethod();
}
just seems like unneeded complexity, without a clear benefit..
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Restore output buffer in case of exceptions
Mehmet Yavuz Selim Soyturk wrote:
Hello,
I'm sorry if that's the wrong list.
I am neither a PHP nor a webscripting guy so I'm sorry if this does
not make sense. I just thought that it could be useful.
PHP 5 supports exception handling. When an exception occurs, PHP does
stack unwinding so that it restores the state of the script. But an
important state of the script does not get restored: the output. Would
it not be a good idea if PHP also did some sort of output buffer
unwinding?
Generally I make sure that the parts of my code that start an output
buffer are also responsible for closing the output buffer.. so something
like this wouldn't be uncommon in my code..
ob_start();
try {
do_something();
} catch (Exception $e) {
ob_end_clean();
throw $e;
}
$data = ob_get_clean();
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] What is the use of unicode.semantics in PHP 6?
Andi Gutmans wrote: What I really think we need to do for this release, which we haven't been good at doing in the past, is build a PHP Compatibility Team which tries to port many applications to PHP 6 and finds the issues in doing this port (both with unicode_semantics=on/off). We can then learn from this experience and have good documentation on how to upgrade to both modes and in some cases, like we have done in the past 2-3 weeks, tweak PHP 6 to not break backwards compatibility. It is possible in many cases. I'd volunteer for this. Does it help you guys to get started with this today, or should I be waiting till there's more agreement on some of this stuff.. Evert -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] What is the use of unicode.semantics in PHP 6?
Andi Gutmans wrote: I think the sooner the better as it's valuable information for the dev team. It'd probably be a good idea to have a Wiki where we can document issues that/common use-cases which are encountered. Maybe we should have a Wiki on one of the php.net servers for such purposes? Andi Is anyone aware of a list with a, say top 10 PHP applications? When such a wiki is setup, how would you suggest to write such documents.. At least a generic guide would be good (e.g.: common pitfalls) Should I be documenting the per-project specifics as well? Evert -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] What is the use of unicode.semantics in PHP 6?
Larry Garfield wrote: Top 10 by what metric? If I had to guess based on market share, I'd say (unordered): Drupal Squirrelmail WordPress phpMyAdmin MediaWiki Joomla PHPBB That will keep me busy =) Evert -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] What is the use of unicode.semantics in PHP 6?
One final question.. should I assume while converting code unicode.semantics is on or off? If its on I would be making sure everything is properly casted to binary strings where this is needed, if it's off the focus would be on making sure the application runs on both PHP5 and PHP6.. What makes the most sense here? I would personally say I would try it assuming its off, as this is the most likely for the development teams to target for .. Evert Andi Gutmans wrote: I think the sooner the better as it's valuable information for the dev team. It'd probably be a good idea to have a Wiki where we can document issues that/common use-cases which are encountered. Maybe we should have a Wiki on one of the php.net servers for such purposes? Andi -Original Message- From: Evert | Rooftop [mailto:[EMAIL PROTECTED] Sent: Tuesday, July 10, 2007 9:40 AM To: Andi Gutmans Cc: Antony Dovgal; Andrei Zmievski; Stas Malyshev; internals@lists.php.net Subject: Re: [PHP-DEV] What is the use of unicode.semantics in PHP 6? Andi Gutmans wrote: What I really think we need to do for this release, which we haven't been good at doing in the past, is build a PHP Compatibility Team which tries to port many applications to PHP 6 and finds the issues in doing this port (both with unicode_semantics=on/off). We can then learn from this experience and have good documentation on how to upgrade to both modes and in some cases, like we have done in the past 2-3 weeks, tweak PHP 6 to not break backwards compatibility. It is possible in many cases. I'd volunteer for this. Does it help you guys to get started with this today, or should I be waiting till there's more agreement on some of this stuff.. Evert -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] RIP PHP 4?
My 2 cents: Before you guys are making any changes in the maintenance process, I think the end goal (dropping PHP4 support) can happen a lot smoother with good communication. You can start today by stating really clear on www.php.net that PHP4 support is going to be dropped in the future and considered 'old', also to Marco's point .. putting the downloads in the museum site will be a really clear statement even though you don't actually have to drop support for PHP4 till some time in the future.. Reading other people's comments it looks like getting people to switch to PHP5, but also remain faithful and supporting to your community is dear to people. The first step to achieve both is to change your communication, not the actual maintenance process. Evert Marco wrote: Also I would suggest removing links to PHP4 downloads away from the front page on the php.net site and maybe put them onto the museum site? Regards Marco -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] toString() and Object #ID
Hi Lars, In the meanwhile .. check out spl_object_hash Evert Lars Schultz wrote: Hi there I just tried to switch from 5.1 to 5.2.3 and got thrown off right away by: Object of class MyObject could not be converted to string I googled a bit and also read any Messages in the internals list but couldn't find a decisive answer as to wether this will stay this way or not. In the PHP 5 Bug Summary Report I found Bug # 40799 change string conversion behaviour for objects not implementing __toString() which is still open. I don't want to complain or anything but I'd like to know wether it's feasible to wait for a change in this current, modified, behaviour or if it's going to stay this way. I used the previous behaviour mostly for debugging purposes where I wanted to get a visual (string) handle for any given object, which helps ALOT when trying to figure out wether one has a copy or the original and wether to references point to the same object(obj1 === obj2 is not always helpful). Is there any other way than casting an object to a string to get an objects #ID? Thanks for your time. Lars -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] Using grand-parent constructor
Hi List, Sorry if this is the wrong list for this kind of stuff.. I'd be happy to re-post this to the users mailing list. With the recent updates that will raise E_STRICT on static calls that are non static, how do we properly do the following.. I have a class named 'GrandParent' a class named 'Parent' and a class named 'Child' GrandParent has a constructor, Parent overrides it and Child does too.. What if I want to call GrandParent's constructor from the child? Most languages allow this through casting the class into the ancestor and call then call the method, but I can't do this with PHP, or can I ? The other solution (right now) would be GrandParent::__construct(), but this is not OOP anymore.. So it seems kind of weird that we get limited in functionality, for OOP-ness, but not adding the functionality to solve common design problems that we're raised by introducing this.. Will we get casting in the future? Evert -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Using grand-parent constructor
Yes, but I want to ignore Parent behaviour, and Re-inherit GrandParent behaviour.. Evert Jasper Bryant-Greene wrote: adding parent::__construct() in the constructors of both Parent and Child should do what you want. Jasper Evert | Rooftop wrote: Hi List, Sorry if this is the wrong list for this kind of stuff.. I'd be happy to re-post this to the users mailing list. With the recent updates that will raise E_STRICT on static calls that are non static, how do we properly do the following.. I have a class named 'GrandParent' a class named 'Parent' and a class named 'Child' GrandParent has a constructor, Parent overrides it and Child does too.. What if I want to call GrandParent's constructor from the child? Most languages allow this through casting the class into the ancestor and call then call the method, but I can't do this with PHP, or can I ? The other solution (right now) would be GrandParent::__construct(), but this is not OOP anymore.. So it seems kind of weird that we get limited in functionality, for OOP-ness, but not adding the functionality to solve common design problems that we're raised by introducing this.. Will we get casting in the future? Evert -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] Feature request: ini setting for http 500 on fatal errors
Excuse me if this has been discussed before, but I would like to know the stance on this issue, it's hard to search the buglist or mailing archives on stuff like http, 500 and fatal. Would it be hard to implement an ini setting for throwing a http 500 error on a fatal error? It's hard to make certain applications and have proper error handling if there is no way to do anything on a fatal error.. It would be even grander if php could try to run a fall-back script when something really bad happens, but just having that 500 on fatal errors would be awesome .. If this is not going to happen anytime soon, would you accept a patch? Evert -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Feature request: ini setting for http 500 on fatal errors
Thats a smart idea.. I like that As for letting PHP do the 500, I tend to use output buffering everywhere (i think most people do, supposed to be faster too) so I'm used to setting header()'s wherever I need them.. Besides, in most of my script the business logic gets executed first, and this is where most errors can happen.. only after the presentation is done. So the solution would be, if fatal error is triggered, and headers_sent() is false then set the error to 500.. Is this possible? Evert Rasmus Lerdorf wrote: Evert | Rooftop wrote: Excuse me if this has been discussed before, but I would like to know the stance on this issue, it's hard to search the buglist or mailing archives on stuff like http, 500 and fatal. Would it be hard to implement an ini setting for throwing a http 500 error on a fatal error? It's hard to make certain applications and have proper error handling if there is no way to do anything on a fatal error.. It would be even grander if php could try to run a fall-back script when something really bad happens, but just having that 500 on fatal errors would be awesome .. If this is not going to happen anytime soon, would you accept a patch? How would you implement it. Fatal errors can happen after output has already been sent in which case it is too late to change the http status. And if you haven't sent anything yet, as in you are using output buffering, then it is rather trivial to do in user space. Simply start you script by setting the status to 500 and change it to 200 when you know you have good output to send. That way if a fatal error happens, the 500 will be sent. -Rasmus -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Feature request: ini setting for http 500 on fatal errors
Brian Moon wrote: Evert | Rooftop wrote: Thats a smart idea.. I like that As for letting PHP do the 500, I tend to use output buffering everywhere (i think most people do, supposed to be faster too) so I'm used to setting header()'s wherever I need them.. You think wrong. There are very good reasons not to use output buffering. calm down :S Besides, in most of my script the business logic gets executed first, and this is where most errors can happen.. only after the presentation is done. So the solution would be, if fatal error is triggered, and headers_sent() is false then set the error to 500.. This produces inconsistent behavior. I would not be in favor of it. I suggest you do as Rasmus suggested. Use register_shutdown_function() perhaps to have a function to change the status code before output is sent in your specific environment. Yea I do like that idea, didn't think of that approach. As for inconsistent behaviour.. It's not a huge deal, and the situation can easily described in the documentation. But yea, this is also why I proposed an ini setting. Rasmus' solution solves my problem though. Thanks a lot! Evert -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
