Re: [PHP-DEV] Next major version must be 7 (Lessons learned from the ECMAScript committee)

2010-03-15 Thread Stanislav Malyshev

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

2010-03-15 Thread Christopher Jones



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

2010-03-15 Thread Ondřej Surý
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"

2010-03-15 Thread Hector Virgen
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

2010-03-15 Thread Arnaud Le Blanc
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"

2010-03-15 Thread Larry Garfield
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"

2010-03-15 Thread Nate Gordon
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"

2010-03-15 Thread Larry Garfield
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?

2010-03-15 Thread Stanislav Malyshev

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"

2010-03-15 Thread Richard Quadling
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