Aloha,
Since Johannes has been stumped (and therefore not as visible as he
would have hoped) with work and 5.3 CVS is already filled brim with
awesome new features, I have been approached by several people
wondering how we can speed up the process. I have always said I am
available to play the secretary to the RM, but in order to ensure that
developers have a greater chance of having an RM to talk to, Johannes
agreed to move me to co-RM status.
I hope we do not have to have a fundamental discussion about the
merits of 2 RMs. Having 2 RMs should hopefully help speed up the 5.3
release cycle. Of course it will be the job of the two RMs to ensure
that we are sufficiently in sync with each other. But I guess we are
hopeful that adding an RM is not made unfeasible by this additional
communication between the RMs.
Anyways, I have updated the 5.3 todo page [1] with all the todo items
I have seen flying over the list and IRC. Other people have also added
their todo items after my recent request [2]. The purpose of the todo
list in the current stage is to show what people are working on and
are hoping to get into 5.3. It is now the job of the RMs to figure out
if indeed we can align all of these features towards a sensible date
for 5.3. Also we need to figure out if the items are still of
relevance and if the names behind the items are valid and when the
relevant developers expect to be able to finish.
Given all of this we see several items on the list as the key features
of this release:
-
namespaces
Here we need to make sure that the current state is now in a coherent
state. I think Derick still has some issues [3] with the recent change
by Greg [4], but even his criticism did not sound all to loud. So I
think we are in a good state here? -
late static binding
Etienne had some questions recently [5], which were met by criticism
by Stas [6]. However all others agreed with the change. So I guess we
are solid here too? -
re2c
Rui recently came to the list with notes on the ZE MB feature [7].
@Scott/Marcus: Is this enough for you guys to get this working?
@Rui: Is there any chance you can get more people in the japanese (or
asian in general) community involved here?
- windows support
Ever since Edin disappeared it has become clear that we have a bus
factor issue with windows support. The windows team is working to
rectify this situation. We need to make sure that the infrastructure
to deliver windows binaries for PHP 5.3 as well as PECL extension is
in place before we can release 5.3.
@Elizabeth/Pierre/Rob: How are things on this front?
- BC issues
Well this is a bit of an "anti-feature" in the sense its not a task
anyone is dedicated to. The point is that we need to make sure that we
understand any BC issues we currently have, so that we can either
correct them or document them.
@Philipp: Since you are the god of documentation .. How are things
looking on the scratchpad [8] you started?
These are the 5 areas we the RMs would hope that people focus on.
Thats actually 3 focus areas too many for my taste, but goes to show
that we might want to release more often (given that the list for 5.4
is already cramming up [9]).
On top of this we also have a few other changes that are of quite some
importance, but that to me will not stop a release if they do not make
it (for the extensions we feel that they will be available via PECL
for those who really need them now in the worst case). But these are
big features non the less that could warrant a new minor release on
their own alone if it would be for even bigger stuff:
-
intl extension
Last discussion ended without a decision on the class naming [10]. I
specifically remember Derick taking issue with intl ext "invading" the
date ext namespace. Stas however arguing that the intl ext is supposed
to bring some forwards compatibility to PHP 6 and therefore naturally
will need to span the namespaces of other extensions, that are planned
to be expanded for PHP 6. -
phar extension
I guess we are pretty solid here? -
E_DEPRECATED
Here we just need to make sure that we actually mark only the things
as deprecated that we actually want to deprecate [11]. This ties in a
bit with the BC issues point above. -
__callStatic
-
Garbage Collection
So is anything missing? Please everybody take time to review the todo
list, make sure that all items are on the list, make sure that the
information is as up to date as possible. Finally anyone who's name is
on this list (or who will add himself) should get in contact with
Johannes and myself within 1 week (thats July 9th) to explain the
state of the todo item and when he can finish the item and what the
general impact the feature has on the release. Also please bring up
any issues, especially for the above 6 points, to the list and try to
focus on solving the issues in a timely manner. We RMs will try to
moderate as much as possible, but understand that at some point we
will have to have to go with one approach (or in the worst case we
might have to push a feature to 5.4).
After July 9th, we will then publish a tentative release plan within 3
days afterwards. Again ideally people will be available for short
feedback loops during this period. If you are unable to follow
internals@ during this period, please make sure we have some way to
contact you (email, IM, phone whatever). If you are not available
please also just let us know. Its not about forcing developers to call
the RMs if they want to go out to the movies. It just makes our work a
bit easier, but in the end its about finding the right balance in
timing, features and stability, so as this is PHP so common sense
always rules any dates (or the nerves of the RMs).
The tentative schedule will probably try to move us quickly towards a
feature freeze together with a first alpha. Depending on our
discoveries we will schedule beta and RC releases (obviously subject
to continued review).
Summary:
Everybody review [1] and make sure all items you care about are on the
list and your name only appears next to stuff you are actually able to
complete in a timely manner.
regards,
Lukas and Johannes
[1] http://wiki.php.net/todo/php53
[2] http://marc.info/?l=php-internals&m=121438504121772&w=2
[3] http://marc.info/?l=php-internals&m=121446594113602&w=2
[4] http://marc.info/?l=php-internals&m=121397701404954&w=2
[5] http://marc.info/?l=php-internals&m=121397858807587&w=2
[6] http://marc.info/?l=php-internals&m=121400956517854&w=2
[7] http://marc.info/?l=php-internals&m=121474666513126&w=2
[8] http://wiki.php.net/doc/scratchpad
[9] http://wiki.php.net/todo/php53#future_php_releases
[10] http://marc.info/?l=php-internals&m=120719875404217&w=2
[11] http://marc.info/?l=php-internals&m=121390431523970&w=2
I think the sooner we set on 5.3 release path, the better of we will
be. As a past RM I can tell you that the more new features exist in a
release, the more challenging the release process is. If a faster
release cycle means having 2 RMs, then we have 2 RMs, thats my opinion
anyhow.
Aloha,
Since Johannes has been stumped (and therefore not as visible as he
would have hoped) with work and 5.3 CVS is already filled brim with
awesome new features, I have been approached by several people
wondering how we can speed up the process. I have always said I am
available to play the secretary to the RM, but in order to ensure
that developers have a greater chance of having an RM to talk to,
Johannes agreed to move me to co-RM status.I hope we do not have to have a fundamental discussion about the
merits of 2 RMs. Having 2 RMs should hopefully help speed up the 5.3
release cycle. Of course it will be the job of the two RMs to ensure
that we are sufficiently in sync with each other. But I guess we are
hopeful that adding an RM is not made unfeasible by this additional
communication between the RMs.
Ilia Alshanetsky
@Philipp: Since you are the god of documentation .. How are things looking
on the scratchpad [8] you started?
Philip, one p, recently moved to Nicaragua (last weekend actually) and
isn't really "available" these days :)
Furthermore I haven't seen Nuno for a while and "you guys" stole
Felipe from "us" and I recently found out that school is heckofalot
easier than work :]
So... any and all help in the documentation area would be appreciated.
The scratchpad wiki page is a good start, but I doubt these are the
"only" changes/new features in 5.3...
Of the top of my head; a list of error changes (especially
functions/features now throwing E_DEPRECATED) is missing...
-Hannes
@Philipp: Since you are the god of documentation .. How are things looking
on the scratchpad [8] you started?Philip, one p, recently moved to Nicaragua (last weekend actually) and
isn't really "available" these days :)
Nice :-)
Furthermore I haven't seen Nuno for a while and "you guys" stole
Felipe from "us" and I recently found out that school is heckofalot
easier than work :]So... any and all help in the documentation area would be appreciated.
The scratchpad wiki page is a good start, but I doubt these are the
"only" changes/new features in 5.3...
Of the top of my head; a list of error changes (especially
functions/features now throwing E_DEPRECATED) is missing...
Also the changes to zend_parse_prameters() should be checked for tiny
changes (like the current()/next() changes already documented on that
wiki page)
Help from any lurker here is appreciated!
johannes
On Wed, Jul 2, 2008 at 22:00, Lukas Kahwe Smith
mls@pooteeweet.org wrote:@Philipp: Since you are the god of documentation .. How are things
looking
on the scratchpad [8] you started?Philip, one p, recently moved to Nicaragua (last weekend actually)
and
isn't really "available" these days :)Nice :-)
Indeed! :)
Furthermore I haven't seen Nuno for a while and "you guys" stole
Felipe from "us" and I recently found out that school is heckofalot
easier than work :]So... any and all help in the documentation area would be
appreciated.
The scratchpad wiki page is a good start, but I doubt these are the
"only" changes/new features in 5.3...
Of the top of my head; a list of error changes (especially
functions/features now throwing E_DEPRECATED) is missing...Also the changes to zend_parse_prameters() should be checked for tiny
changes (like thecurrent()/next() changes already documented on that
wiki page)Help from any lurker here is appreciated!
Essentially the plan is to DocBookify it once 5.3 nears release but
today that page requires additional content. Random people add content
randomly and unfortunately I'm no longer able to lead this effort so
please take over the task of 5.3 upgrade docs procurement. I'll move
it to DocBook if/when needed. In other words, to something similar to http://php.net/migration52
Wiki: http://wiki.php.net/doc/scratchpad/upgrade/53
As for integrating 5.3 goodness into the PHP manual itself, most
features are folded within. All are welcome to edit the CVS module
named phpdoc and today only a recent PHP release is required (no make/
xsltproc/etc.) Or write an email, post a simple text file, and/or edit
the wiki page. Also, thanks to all who use the [DOC] tag!
And lastly, ideas are welcome for dealing with the current style as
we'll end up having the following separate migration guides:
5.0 -> 5.1
5.1 -> 5.2
5.2 -> 5.3
Not a terrible problem but it's something to think about at phpdoc@lists.php.net
.
Regards,
Philip
Essentially the plan is to DocBookify it once 5.3 nears release but
today that page requires additional content. Random people add
content randomly and unfortunately I'm no longer able to lead this
effort so please take over the task of 5.3 upgrade docs procurement.
I'll move it to DocBook if/when needed. In other words, to something
similar to http://php.net/migration52
Just as an FYI. I am currently learning XSLT so that I can finish the
integration of reST [1] as an optional format for wiki pages. Since I
will use docbook as an intermediate step from reST to dokuwiki, I
should also be able to provide basic docbook support as an optional
format in the wiki. This might make it easier to build documents that
are intended to be integrated into the manual later on.
regards,
Lukas Kahwe Smith
mls@pooteeweet.org
Folks:
functions/features now throwing E_DEPRECATED) is missing...
I just added the E_DEPRECATED constant to errorfunc.constants.php. Now
we need to make sure that each function that error has been applied to
has it's manual page updated and gets added to
http://wiki.php.net/doc/scratchpad/upgrade/53.
--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
Summary:
Everybody review [1] and make sure all items you care about are on the list
and your name only appears next to stuff you are actually able to complete
in a timely manner.
..One more thing: My GSoC student, Rudy (CCed), is working on a man
page rendering format for the documentations (functions, methods and
class reference pages).. How do you guys feel about bundling those?
We already bundle the CHM for the windows downloads (actually quite
old one, someone needs to remind me to show Derick how to build the
new ones), it would be pretty sweet if we could bundle the man pages
for the source downloads.
The idea is to install them into a "non-standard location" and then
install a two-liners-shell script ("phpman") to display them..
-Hannes
Hello Hannes,
Wednesday, July 2, 2008, 10:41:10 PM, you wrote:
Summary:
Everybody review [1] and make sure all items you care about are on the list
and your name only appears next to stuff you are actually able to complete
in a timely manner.
..One more thing: My GSoC student, Rudy (CCed), is working on a man
page rendering format for the documentations (functions, methods and
class reference pages).. How do you guys feel about bundling those?
We already bundle the CHM for the windows downloads (actually quite
old one, someone needs to remind me to show Derick how to build the
new ones), it would be pretty sweet if we could bundle the man pages
for the source downloads.
The idea is to install them into a "non-standard location" and then
install a two-liners-shell script ("phpman") to display them..
This can be done pretty late in the release process. Probably even late
beta. Anyway you should try to be ready prior to beta testing.
Best regards,
Marcus
Hi,
Aloha,
Since Johannes has been stumped (and therefore not as visible as he would
have hoped) with work and 5.3 CVS is already filled brim with awesome new
features, I have been approached by several people wondering how we can
speed up the process. I have always said I am available to play the
secretary to the RM, but in order to ensure that developers have a greater
chance of having an RM to talk to, Johannes agreed to move me to co-RM
status.I hope we do not have to have a fundamental discussion about the merits of 2
RMs. Having 2 RMs should hopefully help speed up the 5.3 release cycle. Of
course it will be the job of the two RMs to ensure that we are sufficiently
in sync with each other. But I guess we are hopeful that adding an RM is not
made unfeasible by this additional communication between the RMs.Anyways, I have updated the 5.3 todo page [1] with all the todo items I have
seen flying over the list and IRC. Other people have also added their todo
items after my recent request [2]. The purpose of the todo list in the
current stage is to show what people are working on and are hoping to get
into 5.3. It is now the job of the RMs to figure out if indeed we can align
all of these features towards a sensible date for 5.3. Also we need to
figure out if the items are still of relevance and if the names behind the
items are valid and when the relevant developers expect to be able to
finish.Given all of this we see several items on the list as the key features of
this release:
- namespaces
Here we need to make sure that the current state is now in a coherent state.
I think Derick still has some issues [3] with the recent change by Greg [4],
but even his criticism did not sound all to loud. So I think we are in a
good state here?
I'd really like to see a decision on naming for internal namespaces
before the feature is out. So we can document it and not worry about
BC when we will actually use it.
- late static binding
Etienne had some questions recently [5], which were met by criticism by Stas
[6]. However all others agreed with the change. So I guess we are solid here
too?
Yes, the only thing remaining is a tad of love from somebody with ZE
karma to commit the patches.
- re2c
Rui recently came to the list with notes on the ZE MB feature [7].@Scott/Marcus: Is this enough for you guys to get this working?
@Rui: Is there any chance you can get more people in the japanese (or asian
in general) community involved here?
- windows support
Ever since Edin disappeared it has become clear that we have a bus factor
issue with windows support. The windows team is working to rectify this
situation. We need to make sure that the infrastructure to deliver windows
binaries for PHP 5.3 as well as PECL extension is in place before we can
release 5.3.@Elizabeth/Pierre/Rob: How are things on this front?
- BC issues
Well this is a bit of an "anti-feature" in the sense its not a task anyone
is dedicated to. The point is that we need to make sure that we understand
any BC issues we currently have, so that we can either correct them or
document them.@Philipp: Since you are the god of documentation .. How are things looking
on the scratchpad [8] you started?These are the 5 areas we the RMs would hope that people focus on. Thats
actually 3 focus areas too many for my taste, but goes to show that we might
want to release more often (given that the list for 5.4 is already cramming
up [9]).On top of this we also have a few other changes that are of quite some
importance, but that to me will not stop a release if they do not make it
(for the extensions we feel that they will be available via PECL for those
who really need them now in the worst case). But these are big features non
the less that could warrant a new minor release on their own alone if it
would be for even bigger stuff:
intl extension
Last discussion ended without a decision on the class naming [10]. I
specifically remember Derick taking issue with intl ext "invading" the date
ext namespace. Stas however arguing that the intl ext is supposed to bring
some forwards compatibility to PHP 6 and therefore naturally will need to
span the namespaces of other extensions, that are planned to be expanded for
PHP 6.phar extension
I guess we are pretty solid here?
E_DEPRECATED
Here we just need to make sure that we actually mark only the things as
deprecated that we actually want to deprecate [11]. This ties in a bit with
the BC issues point above.__callStatic
Garbage Collection
So is anything missing? Please everybody take time to review the todo list,
make sure that all items are on the list, make sure that the information is
as up to date as possible. Finally anyone who's name is on this list (or who
will add himself) should get in contact with Johannes and myself within 1
week (thats July 9th) to explain the state of the todo item and when he can
finish the item and what the general impact the feature has on the release.
Also please bring up any issues, especially for the above 6 points, to the
list and try to focus on solving the issues in a timely manner. We RMs will
try to moderate as much as possible, but understand that at some point we
will have to have to go with one approach (or in the worst case we might
have to push a feature to 5.4).After July 9th, we will then publish a tentative release plan within 3 days
afterwards. Again ideally people will be available for short feedback loops
during this period. If you are unable to follow internals@ during this
period, please make sure we have some way to contact you (email, IM, phone
whatever). If you are not available please also just let us know. Its not
about forcing developers to call the RMs if they want to go out to the
movies. It just makes our work a bit easier, but in the end its about
finding the right balance in timing, features and stability, so as this is
PHP so common sense always rules any dates (or the nerves of the RMs).The tentative schedule will probably try to move us quickly towards a
feature freeze together with a first alpha. Depending on our discoveries we
will schedule beta and RC releases (obviously subject to continued review).Summary:
Everybody review [1] and make sure all items you care about are on the list
and your name only appears next to stuff you are actually able to complete
in a timely manner.regards,
Lukas and Johannes[1] http://wiki.php.net/todo/php53
[2] http://marc.info/?l=php-internals&m=121438504121772&w=2
[3] http://marc.info/?l=php-internals&m=121446594113602&w=2
[4] http://marc.info/?l=php-internals&m=121397701404954&w=2
[5] http://marc.info/?l=php-internals&m=121397858807587&w=2
[6] http://marc.info/?l=php-internals&m=121400956517854&w=2
[7] http://marc.info/?l=php-internals&m=121474666513126&w=2
[8] http://wiki.php.net/doc/scratchpad
[9] http://wiki.php.net/todo/php53#future_php_releases
[10] http://marc.info/?l=php-internals&m=120719875404217&w=2
[11] http://marc.info/?l=php-internals&m=121390431523970&w=2--
--
Etienne Kneuss
http://www.colder.ch
Men never do evil so completely and cheerfully as
when they do it from a religious conviction.
-- Pascal
Etienne Kneuss wrote:
- late static binding
Etienne had some questions recently [5], which were met by criticism by Stas
[6]. However all others agreed with the change. So I guess we are solid here
too?Yes, the only thing remaining is a tad of love from somebody with ZE
karma to commit the patches.
Give me the patch and tests for it, I'll probably commit it after review.
Thanks. Dmitry.
Hi!
- intl extension
Last discussion ended without a decision on the class naming [10]. I
specifically remember Derick taking issue with intl ext "invading" the
date ext namespace. Stas however arguing that the intl ext is supposed
to bring some forwards compatibility to PHP 6 and therefore naturally
will need to span the namespaces of other extensions, that are planned
to be expanded for PHP 6.
That was fixed - I have renamed the date formatter class so it doesn't
infringe on date namespace anymore.
--
Stanislav Malyshev, Zend Software Architect
stas@zend.com http://www.zend.com/
(408)253-8829 MSN: stas@zend.com
Lukas Kahwe Smith wrote:
Aloha,
Since Johannes has been stumped (and therefore not as visible as he
would have hoped) with work and 5.3 CVS is already filled brim with
awesome new features, I have been approached by several people
wondering how we can speed up the process. I have always said I am
available to play the secretary to the RM, but in order to ensure that
developers have a greater chance of having an RM to talk to, Johannes
agreed to move me to co-RM status.
..snip..
- re2c
Rui recently came to the list with notes on the ZE MB feature [7].
This one's pretty critical. #!bang support breaking other code.
http://bugs.php.net/bug.php?id=45372
Looks like it would be usefull to have a 'release blocker' flag...?
Otherwise it seems reasonably stable here..
@Scott/Marcus: Is this enough for you guys to get this working?
@Rui: Is there any chance you can get more people in the japanese (or
asian in general) community involved here?
..snip..
Regards
Alan
Lukas Kahwe Smith wrote:
Aloha,
Since Johannes has been stumped (and therefore not as visible as he
would have hoped) with work and 5.3 CVS is already filled brim with
awesome new features, I have been approached by several people
wondering how we can speed up the process. I have always said I am
available to play the secretary to the RM, but in order to ensure
that developers have a greater chance of having an RM to talk to,
Johannes agreed to move me to co-RM status.
..snip..
- re2c
Rui recently came to the list with notes on the ZE MB feature [7].
This one's pretty critical. #!bang support breaking other code.
http://bugs.php.net/bug.php?id=45372Looks like it would be usefull to have a 'release blocker' flag...?
Otherwise it seems reasonably stable here..
I have added the bug to the todo list. I guess thats the best way to
track these "blocker" type bug tickets atm.
Also Alan, I am sure I have asked you already if you know anyone that
relies on the ZE MB support and if so if they can provide us with a
real world example of how they use this feature.
regards,
Lukas Kahwe Smith
mls@pooteeweet.org
Lukas Kahwe Smith wrote:
Since Johannes has been stumped (and therefore not as visible as he would
have hoped) with work and 5.3 CVS is already filled brim with awesome new
features, I have been approached by several people wondering how we can
speed up the process. I have always said I am available to play the
secretary to the RM, but in order to ensure that developers have a greater
chance of having an RM to talk to, Johannes agreed to move me to co-RM
status.
..snip..
- re2c
Rui recently came to the list with notes on the ZE MB feature [7].
This one's pretty critical. #!bang support breaking other code.
http://bugs.php.net/bug.php?id=45372Looks like it would be usefull to have a 'release blocker' flag...?
Otherwise it seems reasonably stable here..
I have added the bug to the todo list. I guess thats the best way to track
these "blocker" type bug tickets atm.
Actually, this is why we have "Critical".
regards,
Derick
--
Derick Rethans
http://derickrethans.nl | http://ezcomponents.org | http://xdebug.org
Lukas Kahwe Smith wrote:
- phar extension
I guess we are pretty solid here?
We'll need to review the phar before release. It definitely must be in
5.3, but it should be improved, and this improvements may require some
changes in ZE.
For now packed phpMyAdmin is 4 times slower than unpacked (with and
without opcode cache).
I'm going to assign next week to ext/phar.
Thanks. Dmitry.
Dmitry Stogov wrote:
Lukas Kahwe Smith wrote:
- phar extension
I guess we are pretty solid here?We'll need to review the phar before release. It definitely must be in
5.3, but it should be improved, and this improvements may require some
changes in ZE.For now packed phpMyAdmin is 4 times slower than unpacked (with and
without opcode cache).
Hi,
I am sure this is because non-code files are not cached, and so the
archive must be decompressed on each page load. If there was a way to
do a persistent temporary file, this could be avoided, and would make
compressed phars perform equal to uncompressed phars if coupled with
phar.cache_list
I'm going to assign next week to ext/phar.
Glad to hear :). I am (as a reminder) out of commission from a coding
perspective until August due to poor internet access and no time, just
as I have been for every summer.
Greg
Hello,
- re2c
Rui recently came to the list with notes on the ZE MB feature [7].@Scott/Marcus: Is this enough for you guys to get this working?
@Rui: Is there any chance you can get more people in the japanese (or
asian in general) community involved here?
I hope that we can have more people as testers.
I will disscuss this problem on japanese develoepers mailing list.
Derick already found a bug.
I will try to fix the bug soon.
I hope that PHP developpers in non-asian country also evaluate
the zend-multibyte because zend-multibute also support single-byte
encodings.
Rui
--
Rui Hirokawa <rui_hirokawa@ybb.ne.jp
Lukas Kahwe Smith wrote:
Aloha,
Since Johannes has been stumped (and therefore not as visible as he
would have hoped) with work and 5.3 CVS is already filled brim with
awesome new features, I have been approached by several people wondering
how we can speed up the process. I have always said I am available to
play the secretary to the RM, but in order to ensure that developers
have a greater chance of having an RM to talk to, Johannes agreed to
move me to co-RM status.
glad to hear it!
- namespaces
Here we need to make sure that the current state is now in a coherent
state. I think Derick still has some issues [3] with the recent change
by Greg [4], but even his criticism did not sound all to loud. So I
think we are in a good state here?
My recent changes aside, there are still some fubar issues with name
resolution, and there has been some offlist discussion of ways to fix
this that have not led to concrete onlist proposals yet.
For those who don't know what I'm talking about, the question is how to
resolve an unqualified classname inside a namespace. i.e. this code:
a.php:
<?php
namespace Foo;
throw new Exception('is this Foo::Exception or ::Exception?');
?>
Currently, the above code would throw ::Exception, because if a
namespaced class does not exist, internal classes are checked before
autoloading for performance reasons. However, if we execute this code
instead:
b.php:
<?php
namespace Foo;
class Exception {}
include 'a.php';
?>
then a.php would throw Foo::Exception. In other words, depending on
file inclusion order, classnames can change with current PHP accepted
practices. The solution to this is to use each namespaced class explicitly:
a2.php:
<?php
namespace Foo;
use Foo::Exception;
throw new Exception('this is Foo::Exception always');
?>
However, all it takes is one forgotten "use" statement, and a very
subtle bug could be introduced later.
Taking a step back, let's examine why autoload is not called before
checking internal classes - it is for performance reasons. However,
this performance enhancement causes unpredictable behavior by default
without explicit action.
There is a simple solution, however. If one changes the name resolution
to this pseudo-code:
- check Foo::Exception for existence
- if not found, try to autoload Foo::Exception
- if not found, check for ::Exception existence, userspace or
internal (addition of userspace check also fixes other problems raised
on-list) - if not found, fail.
This fixes the logic problem, and re-introduces the performance slowdown
for internal classes. FORTUNATELY there is a simple solution to this,
which is to "use" all global classes:
<?php
namespace Foo;
use ::ArrayIterator;
$a = new ArrayIterator(array(1,2,3));
?>
The above code works exactly the same as:
<?php
namespace Foo;
$a = new ArrayIterator(array(1,2,3));
?>
and short-circuits the name resolution to:
- check ::ArrayIterator for existence
- if not found, fail.
To summarize, we should scrap the "performance enhancement" that
introduces the potential for subtle and dangerous logic errors in name
resolution because it is still possible to achieve that performance
enhancement through one-time "use" of internal classnames.
With these changes, namespace classname resolution will be 100%
deterministic regardless of file load order, it will still be possible
to override internal classnames with userspace classes, and for the
ultra-performance hungry, it is still easy to achieve faster classname
resolution for internal classes. Win-win.
Greg
Hi!
This fixes the logic problem, and re-introduces the performance slowdown
for internal classes. FORTUNATELY there is a simple solution to this,
which is to "use" all global classes:
The thing is since it'd work without "use", most users would do it that
way and have horrible code. But if you can do use ::Exception, you can
the same way do use Foo::Exception, right? So what's the difference?
--
Stanislav Malyshev, Zend Software Architect
stas@zend.com http://www.zend.com/
(408)253-8829 MSN: stas@zend.com
Stanislav Malyshev wrote:
Hi!
This fixes the logic problem, and re-introduces the performance
slowdown for internal classes. FORTUNATELY there is a simple
solution to this, which is to "use" all global classes:The thing is since it'd work without "use", most users would do it
that way and have horrible code. But if you can do use ::Exception,
you can the same way do use Foo::Exception, right? So what's the
difference?
The difference is in what you quoted - name resolution is
non-deterministic with current implementation. The suggested change
always works the same way. It turns out my internet access is even
worse than I thought, so I may only be reading/replying once every week
to two weeks until August, please bear with me :/
In other words, with the current implementation, you can just do "use
Foo::Exception;" and it works, but if you forget to do the use
statement, you can get unpredictable behavior with no warning until your
code starts not working properly. With the suggested change of name
resolution, your code always works as you designed it, but if you forget
to "use ::Exception", then your code is simply slightly slower (1 extra
call to autoload if it exists), but still works properly. It also tilts
the "use" towards internal classnames, which in my experience tend to be
outnumbered by userspace classnames, so it will reduce code size, making
it more readable.
Greg
Stanislav Malyshev wrote:
Hi!
This fixes the logic problem, and re-introduces the performance
slowdown for internal classes. FORTUNATELY there is a simple
solution to this, which is to "use" all global classes:The thing is since it'd work without "use", most users would do it
that way and have horrible code. But if you can do use ::Exception,
you can the same way do use Foo::Exception, right? So what's the
difference?The difference is in what you quoted - name resolution is non-
deterministic with current implementation. The suggested change
always works the same way. It turns out my internet access is even
worse than I thought, so I may only be reading/replying once every
week to two weeks until August, please bear with me :/In other words, with the current implementation, you can just do
"use Foo::Exception;" and it works, but if you forget to do the
use statement, you can get unpredictable behavior with no warning
until your code starts not working properly. With the suggested
change of name resolution, your code always works as you designed
it, but if you forget to "use ::Exception", then your code is simply
slightly slower (1 extra call to autoload if it exists), but still
works properly. It also tilts the "use" towards internal
classnames, which in my experience tend to be outnumbered by
userspace classnames, so it will reduce code size, making it more
readable.
Greg's argument seems sound to me. With the proposed change errors are
less likely and more transparent in case they happen (for people using
autoload that is). At the same time people who care about performance
can still work around this behavior (then again those that care about
optimizations on this level probably do not use autload to begin with).
So I guess the point is .. autoload is there for convinience, so lets
make it as convinient as possible.
regards
Lukas Kahwe Smith
mls@pooteeweet.org
Hi!
Greg's argument seems sound to me. With the proposed change errors are
less likely and more transparent in case they happen (for people using
No, they won't be transparent at all. If you use Exception and forget to
put "use ::Exception" in each and every of your files, you get
exhaustive search of include path (not helped by bytecode caching, btw -
all bytecode caches I know cache existing files, not searches for
non-existing ones) on each mention of Exception. You can not see it - on
the surface, everything works fine. Then, when you think your code is
fine, you run profiler and boom - you see 200 file accesses where there
should be none.
autoload that is). At the same time people who care about performance
can still work around this behavior (then again those that care about
optimizations on this level probably do not use autload to begin with).
What's wrong with autoload? You sound like autoload is somehow contrary
to performance, which is not true.
So I guess the point is .. autoload is there for convinience, so lets
make it as convinient as possible.
I don't see how having internal class mention trigger exhaustive
autoload search is "as convenient as possible". For me, it is a huge
landmine under every PHP application trying to use namespaces - forget
one use statement and boom, your performance is gone. If you want to do
that, you better force using ::Class everywhere - this way at least
there's a way to know where it will blow up without running system call
traces on every piece of code.
Stanislav Malyshev, Zend Software Architect
stas@zend.com http://www.zend.com/
(408)253-8829 MSN: stas@zend.com
autoload that is). At the same time people who care about
performance can still work around this behavior (then again those
that care about optimizations on this level probably do not use
autload to begin with).What's wrong with autoload? You sound like autoload is somehow
contrary to performance, which is not true.
There is nothing wrong with autoload. However it adds overhead so if
you want super duper high performance, you use explicit includes/
requires with absolute paths instead.
regards,
Lukas Kahwe Smith
mls@pooteeweet.org
Hi!
There is nothing wrong with autoload. However it adds overhead so if you
want super duper high performance, you use explicit includes/requires
with absolute paths instead.
In most cases, it is not practical - code with autoload in 99.9% of
cases would be more robust, more maintainable and more readable - and in
some cases, more performing too - than code using explicit full-path
includes. So if we talking about regular people using PHP and caring for
performance, autoload is certainly something not to discount.
Stanislav Malyshev, Zend Software Architect
stas@zend.com http://www.zend.com/
(408)253-8829 MSN: stas@zend.com
Hello Lukas,
Thursday, July 17, 2008, 8:15:52 PM, you wrote:
autoload that is). At the same time people who care about
performance can still work around this behavior (then again those
that care about optimizations on this level probably do not use
autload to begin with).What's wrong with autoload? You sound like autoload is somehow
contrary to performance, which is not true.
There is nothing wrong with autoload. However it adds overhead so if
you want super duper high performance, you use
you use a different language. Unless you were refering to development time.
Then autoload is pretty damn good.
explicit includes/
requires with absolute paths instead.
regards,
Lukas Kahwe Smith
mls@pooteeweet.org
Best regards,
Marcus
Hi!
Greg's argument seems sound to me. With the proposed change errors
are less likely and more transparent in case they happen (for
people usingNo, they won't be transparent at all. If you use Exception and
forget to put "use ::Exception" in each and every of your files, you
get exhaustive search of include path (not helped by bytecode
caching, btw - all bytecode caches I know cache existing files, not
searches for non-existing ones) on each mention of Exception. You
can not see it - on the surface, everything works fine. Then, when
you think your code is fine, you run profiler and boom - you see 200
file accesses where there should be none.autoload that is). At the same time people who care about
performance can still work around this behavior (then again those
that care about optimizations on this level probably do not use
autload to begin with).What's wrong with autoload? You sound like autoload is somehow
contrary to performance, which is not true.So I guess the point is .. autoload is there for convinience, so
lets make it as convinient as possible.I don't see how having internal class mention trigger exhaustive
autoload search is "as convenient as possible". For me, it is a huge
landmine under every PHP application trying to use namespaces -
forget one use statement and boom, your performance is gone. If you
want to do that, you better force using ::Class everywhere - this
way at least there's a way to know where it will blow up without
running system call traces on every piece of code.
For this issue it seems like there is nobody that has enough "inertia"
to change the current status quo. As such it seems to me like we
should go to alpha1 as is. I hope that namespaces have enough buzz
that we quickly get feedback after alpha1. We should do as much
encouragement to get people to test namespaces as possible.
At the moment namespaces is probably the feature that makes me most
nervous. Followed by GC and the re2c change.
regards,
Lukas Kahwe Smith
mls@pooteeweet.org
Hi,
Please show me the patch before commit (the last patch I saw wasn't good
enough).
Thanks. Dmitry.
Lukas Kahwe Smith wrote:
Hi!
Greg's argument seems sound to me. With the proposed change errors
are less likely and more transparent in case they happen (for people
usingNo, they won't be transparent at all. If you use Exception and forget
to put "use ::Exception" in each and every of your files, you get
exhaustive search of include path (not helped by bytecode caching, btw
- all bytecode caches I know cache existing files, not searches for
non-existing ones) on each mention of Exception. You can not see it -
on the surface, everything works fine. Then, when you think your code
is fine, you run profiler and boom - you see 200 file accesses where
there should be none.autoload that is). At the same time people who care about performance
can still work around this behavior (then again those that care about
optimizations on this level probably do not use autload to begin with).What's wrong with autoload? You sound like autoload is somehow
contrary to performance, which is not true.So I guess the point is .. autoload is there for convinience, so lets
make it as convinient as possible.I don't see how having internal class mention trigger exhaustive
autoload search is "as convenient as possible". For me, it is a huge
landmine under every PHP application trying to use namespaces - forget
one use statement and boom, your performance is gone. If you want to
do that, you better force using ::Class everywhere - this way at least
there's a way to know where it will blow up without running system
call traces on every piece of code.For this issue it seems like there is nobody that has enough "inertia"
to change the current status quo. As such it seems to me like we should
go to alpha1 as is. I hope that namespaces have enough buzz that we
quickly get feedback after alpha1. We should do as much encouragement to
get people to test namespaces as possible.At the moment namespaces is probably the feature that makes me most
nervous. Followed by GC and the re2c change.regards,
Lukas Kahwe Smith
mls@pooteeweet.org
Please show me the patch before commit (the last patch I saw wasn't
good enough).
err which patch?
i just suggested to go with the status quo for namespaces in alpha1.
regards,
Lukas Kahwe Smith
mls@pooteeweet.org
Oh sorry, I answered to wrong email :)
I meant "parent::" forwarding patch.
We will try to finalize it with Etienne today.
Thanks. Dmitry.
Lukas Kahwe Smith wrote:
Please show me the patch before commit (the last patch I saw wasn't
good enough).err which patch?
i just suggested to go with the status quo for namespaces in alpha1.regards,
Lukas Kahwe Smith
mls@pooteeweet.org
Hi!
In other words, with the current implementation, you can just do "use
Foo::Exception;" and it works, but if you forget to do the use
statement, you can get unpredictable behavior with no warning until your
You get previctable behavior in all cases, there's no randomness in the
engine.
to "use ::Exception", then your code is simply slightly slower (1 extra
call to autoload if it exists), but still works properly. It also tilts
It's not slightly slower, it's A LOT slower - exhaustive search of
whole include path for EACH call mentioning internal class. That means
you have to declare EACH internal class - even if no clashes ever
existed - for EACH use. Basically, it's the same as always using
::Class only implemented in a way that its disastrous effects are hidden
until you check performance of your code. Then you have to go back and
add use statement for each internal class in each of your files. Lot's
of fun that would be.
Stanislav Malyshev, Zend Software Architect
stas@zend.com http://www.zend.com/
(408)253-8829 MSN: stas@zend.com
Hi!
In other words, with the current implementation, you can just do
"use Foo::Exception;" and it works, but if you forget to do the
use statement, you can get unpredictable behavior with no warning
until yourYou get previctable behavior in all cases, there's no randomness in
the engine.
Of course its predictable. What Greg meant is "error prone". The
difference is if we want to by default lower the chance of programming
mistakes or ensure maximum performance with little effort for users
with autoload (and long include path lists).
regards,
Lukas Kahwe Smith
mls@pooteeweet.org
Hi!
Of course its predictable. What Greg meant is "error prone". The
difference is if we want to by default lower the chance of programming
mistakes or ensure maximum performance with little effort for users with
autoload (and long include path lists).
I think silent performance disaster is much worse than error message
which makes it obvious what the mistake was.
--
Stanislav Malyshev, Zend Software Architect
stas@zend.com http://www.zend.com/
(408)253-8829 MSN: stas@zend.com
Stanislav Malyshev escreveu:
Hi!
Of course its predictable. What Greg meant is "error prone". The
difference is if we want to by default lower the chance of programming
mistakes or ensure maximum performance with little effort for users
with autoload (and long include path lists).I think silent performance disaster is much worse than error message
which makes it obvious what the mistake was.
I agree with Stanislav. In fact, average PHP user will read the error
message and change the code to make it work, but will have no clue the
performance of his script is hindered by some massive obscure autoload
look-up and might get the wrong idea that "PHP is slow" if he doesn't
profile his code correctly.
Just my 2 cents.
--
Rodrigo Saboya
Stanislav Malyshev wrote:
Hi!
Of course its predictable. What Greg meant is "error prone". The
difference is if we want to by default lower the chance of programming
mistakes or ensure maximum performance with little effort for users
with autoload (and long include path lists).I think silent performance disaster is much worse than error message
which makes it obvious what the mistake was.
Me too. This is the problem I am referring to:
a.php:
<?php
namespace Foo;
class Exception {}
?>
b.php:
<?php
namespace Foo;
class A {
function __construct() {throw new Exception('hi');}
}
?>
c.php:
<?php
function autoload($a)
{
include 'a.php'; // bogus, but you get the point
}
include 'b.php';
try {
$a = new Foo::A;
} catch (Foo::Exception $e) {
echo "caught\n";
}
?>
The above code will throw an ::Exception, not a Foo::Exception. With
the proposed change, it works as advertised. This code:
<?php
include 'a.php';
include 'b.php';
try {
$a = new A;
} catch (Foo::Exception $e) {
echo "caught\n";
}
?>
throws a Foo::Exception and echoes "caught", demonstrating the
importance of load order as well.
This is far from an obvious error message, it is a silent logic error
that is far more serious than a silent performance problem.
Stas, your response is quite frustrating to this problem and fits a
pattern. It seems the default response is always "no" or "that's not a
real problem" and is almost always condescending. It makes it extremely
difficult to have an intelligent debate with you. If you don't think
something is a real problem, perhaps a better default response is "why
does this person think it is an issue and I don't?" The impression your
response gives is that your first thought is instead "why is XXX such an
idiot who must waste my time?" I know you well enough to know that this
is not what you're thinking, but it would save a lot of time if we can
skip the "what the hell" stage and move right to "let's verify this and
fix it" or "more evidence needed, I see your point but what about XX?"
Thanks,
Greg
Hi!
b.php:
<?php
namespace Foo;
class A {
function __construct() {throw new Exception('hi');}
Here in your proposal exhaustive autoload happens for all cases where
you do not actually override Exception in Foo.
<?php
include 'a.php';
include 'b.php';
try {
$a = new A;
} catch (Foo::Exception $e) {
echo "caught\n";
}
?>throws a Foo::Exception and echoes "caught", demonstrating the
importance of load order as well.
You could do use Foo::Exception in b.php too, to solve it.
Stas, your response is quite frustrating to this problem and fits a
pattern. It seems the default response is always "no" or "that's not a
real problem" and is almost always condescending. It makes it extremely
No, there's no "default response". Just in this case it happens that
your proposal introduces significant problem - performance hit on some
innocent construct without any indication of it happening. And the
solution for it that you propose is not better than the original state
of affairs - doing "use" solves both cases, and if not doing "use" then
your case has more problems. It has nothing to do with me or you - it
has to do with how things work in the engine.
difficult to have an intelligent debate with you. If you don't think
something is a real problem, perhaps a better default response is "why
I think it is a problem, however I do not think this solution is going
to make things better. I am sorry if it looked like condescending to
you, it was not my intent. However, the conclusion still stays - I think
as proposed, this solution introduces more problems than solves. I would
be happy to find a solution that is better - and I am looking for one -
but right not it isn't good enough.
Stanislav Malyshev, Zend Software Architect
stas@zend.com http://www.zend.com/
(408)253-8829 MSN: stas@zend.com
Hello All,
There is no way around it given the feedback I am seeing about
namespace usage in the wild, to warm up this old post again.
This post and the additional commentary, especially about performance
by Stas can be found in the archives at:
http://marc.info/?l=php-internals&m=121527668606247
I think given the feedback from users, we really need to actually
benchmark the performance slow down that Greg's proposed changes will
bring. I also guess there are two types of users out there:
- those that tend to always spice up their API's by wrapping pretty
much all internal functionality (be if that the internal functionality
has a procedural or an OO API). These are also the people that will
have the more complex OO structures (deep inheritance). They also seem
like the most heavy users of namespaces - those that keep their structures flat, use native API's directly
and live in a mixed world of OO and procedural code
So while we are assessing the impact its important to keep in mind
which user type is going to be affected in what way. Furthermore I
hope that some of the people that have build up a code base that uses
namespaces will do this benchmarking, because otherwise we will hardly
get any useful data. Even then of course the benchmarks must be taken
with a grain of salt (as always).
I am including the email from Greg at the bottom here, along with a
reply from Stas (again read the archive to get the full story). Maybe
if we think hard about this one (now that we know that its an
important real world need), we can discover a solution that we did not
see at first.
- namespaces
Here we need to make sure that the current state is now in a
coherent state. I think Derick still has some issues [3] with the
recent change by Greg [4], but even his criticism did not sound all
to loud. So I think we are in a good state here?My recent changes aside, there are still some fubar issues with name
resolution, and there has been some offlist discussion of ways to
fix this that have not led to concrete onlist proposals yet.For those who don't know what I'm talking about, the question is how
to resolve an unqualified classname inside a namespace. i.e. this
code:a.php:
<?php
namespace Foo;
throw new Exception('is this Foo::Exception or ::Exception?');
?>Currently, the above code would throw ::Exception, because if a
namespaced class does not exist, internal classes are checked before
autoloading for performance reasons. However, if we execute this
code instead:b.php:
<?php
namespace Foo;
class Exception {}
include 'a.php';
?>then a.php would throw Foo::Exception. In other words, depending on
file inclusion order, classnames can change with current PHP
accepted practices. The solution to this is to use each namespaced
class explicitly:a2.php:
<?php
namespace Foo;
use Foo::Exception;
throw new Exception('this is Foo::Exception always');
?>However, all it takes is one forgotten "use" statement, and a very
subtle bug could be introduced later.Taking a step back, let's examine why autoload is not called before
checking internal classes - it is for performance reasons. However,
this performance enhancement causes unpredictable behavior by
default without explicit action.There is a simple solution, however. If one changes the name
resolution to this pseudo-code:
- check Foo::Exception for existence
- if not found, try to autoload Foo::Exception
- if not found, check for ::Exception existence, userspace or
internal (addition of userspace check also fixes other problems
raised on-list)- if not found, fail.
This fixes the logic problem, and re-introduces the performance
slowdown for internal classes. FORTUNATELY there is a simple
solution to this, which is to "use" all global classes:<?php
namespace Foo;
use ::ArrayIterator;
$a = new ArrayIterator(array(1,2,3));
?>The above code works exactly the same as:
<?php
namespace Foo;
$a = new ArrayIterator(array(1,2,3));
?>and short-circuits the name resolution to:
- check ::ArrayIterator for existence
- if not found, fail.
To summarize, we should scrap the "performance enhancement" that
introduces the potential for subtle and dangerous logic errors in
name resolution because it is still possible to achieve that
performance enhancement through one-time "use" of internal classnames.With these changes, namespace classname resolution will be 100%
deterministic regardless of file load order, it will still be
possible to override internal classnames with userspace classes, and
for the ultra-performance hungry, it is still easy to achieve faster
classname resolution for internal classes. Win-win.
In other words, with the current implementation, you can just do
"use Foo::Exception;" and it works, but if you forget to do the
use statement, you can get unpredictable behavior with no warning
until yourYou get previctable behavior in all cases, there's no randomness in
the engine.to "use ::Exception", then your code is simply slightly slower (1
extra call to autoload if it exists), but still works properly. It
also tiltsIt's not slightly slower, it's A LOT slower - exhaustive search of
whole include path for EACH call mentioning internal class. That
means you have to declare EACH internal class - even if no clashes
ever existed - for EACH use. Basically, it's the same as always
using ::Class only implemented in a way that its disastrous effects
are hidden until you check performance of your code. Then you have
to go back and add use statement for each internal class in each of
your files. Lot's of fun that would be.
regards,
Lukas Kahwe Smith
mls@pooteeweet.org
Hi!
I think given the feedback from users, we really need to actually
benchmark the performance slow down that Greg's proposed changes will
bring. I also guess there are two types of users out there:
Could you summarize the feedback?
The slowdown is obvious - exhaustive autoloading search for each access
to internal class. However, I'm not sure what benchmark you are seeking.
I could produce benchmark that would provide you almost any slowdown
number by manipulation include path length (longer include path is,
bigger slowdown), class access pattern (more internal classes used, more
slowdown) and application structure (less code, more relative slowdown
from slowing the class resolution). What is the goal here - i.e., do you
doubt that exhaustive autoloading search each time you use Exception in
your code inside namespace would produce a slowdown?
Stanislav Malyshev, Zend Software Architect
stas@zend.com http://www.zend.com/
(408)253-8829 MSN: stas@zend.com
Hi!
I think given the feedback from users, we really need to actually
benchmark the performance slow down that Greg's proposed changes
will bring. I also guess there are two types of users out there:Could you summarize the feedback?
I am mainly baseing myself on the feedback I got at:
http://pooteeweet.org/blog/1288
However I also got some feedback from others on IRC that all went in
the same direction.
I think Liz summarized the gripes best (especially the second
paragraph is important to note):
"I've been using namespaces since then went into 5.3. From my
experience functions in namespaces are basically unusable (you can't
alias in a function like you can a class from a namespace - plus
there's the ambiguity issue with static methods).
Writing HUGE blocks of use statements at the top is going to turn
people off and since included files have their own namespace level you
can't even have a file that keeps a block of use statements that are
needed on every page.
Since I do more than just web applications with PHP, I HAVE run into
the need to get away from the "one namespace per file" rule, and the
fact that you can't have ANYTHING before the opening <?php tag in a
file with a namespace (no whitespace, no html, nothing) without a
fatal error annoys me to no end."
Chuck adds:
"I think that user-level classes are far more common in PHP than
internal classes, and as such should be given priority."
regards,
Lukas Kahwe Smith
mls@pooteeweet.org
Hi!
I am mainly baseing myself on the feedback I got at:
http://pooteeweet.org/blog/1288
OK, will read through it.
I think Liz summarized the gripes best (especially the second paragraph
is important to note):
"I've been using namespaces since then went into 5.3. From my experience
functions in namespaces are basically unusable (you can't alias in a
function like you can a class from a namespace - plus there's the
ambiguity issue with static methods).
Ambiguity seems to be unavoidable, unfortunately - that's why initial
version didn't have functions. But I'm not sure about "alias in" comment
- what exactly is meant here? Did you understand it?
--
Stanislav Malyshev, Zend Software Architect
stas@zend.com http://www.zend.com/
(408)253-8829 MSN: stas@zend.com
Stanislav Malyshev wrote:
Hi!
I am mainly baseing myself on the feedback I got at:
http://pooteeweet.org/blog/1288OK, will read through it.
I think Liz summarized the gripes best (especially the second
paragraph is important to note):
"I've been using namespaces since then went into 5.3. From my
experience functions in namespaces are basically unusable (you can't
alias in a function like you can a class from a namespace - plus
there's the ambiguity issue with static methods).Ambiguity seems to be unavoidable, unfortunately - that's why initial
version didn't have functions. But I'm not sure about "alias in" comment
- what exactly is meant here? Did you understand it?
If you have
<?php
namespace Foo::Bar;
class MyClass {}
?>
you can have it "feel" like it's in the current namespace
<?php
use Foo::Bar::MyClass as MyClass;
new MyClass;
?>
You have a function
<?php
namespace Foo::Bar;
function myfunction() {}
?>
<?php
use Foo::Bar::myfunction as myfunction;
myfunction();
?>
This doesn't work at all
The closest you can do is
<?php
use Foo::Bar as F;
F::myfunction;
?>
which kind of defeats the purpose of having functions in namespaces at
all, why not just use a class with static methods at this point.
Thanks,
Elizabeth
Hi!
This doesn't work at all
The closest you can do is
<?php
use Foo::Bar as F;
F::myfunction;
?>
That's the right way to go. If you want functions in global space, put
them there. If not, then use namespace syntax. BTW, what is so bad in
F::myfunction that it makes it absolutely useless?
which kind of defeats the purpose of having functions in namespaces at
all, why not just use a class with static methods at this point.
I didn't see a lot of use of having functions in namespaces from the
start, but if you could explain what your point is - i.e. why do you
want functions that are declared in namespaces and still are in the
global space - I could maybe understand the concern better.
Stanislav Malyshev, Zend Software Architect
stas@zend.com http://www.zend.com/
(408)253-8829 MSN: stas@zend.com
Stanislav Malyshev schreef:
Hi!
This doesn't work at all
The closest you can do is
<?php
use Foo::Bar as F;
F::myfunction;
?>That's the right way to go. If you want functions in global space, put
them there. If not, then use namespace syntax. BTW, what is so bad in
F::myfunction that it makes it absolutely useless?
because it reads like a fucking static method call, truly not an absolute reason,
but none the less totally not KISS.
which kind of defeats the purpose of having functions in namespaces at
all, why not just use a class with static methods at this point.I didn't see a lot of use of having functions in namespaces from the
start, but if you could explain what your point is - i.e. why do you
want functions that are declared in namespaces and still are in the
global space - I could maybe understand the concern better.
for the same reason you would want it with classes?? because you can
do it with classes, no? and that seems acceptable to you, no? then functions
should have the same privilege.
Hi!
for the same reason you would want it with classes?? because you can
do it with classes, no? and that seems acceptable to you, no? then
functions
should have the same privilege.
Functions and classes are rather different things. Class represents, as
you know, group of data and behavior, function is much smaller. You have
maybe two dozens of built-in classes in PHP that reside in global space,
and many of them (like SPL) can be moved out relatively easily to own
namespaces. You have hundreds, if not thousands, of internal functions,
most of them can't be moved anywhere. So having functions imported into
global space is much less useful and much more dangerous than the same
for classes.
It is also much less useful from one more perspective - when you import
a class, you get a bunch of functions which represent functionality
unit. With single function you probably get only a small piece, so if
you use a library you probably have dozens of functions there. If you
think importing all of them into global space through "use" is a good
idea, I think you need to do some refactoring there. It would grow to be
unmaintainable rather fast. I'd recommend putting them into a namespace
(if for some reason you have classes) and then just use Utility::func()
- it's really not that bad.
--
Stanislav Malyshev, Zend Software Architect
stas@zend.com http://www.zend.com/
(408)253-8829 MSN: stas@zend.com
Stanislav Malyshev schreef:
Hi!
for the same reason you would want it with classes?? because you can
do it with classes, no? and that seems acceptable to you, no? then
functions
should have the same privilege.Functions and classes are rather different things. Class represents, as
you know, group of data and behavior, function is much smaller. You have
maybe two dozens of built-in classes in PHP that reside in global space,
and many of them (like SPL) can be moved out relatively easily to own
namespaces. You have hundreds, if not thousands, of internal functions,
most of them can't be moved anywhere. So having functions imported into
global space is much less useful and much more dangerous than the same
for classes.
guns are dangerous yet they are sold by the bucket load. either don't
sell guns or let people decide how to use them, don't sell'em then dictate
that they can't pull the trigger.
It is also much less useful from one more perspective - when you import
a class, you get a bunch of functions which represent functionality
unit. With single function you probably get only a small piece, so if
you use a library you probably have dozens of functions there. If you
think importing all of them into global space through "use" is a good
idea, I think you need to do some refactoring there.
I won't be using namespaces in 'real life' code at all. I've never
encountered a symbol clash on a class, function or constant in my code
and the day I do I'll rename, search and replace to fix it ... as it
stands namespaces offer me nothing but obtuse abstraction, increased code
brittleness and general stress ... I can do without that lot, which is a
pity because conceptually namespaces are a good idea, I'd love to
be able to reduce my symbol pollution in the global scope and logically
'package' various functionality inside some a defined space.
It would grow to be
unmaintainable rather fast. I'd recommend putting them into a namespace
(if for some reason you have classes) and then just use Utility::func()
I'm sorry is that a function in namespace Utility or a static method of
class Utility?
- it's really not that bad.
no it really is that bad, namespaces as they stand have merely moved the
goalposts of symbol clashing somewhat whilst at the same time making
code less understandable when reading/auditing [php] source code
(e.g. load order dictating what exactly will be instantiated, the function-or-static-method
WTF).
I understand your concerns about performance, of course namespaces need
to be performant in order to be truly usable in production BUT clear, usable
functioning needs to take priority before performance is considered ...
otherwise your putting the horse before the cart so to speak. Elizabeth and
Greg have both stipulated the issues clearly - they need to be tackled or
you will end up with something that is going to make the language less usable
and not more so.
as it stands now prefixing class names with a project specific string and
using abstract classes to fake namespacing of functions is still a more
usable way to go than implementing namespaced code. I don't supposed that's
the intention?
[some comments below]
Lukas Kahwe Smith wrote:
Hi!
I think given the feedback from users, we really need to actually
benchmark the performance slow down that Greg's proposed changes will
bring. I also guess there are two types of users out there:Could you summarize the feedback?
I am mainly baseing myself on the feedback I got at:
http://pooteeweet.org/blog/1288However I also got some feedback from others on IRC that all went in the
same direction.I think Liz summarized the gripes best (especially the second paragraph
is important to note):
"I've been using namespaces since then went into 5.3. From my experience
functions in namespaces are basically unusable (you can't alias in a
function like you can a class from a namespace - plus there's the
ambiguity issue with static methods).
Constants in namespaces have exactly the same problems, but I do find
them useful. In case we remove functions we probably need to remove
constants too.
Also OO is not the single paradigm and PHP is not a pure OO language, so
I don't see a reason to restrict programmers to use only OO libraries.
Writing HUGE blocks of use statements at the top is going to turn people
off and since included files have their own namespace level you can't
even have a file that keeps a block of use statements that are needed on
every page.
"Use" statement has effect only on current file and it is done by
design. Imagine that you include several files and each of them have
several "use" statements. How are you going to identify and resolve
possible conflicts? Also the change of "use" statement in one of include
file may completely change the behavior in another. It is the thing
which we liked to avoid during design.
The main PHP namespaces ideas come from Java packages and Java classes
have to write these "use" statements in the same way. It's not the end
of the world. I believe that well-designed frameworks won't require a
lot of use statements in user-space code.
Since I do more than just web applications with PHP, I HAVE run into the
need to get away from the "one namespace per file" rule, and the fact
that you can't have ANYTHING before the opening <?php tag in a file with
a namespace (no whitespace, no html, nothing) without a fatal error
annoys me to no end."
It's by design too. Namespace is a declaration statement which says that
the complete file belong to this namespace (the mutltiple namespaces per
file is just an optimization technique and its introduction made more
confusion to the whole implementation then the advantage).
I assume namespaces are useful for frameworks and libraries and I hardly
imagine that somebody need HTML code before "<?php" tag there.
Chuck adds:
"I think that user-level classes are far more common in PHP than
internal classes, and as such should be given priority."
Is is related to __autoload()? Then it's a performance compromise.
It's possible to revert the behavior into more logical way, but it may
cause huge slowdown.
For now I see only one problems with current implementation:
Inability of mixing namespaced and non-namespaced code in case of
multiple namespaces per file. It makes the file concatenation technique
non useful.
I don't see a reason in namesapce with brackets for single namespace per
file and would like to save current syntax, but for multiple namespaces
brackets would help (however, even if brackets might be enabled, I am
completely against nested namespaces).
Thanks. Dmitry.
regards,
Lukas Kahwe Smith
mls@pooteeweet.org
The main PHP namespaces ideas come from Java packages and Java classes
have to write these "use" statements in the same way. It's not the end
of the world. I believe that well-designed frameworks won't require a
lot of use statements in user-space code.
Given the overwhelming feedback that this is indeed a big issue, I
would be more careful with saying this is a non issue for "well
designed" frameworks. If someone could post some links to their
namespace using code that is suffering from the current situation it
would provide a good opportunity for all of us to review and comment
(hopefully in a respectful manner .. after all these people are
treading on new territory so its much easier to make witty comments
than doing the initial hard work of trying to do something new).
Especially in this sense I would recommend all people on this list to
make sure they use language that encourages people from coming out of
the shadows on this topic, rather than scaring them off.
regards,
Lukas Kahwe Smith
mls@pooteeweet.org
Hi,
The main PHP namespaces ideas come from Java packages and Java
classes
have to write these "use" statements in the same way. It's not the
end
of the world. I believe that well-designed frameworks won't require a
lot of use statements in user-space code.Given the overwhelming feedback that this is indeed a big issue, I
would be more careful with saying this is a non issue for "well
designed" frameworks. If someone could post some links to their
namespace using code that is suffering from the current situation it
would provide a good opportunity for all of us to review and comment
(hopefully in a respectful manner .. after all these people are
treading on new territory so its much easier to make witty comments
than doing the initial hard work of trying to do something new).
Especially in this sense I would recommend all people on this list
to make sure they use language that encourages people from coming
out of the shadows on this topic, rather than scaring them off.
I don't see this as a big issue either. I've seen and worked with very
large Java code bases and it has never been an issue. Sure, there are
classes where you can end up with up to 40 or more imports. In Java,
IDEs and code-folding make this a non-issue. And it needs to be noted
that wildcard imports in Java are not used often. Direct imports of
the classes is often preferred, especially due to the fact that it's
made very easy by IDEs/editors. Even without the help of editors/
IDEs in PHP I would still consider this a small issue. And dozens of
imports/uses are not the common case anyway (it may even indicate
design issues/too much coupling).
Just my 2 cents on this topic.
Roman
Hi!
initial hard work of trying to do something new). Especially in this
sense I would recommend all people on this list to make sure they use
language that encourages people from coming out of the shadows on this
topic, rather than scaring them off.
I can only second that.
But on the other hand, I think we should also take proposals for change
on this stage with a grain of salt - when you using a new tool, there's
always a moment when you are tempted to say "ah, this works different
way from my old tool, why is that? It should work the same way, because
it's the only natural way!" but it feels natural only because you are
used to work with an old tool and not necessarily because it's better.
It is very hard to know the "you'll thank me later" situation until the
later happens, but sometimes it's exactly that. Sometimes it isn't, of
course :)
Stanislav Malyshev, Zend Software Architect
stas@zend.com http://www.zend.com/
(408)253-8829 MSN: stas@zend.com
Hello Stanislav,
Monday, September 8, 2008, 9:23:09 PM, you wrote:
Hi!
initial hard work of trying to do something new). Especially in this
sense I would recommend all people on this list to make sure they use
language that encourages people from coming out of the shadows on this
topic, rather than scaring them off.
I can only second that.
But on the other hand, I think we should also take proposals for change
on this stage with a grain of salt - when you using a new tool, there's
always a moment when you are tempted to say "ah, this works different
way from my old tool, why is that? It should work the same way, because
it's the only natural way!" but it feels natural only because you are
used to work with an old tool and not necessarily because it's better.
It is very hard to know the "you'll thank me later" situation until the
later happens, but sometimes it's exactly that. Sometimes it isn't, of
course :)
We love you all and you're the best - seriously - well we all do a cool job
here I think.
--
Stanislav Malyshev, Zend Software Architect
stas@zend.com http://www.zend.com/
(408)253-8829 MSN: stas@zend.com
Best regards,
Marcus
On Monday 08 September 2008 1:45:35 pm Lukas Kahwe Smith wrote:
The main PHP namespaces ideas come from Java packages and Java classes
have to write these "use" statements in the same way. It's not the end
of the world. I believe that well-designed frameworks won't require a
lot of use statements in user-space code.Given the overwhelming feedback that this is indeed a big issue, I
would be more careful with saying this is a non issue for "well
designed" frameworks. If someone could post some links to their
namespace using code that is suffering from the current situation it
would provide a good opportunity for all of us to review and comment
(hopefully in a respectful manner .. after all these people are
treading on new territory so its much easier to make witty comments
than doing the initial hard work of trying to do something new).
Especially in this sense I would recommend all people on this list to
make sure they use language that encourages people from coming out of
the shadows on this topic, rather than scaring them off.regards,
Lukas Kahwe Smith
mls@pooteeweet.org
I don't have code for it yet, but perhaps I can describe the way Drupal
(a "well designed" framework that is about 99% procedural code at the moment)
would most likely make use of namespaces and those who know what they're
talking about can say if it will be a problem or not.
Drupal's primary extension mechanism at present is hooks. Hooks are magically
named functions, formed from the name of the plugin module that provides them
and some "hook" name.
Other modules may invoke any hook at any time with the following. (Not the
actual code, but enough to demonstrate the idea.)
function module_invoke_all($hook) {
$args = func_get_args();
array_shift($args);
foreach (module_list() as $module) {
$function = $module . '_' . $hook;
if (function_exists($function) {
$return[] = call_user_func_array($function, $args);
}
}
return $return;
}
function modulea_foo() { ... }
function dostuff() {
$stuff = module_invoke_all('foo');
}
In the latest version we've added a lazy-load mechanism for functions, too, so
we don't have to load the entire code base.
We keep having people suggesting that we use a class-per-module instead of
prefixes. I usually shoot them down as that is a horrifically stupid idea.
For one, classes are not namespaces. Using them as one violates the way
classes are designed to work. For another, it means all code for a given
module would have to live in one and only one file. By using functions, we
are able to have modules implement hooks on behalf of other modules. We can
also split a module into multiple files, so code that is used only very
rarely needn't be loaded on every page load.
Looking at namespaces, they seem at first glance like a better alternative to
prefixes. My natural inclination would be:
core.inc:
<?php
function module_invoke_all($hook) {
$args = func_get_args();
array_shift($args);
foreach (module_list() as $module) {
$function = $module . '::' . $hook;
if (function_exists($function) {
$return[] = call_user_func_array($function, $args);
}
}
return $return;
}
?>
modulea.module:
<?php
namespace modulea;
function foo() { ... }
?>
moduleb.module:
<?php
namespace moduleb;
function dostuff() {
$stuff = module_invoke_all('foo');
}
?>
So given the current implementation, how badly will this break? When we
replace function_exists() with our own implementation that lazy-loads the
file that contains that function on demand (we already have that), how badly
will that fail?
How confused will PHP get if we introduce more classes (we are doing so)
within modules? The re-use of :: still feels like a landmine to me. Not to
reopen fresh wounds, but is there any documentation somewhere on why :: was
chosen as the symbol for namespaces? Every time the issue gets raised I
don't see a justification for :: other than "we've already dealt with that,
don't start again" and "well why are you using functions in namespaces in the
first place?" Is there anywhere (other than 5 year old list archives) we
could see what the reasoning for :: is other than "that's what C++ does"?
I'm really not trying to start another debate here; I'm genuinely curious.
The one-namespace-per-file restriction really does nothing to help us
(Drupal), but we would be able to work around it. I guess I still don't get
why it's so necessary if you just take the time to write an intelligent
autoloader. (Drupal's autoload implementation is two and only ever two
callbacks that get cached, so they are rarely called anyway.)
Anyway, just trying to provide another data point for consideration.
--
Larry Garfield
larry@garfieldtech.com
Hi,
I suppose since I use autoload and classes I belong to the first group.
Thing is, we still do care about performance.
I currenly use underscores as some other programmers do, to "fake"
namespaced identifiers, and from my tests and this discussion so far I'm
convinced the namespaces as they are right now would cause more troubles
than they solve.
Automating name resolution at runtime is bound to have problems as PHP was
never intended to go up in "scopes" and resolve variables, this is why we
have "use" in closures, and why we have "global" in methods and functions.
One of the things I suggested few months ago was that runtime resolution is
simply not included at all, and that we have a syntax for explicitly
specifying the global namespace, when the code is inside a namespace. I
heard lots of objections how ugly it is to prepend everything with "::" (not
that this is the only possibly syntax), but it increasingly is becoming
apparent that the automatic resolution is bound to have either bug-prone or
performance issues, so why introduce a "trap" in the language that people
will continuosly fall into?
Running the autoloader before every internal class would be just amazing for
those of us with caching crawlers (directory crawls for classes and stores
location in cache). I'll be having cache miss every time I use an internal
class, which with larger class libraries can run into 2-3 seconds at a time
to look for, say, class ArrayObject.
The other solution to put autoload last is equally bad as it means an
internal class would override one of mine, which I autoload, making the
autoloader useless.
So I'd say, make it explicit and remove the vague moment.
Regards,
Stan Vassilev
- those that tend to always spice up their API's by wrapping pretty much
all internal functionality (be if that the internal functionality has a
procedural or an OO API). These are also the people that will have the
more complex OO structures (deep inheritance). They also seem like the
most heavy users of namespaces- those that keep their structures flat, use native API's directly and
live in a mixed world of OO and procedural codeSo while we are assessing the impact its important to keep in mind which
user type is going to be affected in what way. Furthermore I hope that
some of the people that have build up a code base that uses namespaces
will do this benchmarking, because otherwise we will hardly get any
useful data. Even then of course the benchmarks must be taken with a
grain of salt (as always).I am including the email from Greg at the bottom here, along with a reply
from Stas (again read the archive to get the full story). Maybe if we
think hard about this one (now that we know that its an important real
world need), we can discover a solution that we did not see at first.
- namespaces
Here we need to make sure that the current state is now in a coherent
state. I think Derick still has some issues [3] with the recent change
by Greg [4], but even his criticism did not sound all to loud. So I
think we are in a good state here?My recent changes aside, there are still some fubar issues with name
resolution, and there has been some offlist discussion of ways to fix
this that have not led to concrete onlist proposals yet.For those who don't know what I'm talking about, the question is how to
resolve an unqualified classname inside a namespace. i.e. this code:a.php:
<?php
namespace Foo;
throw new Exception('is this Foo::Exception or ::Exception?');
?>Currently, the above code would throw ::Exception, because if a
namespaced class does not exist, internal classes are checked before
autoloading for performance reasons. However, if we execute this code
instead:b.php:
<?php
namespace Foo;
class Exception {}
include 'a.php';
?>then a.php would throw Foo::Exception. In other words, depending on
file inclusion order, classnames can change with current PHP accepted
practices. The solution to this is to use each namespaced class
explicitly:a2.php:
<?php
namespace Foo;
use Foo::Exception;
throw new Exception('this is Foo::Exception always');
?>However, all it takes is one forgotten "use" statement, and a very
subtle bug could be introduced later.Taking a step back, let's examine why autoload is not called before
checking internal classes - it is for performance reasons. However,
this performance enhancement causes unpredictable behavior by default
without explicit action.There is a simple solution, however. If one changes the name resolution
to this pseudo-code:
- check Foo::Exception for existence
- if not found, try to autoload Foo::Exception
- if not found, check for ::Exception existence, userspace or
internal (addition of userspace check also fixes other problems raised
on-list)- if not found, fail.
This fixes the logic problem, and re-introduces the performance slowdown
for internal classes. FORTUNATELY there is a simple solution to this,
which is to "use" all global classes:<?php
namespace Foo;
use ::ArrayIterator;
$a = new ArrayIterator(array(1,2,3));
?>The above code works exactly the same as:
<?php
namespace Foo;
$a = new ArrayIterator(array(1,2,3));
?>and short-circuits the name resolution to:
- check ::ArrayIterator for existence
- if not found, fail.
To summarize, we should scrap the "performance enhancement" that
introduces the potential for subtle and dangerous logic errors in name
resolution because it is still possible to achieve that performance
enhancement through one-time "use" of internal classnames.With these changes, namespace classname resolution will be 100%
deterministic regardless of file load order, it will still be possible
to override internal classnames with userspace classes, and for the
ultra-performance hungry, it is still easy to achieve faster classname
resolution for internal classes. Win-win.In other words, with the current implementation, you can just do "use
Foo::Exception;" and it works, but if you forget to do the use
statement, you can get unpredictable behavior with no warning until
yourYou get previctable behavior in all cases, there's no randomness in the
engine.to "use ::Exception", then your code is simply slightly slower (1 extra
call to autoload if it exists), but still works properly. It also
tiltsIt's not slightly slower, it's A LOT slower - exhaustive search of
whole include path for EACH call mentioning internal class. That means
you have to declare EACH internal class - even if no clashes ever
existed - for EACH use. Basically, it's the same as always using
::Class only implemented in a way that its disastrous effects are hidden
until you check performance of your code. Then you have to go back and
add use statement for each internal class in each of your files. Lot's
of fun that would be.regards,
Lukas Kahwe Smith
mls@pooteeweet.org
Hi!
So I'd say, make it explicit and remove the vague moment.
Do I understand right that you advocate having to use ::Exception each
time you need the internal class?
Stanislav Malyshev, Zend Software Architect
stas@zend.com http://www.zend.com/
(408)253-8829 MSN: stas@zend.com
Hi!
So I'd say, make it explicit and remove the vague moment.
Do I understand right that you advocate having to use ::Exception each
time you need the internal class?
As I said:
"I heard lots of objections how ugly it is to prepend everything with "::"
(not
that this is the only possibly syntax), but it increasingly is becoming
apparent that the automatic resolution is bound to have either bug-prone or
performance issues, so why introduce a "trap" in the language that people
will continuosly fall into?"
In other words: everyone is saying that "for those of us who need
performance or avoid resolution problems, can use ::, and the rest..." -->
who are those the rest, which don't care about performance and resolution
problems?
What is YOUR suggestion? Just tell us how hilarious it is to type "::" and
introduce all the other problems anyway.
Furthermore, the "::" (or rather I'd make it "php::") would only be required
in a namespace. For the procedural folks which don't put code in a
namespace, they're already implicitly in "php::" so they can continue
writing things exactly like thay do now.
Hi!
What is YOUR suggestion? Just tell us how hilarious it is to type "::"
and introduce all the other problems anyway.
Use short class name in 95% of the cases where it is unambiguous (i.e.
there's no class name in this namespace which collides with internal
class name). Use "use ::Foo" or "use Name::Space::Foo" or the qualified
name in the rest 5% of cases.
Stanislav Malyshev, Zend Software Architect
stas@zend.com http://www.zend.com/
(408)253-8829 MSN: stas@zend.com
Hello Lukas,
Wednesday, July 2, 2008, 10:00:22 PM, you wrote:
Aloha,
Since Johannes has been stumped (and therefore not as visible as he
would have hoped) with work and 5.3 CVS is already filled brim with
awesome new features, I have been approached by several people
wondering how we can speed up the process. I have always said I am
available to play the secretary to the RM, but in order to ensure that
developers have a greater chance of having an RM to talk to, Johannes
agreed to move me to co-RM status.
Congratulations!
And thanks for doing the work!!
Best regards,
Marcus
Am 02.07.2008 um 22:00 schrieb Lukas Kahwe Smith:
- intl extension
Last discussion ended without a decision on the class naming [10]. I
specifically remember Derick taking issue with intl ext "invading"
the date ext namespace. Stas however arguing that the intl ext is
supposed to bring some forwards compatibility to PHP 6 and therefore
naturally will need to span the namespaces of other extensions, that
are planned to be expanded for PHP 6.
Well... we had some discussions on the i18n list, and everyone except
Stas said we should have consistent class prefixes.
That did not stop Stas from simply rolling a final, stable 1.0.0.
Even though I and others pointed out other problems with it, where
fixing them will break BC.
Very unfortunate, this...
David
Hi!
Well... we had some discussions on the i18n list, and everyone except
Stas said we should have consistent class prefixes.
"Everyone" being you and one other person, and "except" being all people
actually working on the extension.
Anyway, I don't want to start another round of bikeshedding so I leave
it in RMs hands - if RMs decide it should be changed we change it, even
though I think it'd be a mistake. If you want me to explain again why
this way was chosen - I can.
Stanislav Malyshev, Zend Software Architect
stas@zend.com http://www.zend.com/
(408)253-8829 MSN: stas@zend.com
Am 02.07.2008 um 22:00 schrieb Lukas Kahwe Smith:
- intl extension
Last discussion ended without a decision on the class naming [10]. I
specifically remember Derick taking issue with intl ext "invading"
the date ext namespace. Stas however arguing that the intl ext is
supposed to bring some forwards compatibility to PHP 6 and therefore
naturally will need to span the namespaces of other extensions, that
are planned to be expanded for PHP 6.
Well... we had some discussions on the i18n list, and everyone except
Stas said we should have consistent class prefixes.
That did not stop Stas from simply rolling a final, stable 1.0.0.
Even though I and others pointed out other problems with it, where
fixing them will break BC.
Very unfortunate, this...
David
Just a quick reminder at Johannes and I were looking for feedback by
July 9th (aka tomorrow) ..
<snip>Summary:
Everybody review [1] and make sure all items you care about are on
the list and your name only appears next to stuff you are actually
able to complete in a timely manner.
regards,
Lukas Kahwe Smith
mls@pooteeweet.org
hi Lukas, Johannes and all,
Johannes agreed to move me to co-RM status.
That's a great news O:-D
- windows support
Ever since Edin disappeared it has become clear that we have a bus factor
issue with windows support. The windows team is working to rectify this
situation. We need to make sure that the infrastructure to deliver windows
binaries for PHP 5.3 as well as PECL extension is in place before we can
release 5.3.@Elizabeth/Pierre/Rob: How are things on this front?
We are making great progress in many areas. 90% all our dependencies
are under control now and we are able to quickly update them when
necessary (like security fixes, critical bugs for example). They
should all be available online in the next 10 days. We have also
documented all the processes. The important part about how to compile
php will follow shortly.
We should be able to update the snaps with our new builds during this
week. Not all libraries will be ready but it will be a good
opportunity to start to call for tests. We will also provide VC8
(VC2005) builds for x86 and x64 (experimental). The last important
part preventing a move is the apache2filter sapi being broken right
now (but it is not that critical, I will update the snaps during the
weekend even if the apache2filter is not fixed).
The new snaps will affect only 5.3 and 6. The 5.2 snaps will remain
untouched except some libraries (requiring security updates).
This move is the most important step as it is a critical part of our
release process. The various bugs or tweaks that we will certainly
have to do can be done at any time, even during the release phases
after the freeze.
I also try to coordinate the efforts from the various persons working
with us. We have got great helps from external persons (apache, some
asm fixes for example), they are not all part of the PHP core team. I
will come with more details about the team and our work later this
month.
Summary:
Everybody review [1] and make sure all items you care about are on the list
and your name only appears next to stuff you are actually able to complete
in a timely manner.
I have updated the 5.3 todos with my entries putting some deadlines in
front of them (did it last week). Let me know if you have any
questions.
Cheers,
Pierre