Hello all,
All the recent discussions about namespaces, have left many of us
wondering if our implementation is rock solid or not. However the
discussions were not really well organized. This is why I am thankful
that Marcus and Felipe have spend the better part of this Sunday to
write an RFC [1] that hopefully summarizes all the key concerns. Also
they have created a patch that they feel addresses the concerns.
So I ask you all to review the RFC and provide feedback. If you feel
something is missing, the best approach is probably to work with
Marcus and Felipe directly to get your concerns added. Only if there
is a difference of opinion in this process should this be brought to
internals. This way we can hopefully keep the discussion more focused
on actual differences, while making sure that the RFC covers most
concerns in one coherent document. If there are very large and
fundamental differences in opinion I encourage the creation of an
alternate RFC (and patch in case the RFC requires changes to the
codebase - which means you can also write an RFC to clarify the
current behavior on why it makes sense).
As you all hopefully know we have planned an alpha2 release for next
Tuesday [2]. At this stage I guess we should continue with that plan
and in case we need to make any bigger changes to namespaces (like
this RFC suggests), we will probably have to accept an alpha3 release
within 2-3 weeks time. Can't say I am happy about this, but I am quite
positive that bringing this discussion to a slightly more formal level
will give us a chance to make sure that in the end we can release PHP
5.3.0 with confidence.
regards,
Lukas Kahwe Smith
mls@pooteeweet.org
[1] http://wiki.php.net/rfc/namespacecurlies
[2] http://wiki.php.net/todo/php53
Lukas Kahwe Smith wrote:
Hello all,
All the recent discussions about namespaces, have left many of us
wondering if our implementation is rock solid or not. However the
discussions were not really well organized. This is why I am thankful
that Marcus and Felipe have spend the better part of this Sunday to
write an RFC [1] that hopefully summarizes all the key concerns. Also
they have created a patch that they feel addresses the concerns.So I ask you all to review the RFC and provide feedback. If you feel
something is missing, the best approach is probably to work with Marcus
and Felipe directly to get your concerns added. Only if there is a
difference of opinion in this process should this be brought to
internals. This way we can hopefully keep the discussion more focused on
Hi,
This is not a difference of opinion, but I would like to correct a
misconception: phar does not solve the problem that prompts
developers to concatenate files.
The problem is that the loading/unloading of the scanner and parser can
be significant overhead, and by cramming all code into a single file,
can result in a 10%-30% performance improvement over code in separate
files, even with an opcode cache. This has been verified independently
by Zend labs (Stanislav can attest to this) on their machines. The
performance difference depends on whether external code is loaded using
require with absolute path, require_once with relative path, autoload,
or some mix of these.
The problem requires streamlining of the loading process for files, and
could perhaps be addressed by attacking the bottleneck, but is not a
trivial problem to solve.
Just wanted to set the record straight.
Thanks,
Greg
Hello Gregory,
Sunday, August 31, 2008, 10:04:23 PM, you wrote:
Lukas Kahwe Smith wrote:
Hello all,
All the recent discussions about namespaces, have left many of us
wondering if our implementation is rock solid or not. However the
discussions were not really well organized. This is why I am thankful
that Marcus and Felipe have spend the better part of this Sunday to
write an RFC [1] that hopefully summarizes all the key concerns. Also
they have created a patch that they feel addresses the concerns.So I ask you all to review the RFC and provide feedback. If you feel
something is missing, the best approach is probably to work with Marcus
and Felipe directly to get your concerns added. Only if there is a
difference of opinion in this process should this be brought to
internals. This way we can hopefully keep the discussion more focused on
Hi,
This is not a difference of opinion, but I would like to correct a
misconception: phar does not solve the problem that prompts
developers to concatenate files.
The problem is that the loading/unloading of the scanner and parser can
be significant overhead, and by cramming all code into a single file,
can result in a 10%-30% performance improvement over code in separate
files, even with an opcode cache. This has been verified independently
by Zend labs (Stanislav can attest to this) on their machines. The
performance difference depends on whether external code is loaded using
require with absolute path, require_once with relative path, autoload,
or some mix of these.
The problem requires streamlining of the loading process for files, and
could perhaps be addressed by attacking the bottleneck, but is not a
trivial problem to solve.
Just wanted to set the record straight.
Please add that info to the rFC.
Best regards,
Marcus
Hi!
The problem is that the loading/unloading of the scanner and parser can
be significant overhead, and by cramming all code into a single file,
can result in a 10%-30% performance improvement over code in separate
files, even with an opcode cache. This has been verified independently
Not only this, but the fact that executing 50 different op-arrays, with
all setup and teardown that happens on the way, is definitely slower
than 1 op-array, and also the fact that early binding on compile stage
may be a bit faster when we are dealing with a lot of classes and
carefully arrange them.
As always, note that the benchmark was loading huge amount of classes
and doing nothing but, so don't expect your real-life app to get
anywhere near 30% on that. Actually, I have no idea how hard it would be
to make big app using a lot of modules and lot of different classes in
different modules to work this way, so I'm not even sure it's practical
or will give any benefit - since you might be loading a bunch of code
you'd never need. But the effect does exist.
Stanislav Malyshev, Zend Software Architect
stas@zend.com http://www.zend.com/
(408)253-8829 MSN: stas@zend.com
Hello Stanislav,
Tuesday, September 2, 2008, 9:51:38 AM, you wrote:
Hi!
The problem is that the loading/unloading of the scanner and parser can
be significant overhead, and by cramming all code into a single file,
can result in a 10%-30% performance improvement over code in separate
files, even with an opcode cache. This has been verified independently
Not only this, but the fact that executing 50 different op-arrays, with
all setup and teardown that happens on the way, is definitely slower
than 1 op-array, and also the fact that early binding on compile stage
may be a bit faster when we are dealing with a lot of classes and
carefully arrange them.
As always, note that the benchmark was loading huge amount of classes
and doing nothing but, so don't expect your real-life app to get
anywhere near 30% on that. Actually, I have no idea how hard it would be
to make big app using a lot of modules and lot of different classes in
different modules to work this way, so I'm not even sure it's practical
or will give any benefit - since you might be loading a bunch of code
you'd never need. But the effect does exist.
My guess is that it allows for development with heavy __autload usage and
then doing deployment based on static analysis where each target page
results in one large php file generated from that analysis. So there won't
be any overhead and each script target would be a single target of its own.
Best regards,
Marcus
Hi!
My guess is that it allows for development with heavy __autload usage and
then doing deployment based on static analysis where each target page
results in one large php file generated from that analysis. So there won't
be any overhead and each script target would be a single target of its own.
So each target (like each page, MVC action, etc.) would have its own
huge PHP file that has all classes used there? I guess for some
applications that could work, for others, more dynamic, that would fail
miserably. The maintainability of such thing is also challenging.
It would be nice to have some real-life examples of how such things work
out - so far I have seen only theory and synthetic benchmarks, which are
interesting, but not necessary what would happen on real project.
Stanislav Malyshev, Zend Software Architect
stas@zend.com http://www.zend.com/
(408)253-8829 MSN: stas@zend.com
Hello guys,
I just had to write you guys to give you some "real-life" examples.
We're working here at a PHP framework, named ALFA PHP Framework, that's
rather unique in the way that it enforces strong types in every method
(using classes for basic data types). We have our files organized this way:
- /inc/ directory = all BASE classes, auto-loaded by a "cached"
scandir (), loaded in a carefully calculated sequential order.
- /mod/user_authentification
- /mod/admin_cp - which are two MODULE classes that we load when we
need more functionality. We selectively load any modules we need.
As a benchmark, we have somewhere around 10 BASE classes, in 10 PHP
files, and about 10.000 LINES, and loading them takes just 0.00024 seconds
on a Core Duo machine. (0.0006 on an uniproc). We've actually gone further
and we "bypass" some scandir () methods by cacheing them in the _SESSION
variable, if we detected a proper user session once the platform has been
loaded. We don't use __autoload because it doesn't fit our need for
"carefull organized loading".
My conclusion is, that any "real-life" application, well-designed
would do "auto-loading" just for some base-classes, like we do here, and any
other dependencies like "developer required modules", will be cached some
way. We for example do a /per user caching of information, but other
developers can find other mechanism to cache this information, like a DB
result, or anything else.
I for once disagree with "each target (like each page, MVC action,
etc.) would have its own huge PHP file that has all classes used there",
because real-life apps need a dynamic approach, and as said earlier, any
GOOD designed app, will inherently think of a caching mechanism for it's
"loading/require/include" scheme. To accomplish this we actually went for
require_once on a module using an object $MOD->activateRegisteredModule
('user_authentification') - which scandirs () the array, caches the array,
quickly loads them in succession.
In the case of namespaces, PHP should be tunned for PHP classes
loaded in succession, or, if that is a problem, make the parser add
clases/code to the namespace when it detects a "namespace Something" token.
Regarding the need of PHP developers to have extensive C++
knowledge, I really don't care. I come from a C++ background, and any PHP
developer that doesn't understand C++ cannot be called "a developer". Guys,
I work as a Software Architect in Bucharest, Romania, and the quality of PHP
developers is questionable, due to the "easiness" of the PHP language. If
any amount of complication is needed, do it, and stop worrying about "PHP
developers". Real-life PHP developers are on this mailing-list, talking to
you guys, issuing bugs, doing real-life work. Don't make sacrifices just to
keep the language simple. Just go "full throttle forward!"
Regards,
Catalin Z. Alexandru
-----Original Message-----
From: Stanislav Malyshev [mailto:stas@zend.com]
Sent: Tuesday, September 02, 2008 8:02 PM
To: Marcus Boerger
Cc: Gregory Beaver; Lukas Kahwe Smith; PHP Internals List
Subject: Re: [PHP-DEV] Re: namespace RFC
Hi!
My guess is that it allows for development with heavy __autload usage and
then doing deployment based on static analysis where each target page
results in one large php file generated from that analysis. So there won't
be any overhead and each script target would be a single target of its
own.
So each target (like each page, MVC action, etc.) would have its own
huge PHP file that has all classes used there? I guess for some
applications that could work, for others, more dynamic, that would fail
miserably. The maintainability of such thing is also challenging.
It would be nice to have some real-life examples of how such things work
out - so far I have seen only theory and synthetic benchmarks, which are
interesting, but not necessary what would happen on real project.
Stanislav Malyshev, Zend Software Architect
stas@zend.com http://www.zend.com/
(408)253-8829 MSN: stas@zend.com
Hi!
So I ask you all to review the RFC and provide feedback. If you feel
Here's my feedback on the RFC.
-
The RFC seems to assume or imply that PHP programmers have extensive
C++ experience. IMHO it is not true for the majority of PHP programmers. -
Phar has nothing to do with file concatenation, as if was noted, and
concatenation's use is entirely unrelated to phar (and, before you
mention it, to bytecode caches - they can be used together, but one does
not preclude the other). -
Namespaces are NOT code flow control structure. Giving it a syntax
of a control structure is misleading, requiring "endnamespace" at the
end of each file makes no sense and just adds busywork for people. It
also is awfully ugly - braces at least have some decent looks...
Namespace also is not like a label in any way - it does not specify
point in code and you can not jump to it using either conditional (like
switch/case:) or unconditional (like goto) branch. -
I did not understand first paragraph of part named "Statements
outside namespaces" - what is has to do with caches? Could somebody
explain it to me (private mail/IRC/IM OK). -
I am not sure which exactly code RFC proposes to allow outside
namespaces, in any case I don't see why it is necessary to allow any
code to be put outside namespaces in namespaced files. For include, it
doesn't matter anyway, since included file has its own namespace, for
the rest I'm just unclear what else is proposed, please explain. -
Comment about "we kind of allow nested namespaces" because we allow
namespace in included file is wrong. These namespaces live absolutely
separately and are not nested in any meaningful way. All files in PHP
except for the head script are obtained by means of include(), so it is
only natural that namespace is allowed inside include - it would be
useless otherwise. Included file, however, creates it own namespacing
scope, and just as we do not say we allow nested classes because file
defining class can be included from inside any other class, same holds
for namespaces. -
Nested namespaces. I see that RFC authors chose to completely ignore
all my comments about namespace nesting, so I repeat them again for the
record.
Nesting namespaces implies hierarchy, hierarchy implies hierarchical
resolution, so if you inside namespace A::B::C::D::E::F, then name G is
expected to resolve when it means either A::G, A::B::G, A::B::C::G, etc.
Combined with autoloading, this makes resolution process prohibitively
expensive, and not resolvable in runtime by any means - since even if
you wrote A::B::C::D::E::F::G it could still mean
A::B::C::A::B::C::D::E::F::G - since you have not one-level resolution
but hierarchical resolution, even qualified name could be partial name.
Making nesting without hierarchy doesn't make any sense - why nest then,
what purpose would it serve?
Another objection for nesting would be that there's actually no
practical use for it in real code - as you could not nest across file
boundaries, only use would be if you pack substantial number of classes
from different modules into a single file, which usually is a bad idea.
If you follow standards accepted by many common applications and
separate classes in different files, nesting is completely useless, so
it is if you group closely related classes (they would probably then be
in the same hierarchy level).
So, summarily, right now I see serious technical challenge for nesting
(hierarchical lookups) and I don't see real use case for it.
Regards,
Stanislav Malyshev, Zend Software Architect
stas@zend.com http://www.zend.com/
(408)253-8829 MSN: stas@zend.com
Hello Stanislav,
Tuesday, September 2, 2008, 9:58:15 AM, you wrote:
Hi!
So I ask you all to review the RFC and provide feedback. If you feel
Here's my feedback on the RFC.
- The RFC seems to assume or imply that PHP programmers have extensive
C++ experience. IMHO it is not true for the majority of PHP programmers.
- Phar has nothing to do with file concatenation, as if was noted, and
concatenation's use is entirely unrelated to phar (and, before you
mention it, to bytecode caches - they can be used together, but one does
not preclude the other).
Yet, both are a means of deployment. Which is why I mentioned that. If you
do concatenation purely for speed then Phar is not the way to go.
- Namespaces are NOT code flow control structure. Giving it a syntax
of a control structure is misleading, requiring "endnamespace" at the
end of each file makes no sense and just adds busywork for people. It
also is awfully ugly - braces at least have some decent looks...
Namespace also is not like a label in any way - it does not specify
point in code and you can not jump to it using either conditional (like
switch/case:) or unconditional (like goto) branch.
It controls naming and name lookup. End of the story.
Current version looks like a misspelled version of labels and alternative
syntax which simply adds confusion.
- I did not understand first paragraph of part named "Statements
outside namespaces" - what is has to do with caches? Could somebody
explain it to me (private mail/IRC/IM OK).
I don't know it either, it is something that came up several times so I put
it into the RFC.
- I am not sure which exactly code RFC proposes to allow outside
namespaces, in any case I don't see why it is necessary to allow any
code to be put outside namespaces in namespaced files. For include, it
doesn't matter anyway, since included file has its own namespace, for
the rest I'm just unclear what else is proposed, please explain.
I am sorry but I absolutely fail to see how the following is in any way
whatsoever unclear:
====
Proposal and Patch
We propose to add namespaces as block structures and drop 'namespace foo;' in favor of 'namespace foo: ; endnamespace;', as in this patch. The tests are provided in a second patch.
In a second step nesting namespaces should be supported. This can easily be done by simply removing the corresponding error messages.
- Comment about "we kind of allow nested namespaces" because we allow
namespace in included file is wrong. These namespaces live absolutely
separately and are not nested in any meaningful way. All files in PHP
except for the head script are obtained by means of include(), so it is
only natural that namespace is allowed inside include - it would be
useless otherwise. Included file, however, creates it own namespacing
scope, and just as we do not say we allow nested classes because file
defining class can be included from inside any other class, same holds
for namespaces.
- Nested namespaces. I see that RFC authors chose to completely ignore
all my comments about namespace nesting, so I repeat them again for the
record.
Nesting namespaces implies hierarchy, hierarchy implies hierarchical
resolution, so if you inside namespace A::B::C::D::E::F, then name G is
expected to resolve when it means either A::G, A::B::G, A::B::C::G, etc.
Combined with autoloading, this makes resolution process prohibitively
expensive, and not resolvable in runtime by any means - since even if
you wrote A::B::C::D::E::F::G it could still mean
A::B::C::A::B::C::D::E::F::G - since you have not one-level resolution
but hierarchical resolution, even qualified name could be partial name.
Making nesting without hierarchy doesn't make any sense - why nest then,
what purpose would it serve?
namespace A::B::C::D::E::F;
$obj = new G;
Now what?
[...bla...]
Regards,
Stanislav Malyshev, Zend Software Architect
stas@zend.com http://www.zend.com/
(408)253-8829 MSN: stas@zend.com
Best regards,
Marcus
Hi!
I am sorry but I absolutely fail to see how the following is in any way
whatsoever unclear:
This is clear, I understand that and think it is completely wrong and
misguided, for reasons I described in my last email. What I did not
understand is what code you wanted to allow outside namespaces and what
all that include part and strings/not strings distinction talks about.
namespace A::B::C::D::E::F;
$obj = new G;Now what?
Now G is either A::B::C::D::E::F::G or ::G, but never A::B::G etc.
Do you understand the difference? No hierarchy.
Stanislav Malyshev, Zend Software Architect
stas@zend.com http://www.zend.com/
(408)253-8829 MSN: stas@zend.com
Hello all,
All the recent discussions about namespaces, have left many of us
wondering if our implementation is rock solid or not. However the
discussions were not really well organized. This is why I am
thankful that Marcus and Felipe have spend the better part of this
Sunday to write an RFC [1] that hopefully summarizes all the key
concerns. Also they have created a patch that they feel addresses
the concerns.
I have also asked in my blog about practical experiences from people
using PHP 5.3.0 with namespaces in development:
http://pooteeweet.org/blog/1288
The gist in the first 2 responses seem to be that they are ok with the
current state of things.
Anyways, anyone who cares should make their opinion known on this list
as clear as possible by Monday (if someone is aware of a good
discussion outside of internals please also let us know), so that
Johannes and I can make a decision no later than Tuesday without
having to feel like dictators. Personally at this point I would leave
things as is for now, move to beta and hope that this also increases
the number of end users testing and giving feedback. While I hope that
we dont have to do big changes after going to beta, if feedback makes
it necessary, we obviously have to accept it.
regards,
Lukas Kahwe Smith
mls@pooteeweet.org
Lukas Kahwe Smith schreef:
Hello all,
All the recent discussions about namespaces, have left many of us
wondering if our implementation is rock solid or not. However the
discussions were not really well organized. This is why I am thankful
that Marcus and Felipe have spend the better part of this Sunday to
write an RFC [1] that hopefully summarizes all the key concerns. Also
they have created a patch that they feel addresses the concerns.I have also asked in my blog about practical experiences from people
using PHP 5.3.0 with namespaces in development:
http://pooteeweet.org/blog/1288The gist in the first 2 responses seem to be that they are ok with the
current state of things.
they both admit they don't do (or are not interested in) the major point
the RFC tries to tackle (i.e. file concatenation).
subsequent posts do point out problems:
- "non-deterministic" (a.k.a error prone) __autoloading issues
- IFAIC Greg's arguments are sound, Stanislav's performance arguments are bogus
(imho) simply because, up until the point that the new functionality is
stable, complete and devoid of the WTF-factor it's performance should be
ignored ... make it work, then make it fast?
- namespaced constants/functions not autoloadable
- namespaced functions not aliasable
- the abiguity with static methods and namespaced functions
- Elizabeth states this very succinctly.
- inordinate number of use statements
- internal classes being 'favored' over user classes.
- which is likely to mean people will either avoid namespaces, avoid use statements
or worse still miss a use statement now and again ... see point 1.
If you ask me a major issue stems from the fact that the namespace scope operator
was chosen to be the same as the class scope operator, even if this incurred no technical
problems (which, I think, point 4 is), it still incurs the potential for major WTF when
simply reading code - at the very least having to constantly check the 'use' statements
at the top of a file to determine the actually referred to 'element'.
Lukas, you stated a while back you were nervous about the namespace functionality,
I believe you are right to be so. what there is currently will most likely do the
opposite of what it is intended to ... the intention being, I assume, to increase php's
'enterprise level' functionality & appearance (in terms of suitability).
rgds,
Jochem
PS - please be a Dictator! currently it seems that the dev that shouts the loudest gets
to shove his opinion/implementation down everyone's neck regardless of anyone's
objections (however sound) ... even when those objections come from other devs,
which makes a farce of the concept of meritocracy, besides nothing about open source
suggested it's development process needs to be done by commitee.
the more I think about it the more I believe php would benefit from a benevolent
dictator ... who that might be is a more difficult question to answer, one steeped
in politics. I could offer about 3 names that I think would suit the position,
but I doubt anyone of 'importance' has read this far and if they had they probably
attribute about as much weight to my opinions as they do to the average life of an ameoba.
Anyways, anyone who cares should make their opinion known on this list
as clear as possible by Monday (if someone is aware of a good discussion
outside of internals please also let us know), so that Johannes and I
can make a decision no later than Tuesday without having to feel like
dictators. Personally at this point I would leave things as is for now,
move to beta and hope that this also increases the number of end users
testing and giving feedback. While I hope that we dont have to do big
changes after going to beta, if feedback makes it necessary, we
obviously have to accept it.regards,
Lukas Kahwe Smith
mls@pooteeweet.org