[PHP-DEV] Re: [php-maint] [PHP-DEV] PHP 5.3.9 and is_a changes
On Sun, Oct 23, 2011 at 03:36:04PM -0700, Clint Byrum wrote: I appreciate the sentiments of all who have weighed in on this, and I do want to make sure that we are paying attention to the greater PHP community's needs, not just Ubuntu's users. Shipping really old PHP versions is definitely not what we want to do. At the same time, in 5 years I don't think 5.4 will be that much newer feeling than a late 5.3 release, both will likely not be supported by the PHP authors, and people will complain that it's out of date no matter what. So imo it's ultimately a matter of which version is more stable and can be better supported by the package maintainers and security teams in question. I don't yet have an opinion on that, but would defer to other members of the debian team if they did. And note that just because it's the default/supported version does not mean that those distro-users are left up the creek without a paddle. Both ubuntu and debian provide multiple avenues for stable/LTS users to get newer software installed from backport/ppa type repositories, and they're also free to install from source if those packages do not meet their needs. 4) We need it *at least* in Debian experimental, preferrably in Debian unstable. I have not discussed this at all with the Debian PHP maintainers, so this is a big unknown. I've cc'd them for their comment. I do see that 5.4.0 beta is in experimental as of yesterday, so I suspect this will happen naturally. I'm not sure we have a solid plan/timeline on this, but FYI if you sync'd the last 5.3.x version from us the source package was slightly fubar'd (somehow got turned into a native package). We'll probably fix it with an epoch'd upload or just wait until 5.4 is ready enough for unstable, but I don't think we've decided on which yet. sean -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Re: [php-maint] [PHP-DEV] PHP 5.3.9 and is_a changes
Just my two cents, Most likely someone that has a system that they expect to last for five years is going to set it up and forget about it. So they probably don't care that it's up to date. They just want it to work. If not they'll likely either compile their own php or be updating their system long before five years is up. Sent from my iPhone On Oct 24, 2011, at 3:21 AM, sean finney sean...@seanius.net wrote: On Sun, Oct 23, 2011 at 03:36:04PM -0700, Clint Byrum wrote: I appreciate the sentiments of all who have weighed in on this, and I do want to make sure that we are paying attention to the greater PHP community's needs, not just Ubuntu's users. Shipping really old PHP versions is definitely not what we want to do. At the same time, in 5 years I don't think 5.4 will be that much newer feeling than a late 5.3 release, both will likely not be supported by the PHP authors, and people will complain that it's out of date no matter what. So imo it's ultimately a matter of which version is more stable and can be better supported by the package maintainers and security teams in question. I don't yet have an opinion on that, but would defer to other members of the debian team if they did. And note that just because it's the default/supported version does not mean that those distro-users are left up the creek without a paddle. Both ubuntu and debian provide multiple avenues for stable/LTS users to get newer software installed from backport/ppa type repositories, and they're also free to install from source if those packages do not meet their needs. 4) We need it *at least* in Debian experimental, preferrably in Debian unstable. I have not discussed this at all with the Debian PHP maintainers, so this is a big unknown. I've cc'd them for their comment. I do see that 5.4.0 beta is in experimental as of yesterday, so I suspect this will happen naturally. I'm not sure we have a solid plan/timeline on this, but FYI if you sync'd the last 5.3.x version from us the source package was slightly fubar'd (somehow got turned into a native package). We'll probably fix it with an epoch'd upload or just wait until 5.4 is ready enough for unstable, but I don't think we've decided on which yet. sean -- 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] BC break in 5.4, extending internal class
hi, Referring to: https://bugs.php.net/bug.php?id=55300 and in some extend to https://bugs.php.net/bug.php?id=55175 I tend to think that it could have a very bad impact on existing and will prevent many users to migrate easily to 5.4, or smoothly. I think we have to figure a fix for this problem while making it 100% BC with 5.3. I'd to discuss this problem before we go with the 1st RC. Cheers, -- Pierre @pierrejoye | http://blog.thepimp.net | http://www.libgd.org -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Revisit: Traits requiring composing class to implement interface
Stefan, Thanks for the reply. I disagree on a few points that you made however. See below for my reply. Please refer to: https://wiki.php.net/rfc/horizontalreuse#handling_of_propertiesstate Traits do not provide any provisioning for handling state. The original RFC was correct in that traits should not have any state. However the implementation differs from the RFC significantly in that respect. What you observe is that PHP is a very dynamic language when it comes to the definition of fields. And that is what traits also take into account. We do the minimal possible thing, to keep the WTF factor low, but there is no real support for state. And as someone else pointed out: the main difference is indeed the difference between linear application (mixins) and order-less composition (traits). Incorrect. Traits can explicitly define properties which actually prevent the parent class from changing this. See these two examples: http://codepad.viper-7.com/fqD91I and http://codepad.viper-7.com/DFDpqM So there is absolutely 100% support for state here. I could understand if it was a dynamic property or the like, but this is really state. The relevant part of the RFC: https://wiki.php.net/rfc/horizontalreuse#conflict_resolution We abandoned the idea of an explicit exclude operator long ago. (I think it was never in the PHP SVN.) Thus, the situation you describe cannot occur in the sense that a method is missing from the class. However, you can of course provide incompatible method implementations. (Which does not make traits any different from any other way to implement an interface.) The situation can absolutely happen simply with the conflict resolution (as you say). In fact, that way is worse since the signatures are different it means that you literally cannot use both traits (with the situation I originally described, all it would take is implementing a dummy method to complete the interface). As I said before, traits are supposed to be the symmetric dual to interfaces. Implementation without any contract. If we take a look at the following table, you can see that one corner is currently empty. And that corner is the one that's supposed to be filled by traits. If we allow traits to implement an interface, that corner remains empty... __|_Implementation_|_Contract Implementation_| Interface___|_Class Contract___| Class_|_??? Again, just my $0.02... Anthony -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] BC break in 5.4, extending internal class
On Mon, Oct 24, 2011 at 2:53 PM, Pierre Joye pierre@gmail.com wrote: hi, Referring to: https://bugs.php.net/bug.php?id=55300 and in some extend to https://bugs.php.net/bug.php?id=55175 I tend to think that it could have a very bad impact on existing and will prevent many users to migrate easily to 5.4, or smoothly. I think we have to figure a fix for this problem while making it 100% BC with 5.3. I'd to discuss this problem before we go with the 1st RC. Pierre, Is it too much deviation to auto-call the DirectoryIterator constructor if the dev made a __construct() in the child class but didn't call the parent construct(), ONLY when the DirectoryIterator's functionality is referenced. Aka a lazy-load check. It's a silent call, and i'm not in favour of silent stuff but maybe this has sparked a few ideas for people reading this discussion to come up with a less magic solution. Regards, Paul Dragoonis. Cheers, -- Pierre @pierrejoye | http://blog.thepimp.net | http://www.libgd.org -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] BC break in 5.4, extending internal class
Em Mon, 24 Oct 2011 14:53:07 +0100, Pierre Joye pierre@gmail.com escreveu: https://bugs.php.net/bug.php?id=55300 and in some extend to https://bugs.php.net/bug.php?id=55175 I tend to think that it could have a very bad impact on existing and will prevent many users to migrate easily to 5.4, or smoothly. I think we have to figure a fix for this problem while making it 100% BC with 5.3. I'd to discuss this problem before we go with the 1st RC. (context: this is the problem of calling internal methods on objects that were not properly constructed). The change I did in 5.4 should be reverted and synced with 5.3 in the short term because it doesn't work reliably (even not considering the BC break) -- there are other methods for getting an invalid instance (the new reflection method and unserialize, at least). But even in 5.3, there are in SPL counter-measures that don't work reliably, like making a check in get_method. Last month, Etienne was exploring the possibilities for this problem, but I don't think he got to any good solution. In the medium term, either direct calls to zend_object_store_get_object are banned and every method goes through a class-specific wrapper or we come up with a better solution (the only think I came up with in the discussion last time was enforcing the restriction on zend_do_fcall_common_helper/zend_call_function by calling a validation callback stored in the class_entry every time an internal method is to be called). -- Gustavo Lopes -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [RFC] DateTime and Daylight Saving Time Transitions
Hi: https://wiki.php.net/rfc/datetime_and_daylight_saving_time I will move this to voting phase tomorrow unless I hear objections. Thanks, --Dan -- T H E A N A L Y S I S A N D S O L U T I O N S C O M P A N Y data intensive web and database programming http://www.AnalysisAndSolutions.com/ 4015 7th Ave #4, Brooklyn NY 11232 v: 718-854-0335 f: 718-854-0409 -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] SplClassLoader
Hi internals, It's been a while since Stas accepted that, but it seems the class haven't been merged since then. What's the status of this? Can I expect SplClassLoader in 5.4.0? It seems it was approved, but wasn't merged and thread was lost in space. =( There's an RFC for it: https://wiki.php.net/rfc/splclassloader There's a patch for it: https://github.com/metagoto/splclassloader I'm not 100% sure the patch still works since it's been over 1 year since it was proposed... =\ Cheers, On Fri, Jul 15, 2011 at 4:07 PM, Stas Malyshev smalys...@sugarcrm.com wrote: Hi! On 6/29/11 6:31 AM, Mike Willbanks wrote: There's a RFC covering this. There's a patch also. https://wiki.php.net/rfc/splclassloader This one seems to have fallen through the cracks? Well, nobody proposed it in time (especially not the RFC author :) * The other implementation I could see is to modify spl_autoload to be able to pass it a parameter for the auto loading type - right now it will attempt to autoload everything lowercase (been brought up a few times). I think the class looks better. I think RFC needs to be expanded with description of what the class actually does and how, and then if there are no objections I think we could take it into 5.4.0, since the implementation already exists. -- Stanislav Malyshev, Software Architect SugarCRM: http://www.sugarcrm.com/ (408)454-6900 ext. 227 -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php -- Guilherme Blanco Mobile: +55 (11) 8118-4422 MSN: guilhermebla...@hotmail.com São Paulo - SP/Brazil -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] SplClassLoader
On Mon, Oct 24, 2011 at 3:47 PM, guilhermebla...@gmail.com guilhermebla...@gmail.com wrote: Hi internals, It's been a while since Stas accepted that, but it seems the class haven't been merged since then. What's the status of this? Can I expect SplClassLoader in 5.4.0? It seems it was approved, but wasn't merged and thread was lost in space. =( There's an RFC for it: https://wiki.php.net/rfc/splclassloader There's a patch for it: https://github.com/metagoto/splclassloader I'm not 100% sure the patch still works since it's been over 1 year since it was proposed... =\ I was also looking for this yesterday while implementing namespaces into my project to be PSR-0 complaint. I did see metagoto's implementation however would prefer to see something in /ext/* Lets push it ! all major php libs would significantly benefit from this addition from user-land into core. - Paul Dragoonis. Cheers, On Fri, Jul 15, 2011 at 4:07 PM, Stas Malyshev smalys...@sugarcrm.com wrote: Hi! On 6/29/11 6:31 AM, Mike Willbanks wrote: There's a RFC covering this. There's a patch also. https://wiki.php.net/rfc/splclassloader This one seems to have fallen through the cracks? Well, nobody proposed it in time (especially not the RFC author :) * The other implementation I could see is to modify spl_autoload to be able to pass it a parameter for the auto loading type - right now it will attempt to autoload everything lowercase (been brought up a few times). I think the class looks better. I think RFC needs to be expanded with description of what the class actually does and how, and then if there are no objections I think we could take it into 5.4.0, since the implementation already exists. -- Stanislav Malyshev, Software Architect SugarCRM: http://www.sugarcrm.com/ (408)454-6900 ext. 227 -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php -- Guilherme Blanco Mobile: +55 (11) 8118-4422 MSN: guilhermebla...@hotmail.com São Paulo - SP/Brazil -- 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] SplClassLoader
On 24 October 2011 16:53, Paul Dragoonis dragoo...@gmail.com wrote: On Mon, Oct 24, 2011 at 3:47 PM, guilhermebla...@gmail.com guilhermebla...@gmail.com wrote: Hi internals, It's been a while since Stas accepted that, but it seems the class haven't been merged since then. What's the status of this? Can I expect SplClassLoader in 5.4.0? It seems it was approved, but wasn't merged and thread was lost in space. =( There's an RFC for it: https://wiki.php.net/rfc/splclassloader There's a patch for it: https://github.com/metagoto/splclassloader If we can identify where we want it in the structure of the PHP project, I'll be happy to merge the implementation and modify the config files to have --enable-spl-autoloader or such. Does anyone have a preference for this? /ext/spl/ /ext/spl-loader/ /ext/spl-autoloader/ -- David Coallier -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] SplClassLoader
On Mon, Oct 24, 2011 at 3:57 PM, David Coallier dav...@php.net wrote: On 24 October 2011 16:53, Paul Dragoonis dragoo...@gmail.com wrote: On Mon, Oct 24, 2011 at 3:47 PM, guilhermebla...@gmail.com guilhermebla...@gmail.com wrote: Hi internals, It's been a while since Stas accepted that, but it seems the class haven't been merged since then. What's the status of this? Can I expect SplClassLoader in 5.4.0? It seems it was approved, but wasn't merged and thread was lost in space. =( There's an RFC for it: https://wiki.php.net/rfc/splclassloader There's a patch for it: https://github.com/metagoto/splclassloader If we can identify where we want it in the structure of the PHP project, I'll be happy to merge the implementation and modify the config files to have --enable-spl-autoloader or such. Does anyone have a preference for this? /ext/spl/ /ext/spl-loader/ /ext/spl-autoloader/ Hey David, Since it has the prefix 'Spl' then I think it makes sense to add it as a class to the existing /ext/spl/ extension, having it as its own extension would be overkill me thinks. - Paul Dragoonis. -- David Coallier -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] SplClassLoader
On 24 October 2011 15:57, David Coallier dav...@php.net wrote: On 24 October 2011 16:53, Paul Dragoonis dragoo...@gmail.com wrote: On Mon, Oct 24, 2011 at 3:47 PM, guilhermebla...@gmail.com guilhermebla...@gmail.com wrote: Hi internals, It's been a while since Stas accepted that, but it seems the class haven't been merged since then. What's the status of this? Can I expect SplClassLoader in 5.4.0? It seems it was approved, but wasn't merged and thread was lost in space. =( There's an RFC for it: https://wiki.php.net/rfc/splclassloader There's a patch for it: https://github.com/metagoto/splclassloader If we can identify where we want it in the structure of the PHP project, I'll be happy to merge the implementation and modify the config files to have --enable-spl-autoloader or such. Forgive me for not reading the code (yet) but what need is there for an --enable-spl-autoloader flag? What are peoples' thoughts on the name of the class? The word auto fits best with all that has come before, yet the proposal here uses class: what about SplAutoloader? With the introduction of this new class, whatever the name, what happens to __autoload() and spl_autoload_register(), if anything? How many ways do we want/need to load a class? Does anyone have a preference for this? /ext/spl/ /ext/spl-loader/ /ext/spl-autoloader/ IMO, new SPL functionality should live in ext/spl, we don't want to spread the standard library too far and wide. -- David Coallier -- 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] SplClassLoader
hi, I'd to be in favor to include it. However I would like to hear more from the people behind PSR-0 to be sure that it is actually what is needed and to complete the RFC (it is rather missing real info, examples and tests). Please also update the patch and attach it to the RFC. Cheers, On Mon, Oct 24, 2011 at 4:47 PM, guilhermebla...@gmail.com guilhermebla...@gmail.com wrote: Hi internals, It's been a while since Stas accepted that, but it seems the class haven't been merged since then. What's the status of this? Can I expect SplClassLoader in 5.4.0? It seems it was approved, but wasn't merged and thread was lost in space. =( There's an RFC for it: https://wiki.php.net/rfc/splclassloader There's a patch for it: https://github.com/metagoto/splclassloader I'm not 100% sure the patch still works since it's been over 1 year since it was proposed... =\ Cheers, On Fri, Jul 15, 2011 at 4:07 PM, Stas Malyshev smalys...@sugarcrm.com wrote: Hi! On 6/29/11 6:31 AM, Mike Willbanks wrote: There's a RFC covering this. There's a patch also. https://wiki.php.net/rfc/splclassloader This one seems to have fallen through the cracks? Well, nobody proposed it in time (especially not the RFC author :) * The other implementation I could see is to modify spl_autoload to be able to pass it a parameter for the auto loading type - right now it will attempt to autoload everything lowercase (been brought up a few times). I think the class looks better. I think RFC needs to be expanded with description of what the class actually does and how, and then if there are no objections I think we could take it into 5.4.0, since the implementation already exists. -- Stanislav Malyshev, Software Architect SugarCRM: http://www.sugarcrm.com/ (408)454-6900 ext. 227 -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php -- Guilherme Blanco Mobile: +55 (11) 8118-4422 MSN: guilhermebla...@hotmail.com São Paulo - SP/Brazil -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php -- Pierre @pierrejoye | http://blog.thepimp.net | http://www.libgd.org -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] SplClassLoader
I've been following this but not on the internal portions of PSR-0... Why it is needed: Currently all of the implementations on the autoloading side is pushed in through a custom class or function inside of spl_autoload whereas the registered autoloading takes place. Currently each framework that utilizes this implements it within their own source code: * ZF: http://framework.zend.com/apidoc/1.11/db_Loader_Autoloader.html#%5CZend_Loader_Autoloader * Symfony: https://github.com/symfony/ClassLoader By standardizing this inside of an extension gains us 2 very major features (IMO): 1. Extension would force the standard but could be extended to add in various needs in the event there is additional functionality. 2. Easier for someone to implement PSR-0 without having to create a custom autoloader elsewhere The speed of this should give us a slight bump (only slight seeing as w/o the use of absolute paths apc doesn't really gain us anything). Overall; it should clean up the various implementations that are scattered about. Additionally; this should gain greater acceptance and an easier implementations by people creating their custom frameworks or leveraging something such as PSR-0. From the RFC prospective it does seem like many things are missing: 1. Examples * The easiest example being that of a folder structure and class naming such as in PSR-0 with the instance of the autoloader. 2. Use Cases * Examples of framework cases... additionally extending framework libraries in separate folders. Regards, Mike On Mon, Oct 24, 2011 at 11:25 AM, Pierre Joye pierre@gmail.com wrote: hi, I'd to be in favor to include it. However I would like to hear more from the people behind PSR-0 to be sure that it is actually what is needed and to complete the RFC (it is rather missing real info, examples and tests). Please also update the patch and attach it to the RFC. Cheers, On Mon, Oct 24, 2011 at 4:47 PM, guilhermebla...@gmail.com guilhermebla...@gmail.com wrote: Hi internals, It's been a while since Stas accepted that, but it seems the class haven't been merged since then. What's the status of this? Can I expect SplClassLoader in 5.4.0? It seems it was approved, but wasn't merged and thread was lost in space. =( There's an RFC for it: https://wiki.php.net/rfc/splclassloader There's a patch for it: https://github.com/metagoto/splclassloader I'm not 100% sure the patch still works since it's been over 1 year since it was proposed... =\ Cheers, On Fri, Jul 15, 2011 at 4:07 PM, Stas Malyshev smalys...@sugarcrm.com wrote: Hi! On 6/29/11 6:31 AM, Mike Willbanks wrote: There's a RFC covering this. There's a patch also. https://wiki.php.net/rfc/splclassloader This one seems to have fallen through the cracks? Well, nobody proposed it in time (especially not the RFC author :) * The other implementation I could see is to modify spl_autoload to be able to pass it a parameter for the auto loading type - right now it will attempt to autoload everything lowercase (been brought up a few times). I think the class looks better. I think RFC needs to be expanded with description of what the class actually does and how, and then if there are no objections I think we could take it into 5.4.0, since the implementation already exists. -- Stanislav Malyshev, Software Architect SugarCRM: http://www.sugarcrm.com/ (408)454-6900 ext. 227 -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php -- Guilherme Blanco Mobile: +55 (11) 8118-4422 MSN: guilhermebla...@hotmail.com São Paulo - SP/Brazil -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php -- Pierre @pierrejoye | http://blog.thepimp.net | http://www.libgd.org
Re: [PHP-DEV] SplClassLoader
Hi! On 10/24/11 9:45 AM, Mike Willbanks wrote: By standardizing this inside of an extension gains us 2 very major features (IMO): But we already have the extension, don't we? From the RFC prospective it does seem like many things are missing: 1. Examples * The easiest example being that of a folder structure and class naming such as in PSR-0 with the instance of the autoloader. 2. Use Cases * Examples of framework cases... additionally extending framework libraries in separate folders. Yes, the RFC is not really up-to-date or complete. Another thing is I wouldn't really want to add anything that isn't a bugfix or BC fix or anything of this nature after RC1 is out. So if there's support for getting it into SPL, proper RFC, consensus gathering, patch, and all the process should be complete by Nov. 10, otherwise it's not in for 5.4.0. -- Stanislav Malyshev, Software Architect SugarCRM: http://www.sugarcrm.com/ (408)454-6900 ext. 227 -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] SplClassLoader
On Mon, Oct 24, 2011 at 10:20 AM, Peter Cowburn petercowb...@gmail.comwrote: On 24 October 2011 15:57, David Coallier dav...@php.net wrote: On 24 October 2011 16:53, Paul Dragoonis dragoo...@gmail.com wrote: On Mon, Oct 24, 2011 at 3:47 PM, guilhermebla...@gmail.com guilhermebla...@gmail.com wrote: Hi internals, It's been a while since Stas accepted that, but it seems the class haven't been merged since then. What's the status of this? Can I expect SplClassLoader in 5.4.0? It seems it was approved, but wasn't merged and thread was lost in space. =( There's an RFC for it: https://wiki.php.net/rfc/splclassloader There's a patch for it: https://github.com/metagoto/splclassloader If we can identify where we want it in the structure of the PHP project, I'll be happy to merge the implementation and modify the config files to have --enable-spl-autoloader or such. Forgive me for not reading the code (yet) but what need is there for an --enable-spl-autoloader flag? I agree; I do not believe that there is a need for an enable flag in this case. It should just be there or not at all. What are peoples' thoughts on the name of the class? The word auto fits best with all that has come before, yet the proposal here uses class: what about SplAutoloader? With the introduction of this new class, whatever the name, what happens to __autoload() and spl_autoload_register(), if anything? How many ways do we want/need to load a class? I believe by calling a class SplAutoloader when there is already an implementation of spl_autoload that does something very different it would be advised to not name it of the same sort... this is what people would start to think about. The name SplClassLoader is much more specific. If we needed to keep the word Auto it would seem better named SplClassAutoLoader. spl_autoload is completely separate from __autoload today. Also __autoload does differ from the spl_autoload facility in several ways and is not recommended even from the manual standpoint: www.php.net/autoload. Secondarily; a class loader cannot autoload functions - it is made to only implement PSR-0 and nothing more. While you may use spl_autoload to load classes the implementation can also load in functions. This class is really just enforcing a specific standardization.
Re: [PHP-DEV] SplClassLoader
What are peoples' thoughts on the name of the class? The word auto fits best with all that has come before, yet the proposal here uses class: what about SplAutoloader? With the introduction of this new class, whatever the name, what happens to __autoload() and spl_autoload_register(), if anything? How many ways do we want/need to load a class? I believe by calling a class SplAutoloader when there is already an implementation of spl_autoload that does something very different it would be advised to not name it of the same sort... this is what people would start to think about. The name SplClassLoader is much more specific. If we needed to keep the word Auto it would seem better named SplClassAutoLoader. spl_autoload is completely separate from __autoload today. Also __autoload does differ from the spl_autoload facility in several ways and is not recommended even from the manual standpoint: www.php.net/autoload. Secondarily; a class loader cannot autoload functions - it is made to only implement PSR-0 and nothing more. While you may use spl_autoload to load classes the implementation can also load in functions. This class is really just enforcing a specific standardization. I've started toying around with adjusting the patch. A bit of rewrite is required but I'm attempting to modify the patch to be included directly in SPL with the name SplClassLoader so that one can do: $cl = new \SplClassLoader(..., ...); Once the patch is adjusted to fit with SPL, we can revisit the name however it is going to be used. -- David Coallier -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [RFC] DateTime and Daylight Saving Time Transitions
Hi!
https://wiki.php.net/rfc/datetime_and_daylight_saving_time
I will move this to voting phase tomorrow unless I hear objections.
Not an objection but more a side question - is this related to fixing
TLA timezones in general? Right now they fail in a multitude of
scenarios which have nothing to do with transitions, such as:
$t = new DateTime('2010-07-06 18:38:28 EDT');
$ts = $t-format('U');
$t-setTimestamp($ts);
var_dump($t);
--
Stanislav Malyshev, Software Architect
SugarCRM: http://www.sugarcrm.com/
(408)454-6900 ext. 227
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] Patch to allow for Custom Application name in MSSQL connection
We currently use the php-mssql package (in conjunction with FreeTDS) for our setup. In other languages connecting to MSSQL we have come to rely on the Application Name being visible in Traces and the MSSQL profiler. In PHP it gets hard coded to 'PHP 5' even if there are multiple PHP applications connecting to the database. We have submitted a patch to add the ability for you to set the application name in the mssql_connect/mssql_pconnect function as an additional / optional parameter. This has been working great for us, so we wanted to see if we could contribute it back. Please let me know if there is any other information or anything else we could do to improve the patch/bug submission so that we can use this as a learning experience and improve future submissions. https://bugs.php.net/bug.php?id=60124 We have a few more non-related features we are vetting out in dev/production on our side prior to submitting. Also please let me know if this email should be routed to another list. Thanks, -Dan -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [RFC] DateTime and Daylight Saving Time Transitions
Hi Stas:
On Mon, Oct 24, 2011 at 09:57:51AM -0700, Stas Malyshev wrote:
Not an objection but more a side question - is this related to
fixing TLA timezones in general? Right now they fail in a multitude
of scenarios which have nothing to do with transitions, such as:
$t = new DateTime('2010-07-06 18:38:28 EDT');
$ts = $t-format('U');
$t-setTimestamp($ts);
var_dump($t);
Fun! I have a feeling that has the same underlying issue as
https://bugs.php.net/bug.php?id=55253 which needs to be fixed as part of
implementing the RFC.
Thanks,
--Dan
--
T H E A N A L Y S I S A N D S O L U T I O N S C O M P A N Y
data intensive web and database programming
http://www.AnalysisAndSolutions.com/
4015 7th Ave #4, Brooklyn NY 11232 v: 718-854-0335 f: 718-854-0409
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] 5.4.0 beta2
Hi Stas: The next release is planned to be RC1 and is scheduled for November 10. You want the DateTime DST fixing RFC (https://wiki.php.net/rfc/datetime_and_daylight_saving_time) implemented before RC1, right? If so, keep in mind that voting on it will start tomorrow and finish on November 1. Then someone needs to implement it. The deadline may need adjusting. Thanks, --Dan -- T H E A N A L Y S I S A N D S O L U T I O N S C O M P A N Y data intensive web and database programming http://www.AnalysisAndSolutions.com/ 4015 7th Ave #4, Brooklyn NY 11232 v: 718-854-0335 f: 718-854-0409 -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] 5.4.0 beta2
On Mon, 24 Oct 2011, Daniel Convissor wrote: The next release is planned to be RC1 and is scheduled for November 10. You want the DateTime DST fixing RFC (https://wiki.php.net/rfc/datetime_and_daylight_saving_time) implemented before RC1, right? If so, keep in mind that voting on it will start tomorrow and finish on November 1. Then someone needs to implement it. The deadline may need adjusting. I don't see why this requires voting. It's a bug fix. I'm going to set some time apart for this in the week of November 7th. cheers, Derick -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] 5.4.0 beta2
Hi Derick: On Mon, Oct 24, 2011 at 08:31:20PM +0100, Derick Rethans wrote: On Mon, 24 Oct 2011, Daniel Convissor wrote: https://wiki.php.net/rfc/datetime_and_daylight_saving_time I don't see why this requires voting. It's a bug fix. While it's kind of a bug fix, it's also asking for agreement on what the behaviors should be. I'm going to set some time apart for this in the week of November 7th. Thanks, --Dan -- T H E A N A L Y S I S A N D S O L U T I O N S C O M P A N Y data intensive web and database programming http://www.AnalysisAndSolutions.com/ 4015 7th Ave #4, Brooklyn NY 11232 v: 718-854-0335 f: 718-854-0409 -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] 5.4.0 beta2
Hi! You want the DateTime DST fixing RFC (https://wiki.php.net/rfc/datetime_and_daylight_saving_time) implemented before RC1, right? If so, keep in mind that voting on it will start tomorrow and finish on November 1. Then someone needs to implement it. The deadline may need adjusting. As Derick mentioned, if it's a bugfix and doesn't substantially change stuff and does not cause controversy we don't need a long time to vote. As for the deadline, if we have an effort underway and we know we need an extra week to finish it, we'll postpone the release. -- Stanislav Malyshev, Software Architect SugarCRM: http://www.sugarcrm.com/ (408)454-6900 ext. 227 -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] BC break in 5.4, extending internal class
hi, On Mon, Oct 24, 2011 at 4:13 PM, Gustavo Lopes glo...@nebm.ist.utl.pt wrote: The change I did in 5.4 should be reverted and synced with 5.3 in the short term because it doesn't work reliably (even not considering the BC break) -- there are other methods for getting an invalid instance (the new reflection method and unserialize, at least). Please do the revert, as you did the commit in the 1st place. As far as I remember we have discussed this issue back then already as well. But even in 5.3, there are in SPL counter-measures that don't work reliably, like making a check in get_method. Right, but that's another concern and the same cautiousness should be taken there. Thanks! -- Pierre @pierrejoye | http://blog.thepimp.net | http://www.libgd.org -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] SplClassLoader
I've started toying around with adjusting the patch. A bit of rewrite is required but I'm attempting to modify the patch to be included directly in SPL with the name SplClassLoader so that one can do: $cl = new \SplClassLoader(..., ...); Once the patch is adjusted to fit with SPL, we can revisit the name however it is going to be used. For the record: https://gist.github.com/1310352 (I know there are Whitespaces issues, I'll get those resolved) I'll be adding the tests tomorrow morning and then making sure the RFC is adjusted. -- David Coallier -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] SplClassLoader
hi, Could you open a FR at bugs.php.net and attach the patch to it please? Could be easier to track (and the # to the RFC too :) On Mon, Oct 24, 2011 at 11:25 PM, David Coallier dav...@php.net wrote: I've started toying around with adjusting the patch. A bit of rewrite is required but I'm attempting to modify the patch to be included directly in SPL with the name SplClassLoader so that one can do: $cl = new \SplClassLoader(..., ...); Once the patch is adjusted to fit with SPL, we can revisit the name however it is going to be used. For the record: https://gist.github.com/1310352 (I know there are Whitespaces issues, I'll get those resolved) I'll be adding the tests tomorrow morning and then making sure the RFC is adjusted. -- David Coallier -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php -- Pierre @pierrejoye | http://blog.thepimp.net | http://www.libgd.org -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] SplClassLoader
Could you open a FR at bugs.php.net and attach the patch to it please? Could be easier to track (and the # to the RFC too :) Yeah I'll do that once I have the tests adjusted and once I know the patch actually works as expected. -- David Coallier -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Re: [php-maint] [PHP-DEV] PHP 5.3.9 and is_a changes
Hi, I have always disliked the lack of modern packages on Debian/Ubuntu distros, I feel like minor are misused as major versions, with an exaggerated fear to upgrade. It's like building web sites for IE6 because people are not allowed to upgrade to IE9, very frustrating for developers and hard to explain to stakeholders. (OT: so I welcomed Chrome/FF choice to bump major versions very frequently). Why can Ubuntu only support 5.3.x and not simply 5.x ? As far as I can see BC will be guaranteed, PHP maintainers are really committed to it, and only a new major version would be so problematic as many suggest. As a user, I would really encourage to include the latest stable 5.x and provide to the community all the available 5.x upgrade during the next 5 years (5.4, 5.5 etc). Those 105 php apps should be maintained or removed, not used as an excuse to slow down the community. Then, if a PHP 6 will ever be released, then someone will rightly wonder should we include PHP 6 in the next LST ? - my .02 - On 24 October 2011 14:39, Brad Proctor bproct...@gmail.com wrote: Just my two cents, Most likely someone that has a system that they expect to last for five years is going to set it up and forget about it. So they probably don't care that it's up to date. They just want it to work. If not they'll likely either compile their own php or be updating their system long before five years is up. Sent from my iPhone On Oct 24, 2011, at 3:21 AM, sean finney sean...@seanius.net wrote: On Sun, Oct 23, 2011 at 03:36:04PM -0700, Clint Byrum wrote: I appreciate the sentiments of all who have weighed in on this, and I do want to make sure that we are paying attention to the greater PHP community's needs, not just Ubuntu's users. Shipping really old PHP versions is definitely not what we want to do. At the same time, in 5 years I don't think 5.4 will be that much newer feeling than a late 5.3 release, both will likely not be supported by the PHP authors, and people will complain that it's out of date no matter what. So imo it's ultimately a matter of which version is more stable and can be better supported by the package maintainers and security teams in question. I don't yet have an opinion on that, but would defer to other members of the debian team if they did. And note that just because it's the default/supported version does not mean that those distro-users are left up the creek without a paddle. Both ubuntu and debian provide multiple avenues for stable/LTS users to get newer software installed from backport/ppa type repositories, and they're also free to install from source if those packages do not meet their needs. 4) We need it *at least* in Debian experimental, preferrably in Debian unstable. I have not discussed this at all with the Debian PHP maintainers, so this is a big unknown. I've cc'd them for their comment. I do see that 5.4.0 beta is in experimental as of yesterday, so I suspect this will happen naturally. I'm not sure we have a solid plan/timeline on this, but FYI if you sync'd the last 5.3.x version from us the source package was slightly fubar'd (somehow got turned into a native package). We'll probably fix it with an epoch'd upload or just wait until 5.4 is ready enough for unstable, but I don't think we've decided on which yet. sean -- 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] PHP 5.3.9 and is_a changes
hi Clint, On Mon, Oct 24, 2011 at 12:36 AM, Clint Byrum cl...@ubuntu.com wrote: I appreciate the sentiments of all who have weighed in on this, and I do want to make sure that we are paying attention to the greater PHP community's needs, not just Ubuntu's users. Shipping really old PHP versions is definitely not what we want to do. Well, PHP 5.3 is the current stable, it is not like it is that old (3 years already tho'). However, we do need to be able to support the release with updates. While 5.4 would probably mean more of those updates would be simple cherry picks from 5.4, it also means there would likely be a lot more of them, since 5.4.0 will undoubtedly be a more aggressive release than 5.3.9, and like any .0 release, it just won't have the exposure that 5.3.x has had. Well, things may change as we have now some stricter rules when it comes to BC breaks and related areas. Also, we have 105 PHP applications in Ubuntu, 2 of which are in our main component (ganglia and nagios), which means they are supported by our security team and developers for the entire lifecycle of a release. Its not likely that we would be able to test all 105 of them with PHP 5.4 before the release date, which may mean some of them will be quite broken, and also require stable release updates to fix. If you can list the ones which have unit tests, then we should definitively do test them now and here using php's snapshots. If your team could get this list shortly, we can them share resources to setup the automating testing. We already do that in our labs for a couple of applications and php's unit tests. Frameworks are coming too. Now, all of that said, I would love to have 5.4 as the version in 12.04. Since 103 of the 105 apps are community supported, that means we'd need a large community effort to make sure this is doable. Yes, and maybe the upstream teams of the respective apps would be willing to help. But it is a huge communication effort and any help is welcome. I'm working with some apps and mainly with frameworks lately (symfony being the most active here). Here's what would need to happen for 12.04 to ship with 5.4 instead of 5.3: 1) PHP needs to make a commitment to release very soon. Beta is fine for the first month or so of the cycle, but not more. I would suggest to read the following RFC and todos: https://wiki.php.net/rfc/releaseprocess https://wiki.php.net/todo/php54 I would not expect to have 5.4.0 final out before end of december or early next year. The rest is defined by the RFC. I think we can expect more frequent releases than what we used to do, but smaller, which is actually better. 2) App developers need to commit to testing their apps on the dev release of Ubuntu. If people are interested, I'd be happy to set up a jenkins instance somewhere and give people write access to a bzr/svn/git tree of tests to run daily on the dev release. That's something we can try to work together, by contacting the respective teams and get tests infrastructure together. The key is to get the testing results as frequently as possible. Thanks for coming to us to discuss this, it is very appreciated! Cheers, -- Pierre @pierrejoye | http://blog.thepimp.net | http://www.libgd.org -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Re: [php-maint] [PHP-DEV] PHP 5.3.9 and is_a changes
Am 25.10.2011 00:18, schrieb de...@lucato.it: As a user, I would really encourage to include the latest stable 5.x and provide to the community all the available 5.x upgrade during the next 5 years (5.4, 5.5 etc). Those 105 php apps should be maintained or removed, not used as an excuse to slow down the community the problem is that most php code out there is useless crap i maintain some hundret thousands line of codes since 10 years and did every php-upgrade even 4.x to 5.x without having more than a handful lines to optimize / replace the reason is that most developers out there too stupid to use E_ALL | E_STRICT on their machines and do not see any warnings while we have this error-level actibe on some hundret domains all scripts /applications have to run with this settings or fixed or removed from our servers - and would most developers act the same way you could easily upgrade to each php-version so crappy applications have to be removed from the distributions to prevent the neagtive impact of never use any new features because most servers out there are for years outdated _ this is possible over years in production environment if you have not to rely on broken apps: php-5.3.8-21.fc14.rh.20110823.x86_64 mysql-5.5.17-3.fc14.rh.20111022.x86_64 postfix-2.8.6-3.fc14.rh.20111024.x86_64 signature.asc Description: OpenPGP digital signature
Re: [PHP-DEV] Re: [php-maint] [PHP-DEV] PHP 5.3.9 and is_a changes
Excerpts from devis's message of Mon Oct 24 15:18:14 -0700 2011: Hi, I have always disliked the lack of modern packages on Debian/Ubuntu distros, I feel like minor are misused as major versions, with an exaggerated fear to upgrade. It's like building web sites for IE6 because people are not allowed to upgrade to IE9, very frustrating for developers and hard to explain to stakeholders. (OT: so I welcomed Chrome/FF choice to bump major versions very frequently). Why can Ubuntu only support 5.3.x and not simply 5.x ? As far as I can see BC will be guaranteed, PHP maintainers are really committed to it, and only a new major version would be so problematic as many suggest. As a user, I would really encourage to include the latest stable 5.x and provide to the community all the available 5.x upgrade during the next 5 years (5.4, 5.5 etc). Those 105 php apps should be maintained or removed, not used as an excuse to slow down the community. devis, Firefox and Chrome are leaf packages. They can bump versions and they only affect one package, themselves. This allows testing to be simple and definitive. PHP supports not only the 105 apps in the Ubuntu archive, but thousands upon thousands of PHP applications which people write to run on top of Ubuntu. By freezing around a single version, and emphatically reviewing each update to ensure it does not introduce any changes in behavior (even positive changes!) without a clear justification (fixing a critical bug for instance), users can be assured that the app they write for any given release of Ubuntu will continue to function for the life of that release. We actually do have a micro release exception process which we have in place for a few upstreams: https://wiki.ubuntu.com/StableReleaseUpdates/MicroReleaseExceptions PHP5 isn't actually that far off from the requirements there, just need to enable the regression tests in the build and have them all pass. As I understand it, PHP 5.4 will have that, so one more positive for that. Note that we also have the ubuntu-backports project which can be used to obtain newer versions in the older release. There is a requirement, however, that all dependent packages are smoke tested with each backport, so somebody would have to automate testing all of the PHP applications in Ubuntu before backports was a viable option. -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] SplClassLoader
Hi internals, For all those interested, I have updated the RFC with better explanation, included example implementation and also example usage. If you have any other wishes, doubts, etc, feel free to ask on this thread and I'll quickly answer here and also update the RFC accordingly. The url for the RFC is: https://wiki.php.net/rfc/splclassloader Cheers, On Mon, Oct 24, 2011 at 7:55 PM, David Coallier dav...@php.net wrote: Could you open a FR at bugs.php.net and attach the patch to it please? Could be easier to track (and the # to the RFC too :) Yeah I'll do that once I have the tests adjusted and once I know the patch actually works as expected. -- David Coallier -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php -- Guilherme Blanco Mobile: +55 (11) 8118-4422 MSN: guilhermebla...@hotmail.com São Paulo - SP/Brazil -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Revisit: Traits requiring composing class to implement interface
Hi Anthony: On 24 Oct 2011, at 07:06, Anthony Ferrara wrote: Please refer to: https://wiki.php.net/rfc/horizontalreuse#handling_of_propertiesstate Traits do not provide any provisioning for handling state. The original RFC was correct in that traits should not have any state. However the implementation differs from the RFC significantly in that respect. Please read the RFC. Thanks! Traits do not provide any provisioning for handling state. However, every behavior needs state to operate on, otherwise it could be just a static functional helper method. Thus, trait code will either need to use accessors, which is favorite way to go since it provides full traits semantics, or they use properties, which is possible but rather a convenience feature. Thus, the goal for a consistent language design is to raise awareness of the problem, promote the use of accessors, and break early in case the changes to a trait is potentially problematic for a class using it. This results in the following rules: [...] This is purely a matter of consistence with the dynamic nature of PHP. We allow explicit naming of the properties, and that is all. There is no handling of any semantics, there is no conflict resolution, there is no state merging, splitting or what ever you would need to have a powerful enough semantics for stateful traits. Thus, I maintain the position that our traits do not provide any handling for state. However, they break early when a conflict/incompatibility is assumed. That is all, nothing more. Traits can explicitly define properties which actually prevent the parent class from changing this. What is a parent class with regard to a trait? That concept does not exist. See these two examples: http://codepad.viper-7.com/fqD91I and http://codepad.viper-7.com/DFDpqM That is not a parent class, that is a using class or user, not a parent. So there is absolutely 100% support for state here. I could understand if it was a dynamic property or the like, but this is really state. As I outlined above, I disagree with that position. It does not mean that traits handle/have state! That only means that we cater for the nature of PHP. Perhaps the difference is academic, but it is quite important for me. We cannot do without that breaking early property, because being conservative here seems the best option we have at the moment. Bailing out in case of possible conflicts is the only way to avoid subtle bugs. But the semantics of the properties are exactly as if they are defined in the class, which means that there is no notion of state what so ever associate with the trait. It is only realized in the final class, and the corresponding object. The trait merely declares it. The relevant part of the RFC: https://wiki.php.net/rfc/horizontalreuse#conflict_resolution We abandoned the idea of an explicit exclude operator long ago. (I think it was never in the PHP SVN.) Thus, the situation you describe cannot occur in the sense that a method is missing from the class. However, you can of course provide incompatible method implementations. (Which does not make traits any different from any other way to implement an interface.) The situation can absolutely happen simply with the conflict resolution (as you say). I think, I do not understand what you are getting at. The problem that cannot occur is that you get a runtime error because a method is completely missing from a class. You can neither exclude nor rename a method. We do not have exclude, and we only got aliasing. Neither of these mechanisms will lead to a case where a method is completely missing from the eventual class. Implementation without any contract. Yes. Best regards Stefan -- Stefan Marr Software Languages Lab Vrije Universiteit Brussel Pleinlaan 2 / B-1050 Brussels / Belgium http://soft.vub.ac.be/~smarr Phone: +32 2 629 2974 Fax: +32 2 629 3525 -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
