php 5.2.0

Ron Korving wrote:

Well, I'm in no position to ask anyone for anything, but... here goes anyway
;)

APC is a good caching mechanism, but is lacking in optimization features,
where for example (to my knowledge anyway) Zend Optimizer is doing a good
job. Since it looks like APC is going to be included in PHP 6 by default,
maybe it's getting more and more interesting to invest time in optimization
algorithms to enhance APC? I think it's probably the one area in which the
most performance gain for users can be achieved.

Not sure what this has to do with PHP 5.2.0, but yes, improving the
optimizer has been on the todo for a while. Volunteers are welcome.

-Rasmus

While adding an optimizer to APC is definitely a good thing, but
ultimately APC is an external tool, we want to make the language
itself to become faster. There are series of things that became a bit
slower since 4.4, some have been resolved, others are still pending.
These are the things 5.2 will attempt to address.

Well, I'm in no position to ask anyone for anything, but... here
goes anyway
;)

APC is a good caching mechanism, but is lacking in optimization
features,
where for example (to my knowledge anyway) Zend Optimizer is doing
a good
job. Since it looks like APC is going to be included in PHP 6 by
default,
maybe it's getting more and more interesting to invest time in
optimization
algorithms to enhance APC? I think it's probably the one area in
which the
most performance gain for users can be achieved.

Ilia Alshanetsky
Advanced Internet Designs Inc.
ilia@prohost.org

On Tue, 02 May 2006 21:25:41 +0200
akorthaus@web.de (Andreas Korthaus) wrote:

But perhaps that's something for 6.0...

That's all php 6.0 yes, maybe not http...

-- Pierre

Hi!

Ilia Alshanetsky wrote:

So, if you have changes you'd like to see in 5.2 (don't go too
wild now ;-) ), reply to this e-mail.

Some issues not yet in the wiki, which have been discussed on this
list some time ago:

1. date extension
   with OO interface and classname "Date" (don't forget about the
   PEAR::Date fun ;-))
   For the OO interface, AFAIR most people prefered something like:
   http://cvs.php.net/viewcvs.cgi/pecl/date/docs/examples/sample1.php?
   view=markup
   to something like: http://www.zend.com/zend/week/date-timezone.txt

That is on the list.

2. late static binding (keyword "this"?)
   When using static classes and inheritance, you can't use parent
   methodes/members today

Too big for PHP 5.2 IMHO

But perhaps that's something for 6.0...

Another idea for a future PHP version:

pecl_http extension implements some really useful features:
http://dev.iworks.at/ext-http/http-functions.html.gz

Perhaps some day, when it's ready... it could implement the 5
functions from ext/http too, and replace that extension without any
BC-issues...

I'd prefer to wait with addition of new extensions until PHP 6,
unless there is a majority consensus that we absolutely must have
this extension in PHP core.

Ilia Alshanetsky
Advanced Internet Designs Inc.
ilia@prohost.org

Hello Evert,

Wednesday, May 3, 2006, 12:09:17 AM, you wrote:

Hi People,

I'm not sure this is the right place to make a feature request, but here
goes..

I noticed some upgrades/ideas in the streams system lately.. Is there
any chance at all this can be migrated to an OOP system?

Here's the kind of think i would really like to see (java does it the
same way, more or less)

2 base stream interfaces
Writer
Reader

Which are implemented by:
FileWriter
FileReader
SocketWriter
SocketReader
StringWriter
StringReader

The Java IO library uses the decorator pattern to add functionality to
those base classes:

BufferedReader
BufferedWriter
HTMLFilterWriter

Since we are getting a new filter system, this could also be based on
this stream system....

This would allow be to write new base-classes for transports and make
use of all the existing filter-classes.
Also, this could be unified with XMLReader and XMLWriter and the SPL
file classes.

XMLReader/XMLWriter have nothing to do with our streams implementation
though they can leverage them. In fact they follow libxml2's api which
is inspired by C#'s xmlTextReader. Adding functions to that doesn't make
sense at all they are just wrappers that make the libraries api available
to PHP. SPL could be the start of such a thing but right now in no way is
limited to streams stuff. Again it can leverage streams of course and
that at any level.

This implementation is just a suggestion (and I really like the
flexibility of the Java IO system).. I'm just really missing a proper
unified stream system..

Flexibility of the cost that it takes a decend programmer years to
understand what plays together in what sense...definitively the
opposit of php's kiss approach.

Great work has already been done to centralize systems because of the
introduction of the Traversable interface and its descendants.. but more
and more often I find myself rewriting PHP extensions in PHP, because
there's no unified (abstracted) API..

Traversable is a tag necessary to the engine and does not define any API.
The corresponding API is being defined by the two interfaces Iterator and
IteratorAggregate. None of those has anything to do with reading streams.
All that occurs is that SPL gives you a class (SplFileObject) that
simplifies reading files line by line wchih is based on Iterator, giving
it a semantical meaning.

I'm already pretty far in implementing this in PHP, and I would be more
than happy to PEAR it (if people are interested).. but I feel like a
system like this belongs at the core to prevent every new subsystem from
figuring out a new API...

If you go with such classes be sure to follow established naming conventions
and do not name them simply 'BufferedReader' or even worse 'Reader'.

I hope I made my point, I'll be more than happy to eloborate or help
writing specs for this system, my C skills are mediocre though..

Streams stuff belongs here. You don't want to wait forever when reading
giles do you? However having a pear like, working set of classes interfaces
would be a nice starting point. So your work would be of help of course.

Oh, and thanks for your great work.. PHP is the reason I can pay my rent
and I know there's a lot of people like me =)

Evert

Ilia Alshanetsky wrote:

Heh, Lukas preempted by e-mail a bit, but the bottom line is that the
next release in the 5.X series is going to be 5.2.0. Being a minor
version release we have a greater amount of freedom then the one we
normally get for patch level releases and that's exactly what we need
for some of the changed being planned. Basically for the next week, I
would like to assemble a list of changes (using Lukas' wiki) that we
wish to integrate into this release and then make a new branch. Once
that is the final list will be published and we will start on a 3
month release cycle, where the 1st month is allotted towards making
the big changes and the remaining 2 months to get things stable. So,
if you have changes you'd like to see in 5.2 (don't go too wild now
;-) ), reply to this e-mail.

Hi,

I updated my phptodo wiki for the next planned release. Ilia also
send me a bunch of items that I threw on there:
http://oss.backendmedia.com/PhP52

If you want me to be your personal secretary let me know what items
you are missing from the list, what items should be assigned to
specific people and finally what items are completed.

regards,
Lukas

--

Ilia Alshanetsky
Advanced Internet Designs Inc.
ilia@prohost.org

--

Best regards,
Marcus

On Tue, 2 May 2006 22:21:14 +0200
pierre.php@gmail.com (Pierre) wrote:

On Tue, 02 May 2006 10:22:14 -0700
andi@zend.com (Andi Gutmans) wrote:

Any reason why sqlite (pdo & ext/) can't be compiled without the
bundled sqlite.

While testing, I also confirm that ext/sqlite with --with-sqlite=/usr
is also broken. For some unknown reason, it tries to get files and
definitions from ext/sqlite/libsqlite/src/.

--
Pierre

Did I help you? Please donate
http://blog.thepimp.net/index.php/1998/04/12/57-please-donate