Re: [PHP-DEV] Next major version must be 7 (Lessons learned from the ECMAScript committee)
Hi! E (for ergo): The next major version of PHP must be called 7, to avoid confusion. Could we not at least agree on this? Why should we care? When we have that version working, we could have long, nice and pleasant flame^H^H^H^H^Hdiscussion about it. Right now this is one question that we absolutely shouldn't bother with. -- Stanislav Malyshev, Zend Software Architect s...@zend.com http://www.zend.com/ (408)253-8829 MSN: s...@zend.com -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Bug # 50755
Stanley Sufficool wrote: > I have attached patches for bug # 50755 on bugs.php.net. These also > cleanup to PDO DBLIB code to have less of a memory footprint and to > prepare for other feature additions such as multiple rowset support. > > I have compiled and tested on x86. > > Can someone review and provide feedback. Thank you. > Hi Stanley, Persistence is good, but you might need to use another way to find someone who has the skills, interest and time to review it. Maybe ask around on IRC - #php-dev-win on Freenode? Chris -- Email: christopher.jo...@oracle.comTel: +1 650 506 8630 Blog: http://blogs.oracle.com/opal/ Free PHP Book: http://tinyurl.com/UGPOM -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] SVN Account Request: ondrej
Hi Pierre, On Wed, Mar 10, 2010 at 21:45, Pierre Joye wrote: > hi Ondrej, > > Your account can and certainly will be approved once you have provided > a serie of patches and they have been applied (already one in the > queue :). Ok, makes sense. BTW Are you considering to apply that "use internal crypt() only for algorithms unavailable" or not? If not, I am going to fill bugs for all those little bugs in m4 and crypt.c. > On Wed, Mar 10, 2010 at 6:41 PM, Hannes Magnusson > wrote: >> On Tue, Mar 9, 2010 at 15:28, OndĹej SurÄË wrote: >>> I'm one of Debian PHP maintainers. >>> >> >> Thats.. great.. and? :) And I don't think I need to fill bug for every brown-paper-bag bug I found in php. And since somebody asked Raphael Geissert to make a SVN account, since we have started running (and fixing failing) unit test in each build. >> You don't need PHP SVN karma to maintain the debian packages... JFTR...I am not 16 to strive for "karma". Ondrej -- OndÅej Surý http://blog.rfc1925.org/ -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] Re: [fw-webservices] Re: [PHP-DEV] RFC - "class underloading" -or- "ancestor overloading"
I also ran into this problem with Zend_Db_Select. I wanted to add a new constant to improve my usage of Zend_Db_Table#select(), but that method would always returns an instance of Zend_Db_Table_Select which extended Zend_Db_Select. There was no easy way for me to add my class constant without resorting to one of the 3 methods Chris mentioned. Another possible solution (although it would require a rewrite of the framework classes) is to avoid using "extends" entirely. This can be accomplished by using interfaces instead, which is explained in this article: http://www.javaworld.com/javaworld/jw-08-2003/jw-0801-toolbox.html Although the article is a bit dated and it's for Java, the concept still applies and can help developers make better use of framework code by inheriting only the implementations they need while providing alternate implementations when necessary. Maybe this can be a design paradigm to attempt to follow in ZF 2.0? -- Hector On Sat, Mar 13, 2010 at 8:10 AM, Richard Quadling wrote: > On 13 March 2010 01:50, Chris Trahey wrote: > > Perhaps a new concept in class-based OO programming, I'm not sure. > > > > Depending on your perspective you could call it ancestor overloading (or > > upstream overloading) or class underloading. > > > > > > We are increasingly developing with the aid of frameworks & libraries. In > > fact, this idea came from my current project using the Zend Framework. > > > > These libraries, while greatly extensible, are also fairly > self-extending. > > That is, they include many classes that extend many classes, which is > great. > > > > As consumers of these libraries, we can extend the classes and consume > the > > API however we please, but there is one sticking point. > > > > We cannot change classes that many other classes extend without extending > or > > changing each child class and then making sure that our code uses the new > > class. > > > > > > For a concrete example, I was working with the Zend_Form_Element > subclasses, > > and I realized that I wanted to change some of the default behavior (in > > Zend_Form_Element). > > > > - at this point I will assume the reader understands why I wouldn't want > to > > just start changing the Zend library files - > > > > There are many subclasses of Zend_Form_Element. If you want to change the > > default behavior for all of them, you have 3 choices currently: > > > > 1. Directly edit the Zend_Form_Element file in the library, -bad for > updates > > & other projects that use the library > > > > 2. subclass Zend_Form_Element and change declaration of the descendants > to > > extend new class - same problems > > > > 3. extend each child class and implement those subclasses in your app > code > > -very tedious and TONS of repeated code, breaks consistency of API for > > developers. > > > > > > There could be a better way, if we could insert a class into the family > > tree. > > > > And that's the heart of this idea, so I'll repeat it: > > > > * insert a class into the family tree * > > > > > > Image we do it using an alternative keyword to "extends", such as > > "overloads". > > > > > > Example: > > > > > > class Library_Class { } > > > > class Library_Subclass extends Library_Class {} > > > > and then: > > > > class My_LibClass_Overload overloads Library_Class{} > > > > > > Now new instances of Library_Subclass actually extend > My_LibClass_Overload, > > which "extends" Library_Class. The developer would then code > > My_LibClass_Overload as if it were declared like this: > > > > class Library_Class {} > > > > class My_LibClass_Overload extends Library_Class {} > > > > class Library_Subclass extends My_LibClass_Overload {} > > > > > > But indeed the declaration of Library_Subclass would *not* have to > change. > > > > > > This way developers could "extend" default functionality and have > *existing* > > library classes pick up the new functionality without redeclaring > anything > > in the library. > > > > Downstream classes would still override any methods that they redeclare. > If > > you wanted to have end-point classes in the library have different > behavior, > > you would overload them instead, such as > > > > class My_LibSubclass_Overload overloads Lib_Subclass {} > > > > > > The benefit is that the application code can still consume "standard" > > classes, such as Library_Subclass and not need to know or care about the > > extended functionality. > > > > > > Going back to my concrete example, my code could then still use > > Zend_Form_Element_Text, but benefit from the modifications I added, > without > > me having to touch the library code. > > > > > > I hope I've explained clearly what this could look like. I'm a younger > > developer, so forgive me if I'm rough on the terminology -perhaps > > overload/underload is not the best word for this functionality. Also, I'm > > not sure if there are other class-based OO languages that allow this kind > of > > behavior... Prototypal languages perhaps, as is the case w
Re: [PHP-DEV] Implementing fdopen in PHP
Le dimanche 14 mars 2010 à 17:38 +1100, Dennis Hotson a écrit : > Hi all, > > It's my first post, so go easy on me. :-) > > I'm trying to implement PHP support for github's erlang RPC server called > ernie. > So basically I've been porting the following ruby code to PHP: > http://github.com/mojombo/ernie/blob/master/lib/ernie.rb > > The problem I'm having is on line 127-128: > input = IO.new(3) > > I believe this is equivalent to fdopen() in C, but there doesn't appear to > be any way to do this in PHP. > > So basically, I'm a bit stuck and looking for advice on how to proceed. > Should I implement this in core PHP or as an extension? What's the best way > to get a function like this into PHP? Hi, I guess that this can go to some future PHP release, and in a small extension if you want to have it in current / older versions too. You can implement it with php_stream_fopen_from_fd(). Regards, -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Re: [fw-webservices] Re: [PHP-DEV] RFC - "class underloading" -or- "ancestor overloading"
The challenge of "never use extend" is that simply wrapping classes in decorators only goes so far. You can't always maintain interface compliance if you're nesting decorators, and if you're overriding only one out of a dozen or two methods then you have a lot of foo() { return $obj->foo(); } method implementations. Aside from being hard to read, that also eats up cycles for the extra stack calls. __call() can make it much less code but is also much slower. If there were a syntactic-level support for "wrap this object in this class and pass through any method that isn't redefined", a sort of sideways extends, that would become much simpler. I'm not sure what that would look like, though. Or perhaps this is a good time to revisit the traits proposal from a few months back? --Larry Garfield On Monday 15 March 2010 12:36:32 pm Hector Virgen wrote: > I also ran into this problem with Zend_Db_Select. I wanted to add a new > constant to improve my usage of Zend_Db_Table#select(), but that method > would always returns an instance of Zend_Db_Table_Select which extended > Zend_Db_Select. There was no easy way for me to add my class constant > without resorting to one of the 3 methods Chris mentioned. > > Another possible solution (although it would require a rewrite of the > framework classes) is to avoid using "extends" entirely. This can be > accomplished by using interfaces instead, which is explained in this > article: > > http://www.javaworld.com/javaworld/jw-08-2003/jw-0801-toolbox.html > > Although the article is a bit dated and it's for Java, the concept still > applies and can help developers make better use of framework code by > inheriting only the implementations they need while providing alternate > implementations when necessary. > > Maybe this can be a design paradigm to attempt to follow in ZF 2.0? > > -- > Hector > > > On Sat, Mar 13, 2010 at 8:10 AM, Richard Quadling > > wrote: > > On 13 March 2010 01:50, Chris Trahey wrote: > > > Perhaps a new concept in class-based OO programming, I'm not sure. > > > > > > Depending on your perspective you could call it ancestor overloading > > > (or upstream overloading) or class underloading. > > > > > > > > > We are increasingly developing with the aid of frameworks & libraries. > > > In fact, this idea came from my current project using the Zend > > > Framework. > > > > > > These libraries, while greatly extensible, are also fairly > > > > self-extending. > > > > > That is, they include many classes that extend many classes, which is > > > > great. > > > > > As consumers of these libraries, we can extend the classes and consume > > > > the > > > > > API however we please, but there is one sticking point. > > > > > > We cannot change classes that many other classes extend without > > > extending > > > > or > > > > > changing each child class and then making sure that our code uses the > > > new class. > > > > > > > > > For a concrete example, I was working with the Zend_Form_Element > > > > subclasses, > > > > > and I realized that I wanted to change some of the default behavior (in > > > Zend_Form_Element). > > > > > > - at this point I will assume the reader understands why I wouldn't > > > want > > > > to > > > > > just start changing the Zend library files - > > > > > > There are many subclasses of Zend_Form_Element. If you want to change > > > the default behavior for all of them, you have 3 choices currently: > > > > > > 1. Directly edit the Zend_Form_Element file in the library, -bad for > > > > updates > > > > > & other projects that use the library > > > > > > 2. subclass Zend_Form_Element and change declaration of the descendants > > > > to > > > > > extend new class - same problems > > > > > > 3. extend each child class and implement those subclasses in your app > > > > code > > > > > -very tedious and TONS of repeated code, breaks consistency of API for > > > developers. > > > > > > > > > There could be a better way, if we could insert a class into the family > > > tree. > > > > > > And that's the heart of this idea, so I'll repeat it: > > > > > > * insert a class into the family tree * > > > > > > > > > Image we do it using an alternative keyword to "extends", such as > > > "overloads". > > > > > > > > > Example: > > > > > > > > > class Library_Class { } > > > > > > class Library_Subclass extends Library_Class {} > > > > > > and then: > > > > > > class My_LibClass_Overload overloads Library_Class{} > > > > > > > > > Now new instances of Library_Subclass actually extend > > > > My_LibClass_Overload, > > > > > which "extends" Library_Class. The developer would then code > > > My_LibClass_Overload as if it were declared like this: > > > > > > class Library_Class {} > > > > > > class My_LibClass_Overload extends Library_Class {} > > > > > > class Library_Subclass extends My_LibClass_Overload {} > > > > > > > > > But indeed the declaration of Library_Subclass would *not* have to > > > > change. > > > > > This way developer
Re: [PHP-DEV] Re: [fw-webservices] Re: [PHP-DEV] RFC - "class underloading" -or- "ancestor overloading"
On Mon, Mar 15, 2010 at 2:14 PM, Larry Garfield wrote: > The challenge of "never use extend" is that simply wrapping classes in > decorators only goes so far. You can't always maintain interface > compliance > if you're nesting decorators, and if you're overriding only one out of a > dozen > or two methods then you have a lot of foo() { return $obj->foo(); } method > implementations. Aside from being hard to read, that also eats up cycles > for > the extra stack calls. __call() can make it much less code but is also > much > slower. > > If there were a syntactic-level support for "wrap this object in this class > and pass through any method that isn't redefined", a sort of sideways > extends, > that would become much simpler. I'm not sure what that would look like, > though. > > Or perhaps this is a good time to revisit the traits proposal from a few > months back? > While traits do seem pretty cool, the fundamental problem appears to be that Framework X doesn't let me do what I want. Unfortunately that is the side effect of using a framework, it does things for you. I had attempted to build a system like this in userland code to dynamically replace classes in my framework, but scrapped it because I could only see ways in which it would be abused. If someone replaces a class buried in a framework, that modifies some bit of functionality, which is depended on by a completely unrelated area of the framework, it could potentially cause issues that would be very hard to track down. This sounds a lot like aspect oriented programming in the ability to completely overwrite a function with userland code. I feel like the better solution is to fix the framework to allow the flexibility to do what you want in a controlled manner, and not bend the language to fix the framework. I don't mean to say that PHP is problem free or perfect, but I'm not sure this is the best method to fix the problem at hand. -- -Nathan Gordon If the database server goes down and there is no code to hear it, does it really go down? :wq
Re: [PHP-DEV] Re: [fw-webservices] Re: [PHP-DEV] RFC - "class underloading" -or- "ancestor overloading"
On Monday 15 March 2010 03:08:28 pm Nate Gordon wrote: > > If there were a syntactic-level support for "wrap this object in this > > class and pass through any method that isn't redefined", a sort of > > sideways extends, > > that would become much simpler. I'm not sure what that would look like, > > though. > > > > Or perhaps this is a good time to revisit the traits proposal from a few > > months back? > > While traits do seem pretty cool, the fundamental problem appears to be > that Framework X doesn't let me do what I want. Unfortunately that is the > side effect of using a framework, it does things for you. I had attempted > to build a system like this in userland code to dynamically replace > classes in my framework, but scrapped it because I could only see ways in > which it would be abused. If someone replaces a class buried in a > framework, that modifies some bit of functionality, which is depended on > by a completely unrelated area of the framework, it could potentially > cause issues that would be very hard to track down. This sounds a lot > like aspect oriented programming in the ability to completely overwrite a > function with userland code. > > I feel like the better solution is to fix the framework to allow the > flexibility to do what you want in a controlled manner, and not bend the > language to fix the framework. I don't mean to say that PHP is problem > free or perfect, but I'm not sure this is the best method to fix the > problem at hand. Certainly true; it's not PHP's job to work around framework flaws. However, if PHP can make it easier to make frameworks that don't have common flaws, that is something it can and IMO should do. Traits wouldn't fix the issue mentioned here, but might allow the framework to be written in a way that doesn't have, or at least ameliorates, these sorts of issues. Or perhaps there's a different approach besides traits that would work better. I dunno. :-) --Larry Garfield -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Where are we ACTUALLY on Unicode?
Hi! What I am probably asking is what was the brick wall PHP6 hit. I was under the impression that there was no agreement on 'switchable or only' to unicode core? ( And those who did write PHP6 books seemed to have their own views on which way the discussions would go ;) ). From what I can see, the biggest issues are these: 1. Performance - Unicode-based PHP right now requires tons of conversions when talking to outside world (like MySQL) which slows down the app significantly. Many extensions frequently used by PHP app writers (such as mysql, pcre, etc.) do not support UTF-16 properly. Also, inflated memory usage hurts scalability a lot. 2. Compatibility - it's hard to make existing app works with Unicode and doesn't lose in performance or doesn't have any weird scenarios where your passwords suddenly stop working because there's an extra recoding step in some md5() call. -- Stanislav Malyshev, Zend Software Architect s...@zend.com http://www.zend.com/ (408)253-8829 MSN: s...@zend.com -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Re: [fw-webservices] Re: [PHP-DEV] RFC - "class underloading" -or- "ancestor overloading"
On 15 March 2010 21:43, Larry Garfield wrote: > On Monday 15 March 2010 03:08:28 pm Nate Gordon wrote: > >> > If there were a syntactic-level support for "wrap this object in this >> > class and pass through any method that isn't redefined", a sort of >> > sideways extends, >> > that would become much simpler. I'm not sure what that would look like, >> > though. >> > >> > Or perhaps this is a good time to revisit the traits proposal from a few >> > months back? >> >> While traits do seem pretty cool, the fundamental problem appears to be >> that Framework X doesn't let me do what I want. Unfortunately that is the >> side effect of using a framework, it does things for you. I had attempted >> to build a system like this in userland code to dynamically replace >> classes in my framework, but scrapped it because I could only see ways in >> which it would be abused. If someone replaces a class buried in a >> framework, that modifies some bit of functionality, which is depended on >> by a completely unrelated area of the framework, it could potentially >> cause issues that would be very hard to track down. This sounds a lot >> like aspect oriented programming in the ability to completely overwrite a >> function with userland code. >> >> I feel like the better solution is to fix the framework to allow the >> flexibility to do what you want in a controlled manner, and not bend the >> language to fix the framework. I don't mean to say that PHP is problem >> free or perfect, but I'm not sure this is the best method to fix the >> problem at hand. > > Certainly true; it's not PHP's job to work around framework flaws. However, > if > PHP can make it easier to make frameworks that don't have common flaws, that > is > something it can and IMO should do. > > Traits wouldn't fix the issue mentioned here, but might allow the framework to > be written in a way that doesn't have, or at least ameliorates, these sorts of > issues. > > Or perhaps there's a different approach besides traits that would work better. > I dunno. :-) > > --Larry Garfield The ability to "registerASubClassForThisClass" idea (don't know the proper name for this), has certainly worked for me. -- - Richard Quadling "Standing on the shoulders of some very clever giants!" EE : http://www.experts-exchange.com/M_248814.html EE4Free : http://www.experts-exchange.com/becomeAnExpert.jsp Zend Certified Engineer : http://zend.com/zce.php?c=ZEND002498&r=213474731 ZOPA : http://uk.zopa.com/member/RQuadling -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php