Re: [PHP-DEV] Inconsistencies in 5.3
On Thursday 14 August 2008 12:36:29 am Rasmus Lerdorf wrote: Larry Garfield wrote: I would also note that include up front and have a good autoload scheme works great if you are writing all classes. If you're trying to use namespaces and functions, there is no autoload. That makes the autoload argument moot, and pre-loading everything up front can get ridiculously expensive in large systems, and even then you don't always know what to load up front. (Think anything that accepts plugins.) So an answer of well if it throws a warning when you do that, don't do that is simply not realistic in practice. With an opcode cache, it is actually often more efficient to load everything up front even if you aren't using it all on any given request. By using autoload or other conditional mechanisms you lose the function and class caching mechanism provided by the opcode cache because you have now pushed the creation of these to the executor instead of letting the opcode cache cache them for you. And assuming your include_path setting and your include hierachy is clean so you don't have any or at least only minimal per-include stat overhead, whether you include 1 or 20 files on a request isn't a big deal since they are all going to be in memory anyway. -Rasmus For better or worse 99% of the code I write runs on systems without an opcode cache 99% of the time so that's what I optimize for. That it is apparently impossible to optimize for both opcode caching and non-opcode caching environments at the same time (the former hates conditional include, the latter loves it) is a problem in itself, although I will be honest that I have never fully understood the reasons for it. (Doesn't the opcode cache just recognize oh yeah, file /foo/bar/baz.php, I've got that parsed already I'll just add that to the runtime environment?) Even then, every benchmark I've seen for Drupal (the system I work on) still gives a several-fold increase in runtime performance with an opcode cache, so I am not super worried about eeking out every last CPU cycle. We also by nature have to support user-pluggable modules, which cannot be statically included. There's also memory usage to consider. In our testing, conditional includes sliced 25% off of the memory usage when not using an opcode cache and had no noticeable effect when using an opcode cache, so that's still a big win for larger code bases. We're working at making even more code conditionally included in the next version for that exact reason. In any case, the point I am making is that saying well, don't use conditional includes and namespaces or don't use functions and namespaces is a non-option. Either of those pretty much guarantees that we (Drupal) will never be able to use namespaces in practice. -- Larry Garfield [EMAIL PROTECTED] -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Inconsistencies in 5.3
Larry Garfield wrote: On Thursday 14 August 2008 12:36:29 am Rasmus Lerdorf wrote: Larry Garfield wrote: I would also note that include up front and have a good autoload scheme works great if you are writing all classes. If you're trying to use namespaces and functions, there is no autoload. That makes the autoload argument moot, and pre-loading everything up front can get ridiculously expensive in large systems, and even then you don't always know what to load up front. (Think anything that accepts plugins.) So an answer of well if it throws a warning when you do that, don't do that is simply not realistic in practice. With an opcode cache, it is actually often more efficient to load everything up front even if you aren't using it all on any given request. By using autoload or other conditional mechanisms you lose the function and class caching mechanism provided by the opcode cache because you have now pushed the creation of these to the executor instead of letting the opcode cache cache them for you. And assuming your include_path setting and your include hierachy is clean so you don't have any or at least only minimal per-include stat overhead, whether you include 1 or 20 files on a request isn't a big deal since they are all going to be in memory anyway. -Rasmus For better or worse 99% of the code I write runs on systems without an opcode cache 99% of the time so that's what I optimize for. That it is apparently impossible to optimize for both opcode caching and non-opcode caching environments at the same time (the former hates conditional include, the latter loves it) is a problem in itself, although I will be honest that I have never fully understood the reasons for it. (Doesn't the opcode cache just recognize oh yeah, file /foo/bar/baz.php, I've got that parsed already I'll just add that to the runtime environment?) No, it also takes all top-level functions and classes and caches the created functions and classes in shared memory and modifies the cached opcodes to not need to create these at execution time. However, it obviously can't do this if the execution context is required in order to know whether the function or class should exist on that request, so whenever you do any sort of conditional function or class definition you lose this level of caching. -Rasmus -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Inconsistencies in 5.3
For better or worse 99% of the code I write runs on systems without an opcode cache 99% of the time so that's what I optimize for. That it is apparently impossible to optimize for both opcode caching and non-opcode caching environments at the same time (the former hates conditional include, the latter loves it) is a problem in itself, although I will be honest that I have never fully understood the reasons for it. (Doesn't the opcode cache just recognize oh yeah, file /foo/bar/baz.php, I've got that parsed already I'll just add that to the runtime environment?) No, it also takes all top-level functions and classes and caches the created functions and classes in shared memory and modifies the cached opcodes to not need to create these at execution time. However, it obviously can't do this if the execution context is required in order to know whether the function or class should exist on that request, so whenever you do any sort of conditional function or class definition you lose this level of caching. -Rasmus Hi, This is why it pays to have two automated distribution models. For deployment with no opcode cache, and for development/version control, an autoloader using a class map is most practical. An automated packer can take all classes and functions (or part of them in common use) and put them in the bootstrap file for opcode deployment, leaving only the less common to autoload. (And which makes the fact we can now have multiple namespaces in one file really important) Regards, Stan Vassilev -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Inconsistencies in 5.3
On Thursday 14 August 2008 2:08:23 am Stan Vassilev | FM wrote: For better or worse 99% of the code I write runs on systems without an opcode cache 99% of the time so that's what I optimize for. That it is apparently impossible to optimize for both opcode caching and non-opcode caching environments at the same time (the former hates conditional include, the latter loves it) is a problem in itself, although I will be honest that I have never fully understood the reasons for it. (Doesn't the opcode cache just recognize oh yeah, file /foo/bar/baz.php, I've got that parsed already I'll just add that to the runtime environment?) No, it also takes all top-level functions and classes and caches the created functions and classes in shared memory and modifies the cached opcodes to not need to create these at execution time. However, it obviously can't do this if the execution context is required in order to know whether the function or class should exist on that request, so whenever you do any sort of conditional function or class definition you lose this level of caching. -Rasmus Hm, I see. So you still get the cached compiled opcodes, but not the cached linking. (To use C++ terminology, which I'm sure is technically inaccurate in this case.) Thanks. Hi, This is why it pays to have two automated distribution models. For deployment with no opcode cache, and for development/version control, an autoloader using a class map is most practical. An automated packer can take all classes and functions (or part of them in common use) and put them in the bootstrap file for opcode deployment, leaving only the less common to autoload. (And which makes the fact we can now have multiple namespaces in one file really important) Regards, Stan Vassilev Not looking to start a flame war, really, but how do the above opcode concerns impact Phar? (I mention that here because it was discussed as a potential alternative to multiple namespaces per file to avoid the many-stats problem.) -- Larry Garfield [EMAIL PROTECTED] -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Inconsistencies in 5.3
Hello Stanislav, Thursday, August 14, 2008, 12:25:35 AM, you wrote: Hi! I think Marcus is talking about files that are included that do not specify a namespace explicitly. In this situation the context does matter. No it does not. Would anybody check what they are talking about before starting to discuss things? Start with yourself by checking out Zend/tests/ns_069.phpt and then come back if you see no problem there. Since I am sure you will ignore the issue here goes anyway. The included file has a different scope. Hence a lot of stuff like reflection does not work as expected. End of the story. If we truely had multiple namespace support, then we would simply keep the namespce for the include and if the file has a namespace it would be compared to the current one, if that is equal all is fine. For __autoload it is also quite easy, it should simply be defined outside of a namespace. And if you need to combine it with namespace, then simply register the different autoload functrions with spl_autoload_register(). Best regards, Marcus -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Inconsistencies in 5.3
Hello Guilherme,
Thursday, August 14, 2008, 3:37:17 AM, you wrote:
I read parts of the thread and I'm curious about a situation that
seems Marcus' patch will deny.
It seems that it'll be denied the possibility to require/include a
file inside of a method of a class/function inside a namespace.
Now I need to bring a situation where maybe Doctrine will implement.
We may have the namespace Doctrine and inside of it a function or
maybe a method called autoload. This one will be linked with
spl_register_autoload.
This method actually includes a file on script and since the autoload
is inside namespace Doctrine and the file included may be part of
namespace Doctrine::XXX::YYY, how will it work?
It seems Marcus' patch denies this possibility.
I review the earlier implementations of namespace support, but now I'm
curious what's the real issue with namespaces and included files.
Please, please please, that's not a flaming discussion. I just want to
have things clear in my head why this design decision was taken.
IMHO, if I have something like:
namespace Doctrine {
function autoload($class) { include 'Doctrine/Orm/Entity.php'; }
}
And...:
namespace Doctrine::Orm {
class Entity { ... }
}
The included file should have 2 different possibilities of being processed:
1- It is called in global scope, so it'll be able to Doctrine::Orm::Entity
2- It is called in local scope. This is something that would be
awesome, but would lead compilers crazy. How?
The example:
namespace Doctrine {
function autoload($class) { include 'Doctrine/Orm/Entity.php'; }
}
And...:
namespace Orm
{
class Entity { ... }
}
And since include was done inside Doctrine namespace, it'd be
accessible through Doctrine::Orm::Entity.
This would lead after some time into a newer request of users...
namespace Foo {
namespace Bar {
class Baz { ... }
}
}
// Acess as Foo::Bar::Baz
Or even:
namespace Foo::Bar {
namespace Baz::Wee {
class Blah { ... }
}
}
// Acess as Foo::Bar::Baz::Wee:Blah
In this situation, if you separate (using the last example), you could
do a simply:
namespace Foo::Bar {
include 'Baz/Wee.php';
}
And it should result the same thing as my example.
Please notice I do not want to start a why not use my syntax. I want
answers what can be accomplish, what cannot be accomplished and why
things are possible/impossible.
Lukas knows more than anyone else that we from Doctrine team are
expecting 5.3 to be a God master in namespace and waiting for a full
scope to be defined (and win release work) to start to port our code.
Thanks in advance,
Cheers,
On Wed, Aug 13, 2008 at 8:00 PM, Lukas Kahwe Smith [EMAIL PROTECTED] wrote:
On 14.08.2008, at 00:54, Rasmus Lerdorf wrote:
Gregory Beaver wrote:
Lukas Kahwe Smith wrote:
On 13.08.2008, at 22:18, Stanislav Malyshev wrote:
Simply include a script from two locations with different namespaces
or one
with namespace and the otherone without.
I'm afraid you misunderstand how namespaces work. As I explained
numerous times, namespaces are file-local, and this when including
file, it does not matter a bit what was including context.
I think Marcus is talking about files that are included that do not
specify a namespace explicitly. In this situation the context does
matter.
We do not know if the developer in question is aware that the context
would matter in this case. Actually like I said in a previous email it
would be nice to at least not throw a warning if the file that is
included specifies an explicit namespace (I assume that is possible?).
Maybe adding a new include is a solution. This way developers can say
explicitly what they want to do without having to suppress the warning.
Then again quickly some smartass developer is going to teach people that
these annoying warnings go away if you just use this new include
everywhere. Then again, I am not sure if I even have my head wrapped
around this entire namespace thing.
Hi,
Currently, if you include a file within a class method that contains
function definitions, they remain functions outside the class. If you
include a file that contains a class.
In short, only global cpde is executed in the scope, and there is no
precedent in PHP to redefine re-usable elements based on scope.
Why would namespaces be any different? This whole argument makes no
sense to me.
Well, it depends how you view the scope. If you include a file that
defines a variable from within a function or a method, that variable becomes
function-scoped, not global. In the case of a namespaced function or method
including a file containing functions or classes, those classes become
global. That has, of course, always been the case, but we haven't had the
concept of a namespace context before and we haven't had anything that was
file-scoped like this. So people might extrapolate from the
function-context case to this and
Re: [PHP-DEV] Inconsistencies in 5.3
Hello Rasmus, Thursday, August 14, 2008, 7:36:29 AM, you wrote: Larry Garfield wrote: I would also note that include up front and have a good autoload scheme works great if you are writing all classes. If you're trying to use namespaces and functions, there is no autoload. That makes the autoload argument moot, and pre-loading everything up front can get ridiculously expensive in large systems, and even then you don't always know what to load up front. (Think anything that accepts plugins.) So an answer of well if it throws a warning when you do that, don't do that is simply not realistic in practice. With an opcode cache, it is actually often more efficient to load everything up front even if you aren't using it all on any given request. By using autoload or other conditional mechanisms you lose the function and class caching mechanism provided by the opcode cache because you have now pushed the creation of these to the executor instead of letting the opcode cache cache them for you. And assuming your include_path setting and your include hierachy is clean so you don't have any or at least only minimal per-include stat overhead, whether you include 1 or 20 files on a request isn't a big deal since they are all going to be in memory anyway. See, this is something I fail to understant/accept. With all the crappy delayed inheritance and whatnot dynamic feature of the language it only seems fair that we develop apc in a way that it checks whether a class always gets created from the same file. Or at least we should provide a flag where apc would evaluate __autoload calls only once and then caches the results. If someone wants to screw up, it is their fault, erm their tradeoff, they'd simply get a much slower execution time as they wouldn't be able to use that optimization. Best regards, Marcus -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Inconsistencies in 5.3
Hi! Start with yourself by checking out Zend/tests/ns_069.phpt and then come back if you see no problem there. Since I am sure you will ignore the issue here goes anyway. I do not see any problem there, right. The included file has a different scope. Hence a lot of stuff like reflection does not work as expected. End of the story. If we truely It's not even beginning of the story, since you forgot to explain what did you mean by as expected. had multiple namespace support, then we would simply keep the namespce for the include and if the file has a namespace it would be compared Well, we do not, that's not how namespaces work. -- Stanislav Malyshev, Zend Software Architect [EMAIL PROTECTED] http://www.zend.com/ (408)253-8829 MSN: [EMAIL PROTECTED] -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
RE: [PHP-DEV] Inconsistencies in 5.3
What do you mean are file-local?! So if I have a B.php, that includes A.php, and in A.php I have a namespace called Foo, I can't call a function from that namespace like Foo::someFunc () unless I call it from A.php?! So a Foo:someFunc () from B.php would be illegal? Cause if you're suggesting this, the whole idea of namespaces does something that can be described in PHP as: die ($namespaceLittleNamespaceIdea); -Original Message- From: Stanislav Malyshev [mailto:[EMAIL PROTECTED] Sent: Wednesday, August 13, 2008 11:18 PM To: Marcus Boerger Cc: internals@lists.php.net Subject: Re: [PHP-DEV] Inconsistencies in 5.3 Hi! Simply include a script from two locations with different namespaces or one with namespace and the otherone without. I'm afraid you misunderstand how namespaces work. As I explained numerous times, namespaces are file-local, and this when including file, it does not matter a bit what was including context. -- Stanislav Malyshev, Zend Software Architect [EMAIL PROTECTED] http://www.zend.com/ (408)253-8829 MSN: [EMAIL PROTECTED] -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Inconsistencies in 5.3
Marcus Boerger wrote: Hello Rasmus, Thursday, August 14, 2008, 7:36:29 AM, you wrote: Larry Garfield wrote: I would also note that include up front and have a good autoload scheme works great if you are writing all classes. If you're trying to use namespaces and functions, there is no autoload. That makes the autoload argument moot, and pre-loading everything up front can get ridiculously expensive in large systems, and even then you don't always know what to load up front. (Think anything that accepts plugins.) So an answer of well if it throws a warning when you do that, don't do that is simply not realistic in practice. With an opcode cache, it is actually often more efficient to load everything up front even if you aren't using it all on any given request. By using autoload or other conditional mechanisms you lose the function and class caching mechanism provided by the opcode cache because you have now pushed the creation of these to the executor instead of letting the opcode cache cache them for you. And assuming your include_path setting and your include hierachy is clean so you don't have any or at least only minimal per-include stat overhead, whether you include 1 or 20 files on a request isn't a big deal since they are all going to be in memory anyway. See, this is something I fail to understant/accept. With all the crappy delayed inheritance and whatnot dynamic feature of the language it only seems fair that we develop apc in a way that it checks whether a class always gets created from the same file. Or at least we should provide a flag where apc would evaluate __autoload calls only once and then caches the results. If someone wants to screw up, it is their fault, erm their tradeoff, they'd simply get a much slower execution time as they wouldn't be able to use that optimization. We already do that. See the report_autofilter check in APC. -Rasmus -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Inconsistencies in 5.3
Hi Markus,
Am Dienstag, den 12.08.2008, 22:51 +0200 schrieb Marcus Boerger:
[...]
a) Prevent include/require inside namespaced functions.
Patch: php-no-include-in-namespaced-functions-6.0-20080812.diff.txt
Should pretty much work.
So this means something like this won't work without a warning anymore?
namespace Foo;
class View
{
public function render($file)
{
include $file;
}
}
[...]
cu, Lars
signature.asc
Description: Dies ist ein digital signierter Nachrichtenteil
Re: [PHP-DEV] Inconsistencies in 5.3
Hello Lars,
Wednesday, August 13, 2008, 11:55:23 AM, you wrote:
Hi Markus,
Am Dienstag, den 12.08.2008, 22:51 +0200 schrieb Marcus Boerger:
[...]
a) Prevent include/require inside namespaced functions.
Patch: php-no-include-in-namespaced-functions-6.0-20080812.diff.txt
Should pretty much work.
So this means something like this won't work without a warning anymore?
namespace Foo;
class View
{
public function render($file)
{
include $file;
}
}
[...]
cu, Lars
Namespaces are new, so it never worked before. But yes, this would trigger
a warning in the compiler which means you are told to not do this with apc
or other compiler caches.
marcus
marcus
Best regards,
Marcus
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Inconsistencies in 5.3
Hi Markus
Am Mittwoch, den 13.08.2008, 15:21 +0200 schrieb Marcus Boerger:
[...]
Namespaces are new, so it never worked before. But yes, this would trigger
a warning in the compiler which means you are told to not do this with apc
or other compiler caches.
You are aware that this is used in a number of PHP libraries/frameworks?
Additionally, a lot have code like this:
class ...
public function foo()
{
if (!$this-_something) {
require_once 'Foo/Exception.php';
throw new FooException();
}
}
I guess most of the time those using OP caches know what they are doing.
So why should a warning be triggered here?
cu, Lars
signature.asc
Description: Dies ist ein digital signierter Nachrichtenteil
Re: [PHP-DEV] Inconsistencies in 5.3
On 13.08.2008, at 15:35, Lars Strojny wrote:
Hi Markus
Am Mittwoch, den 13.08.2008, 15:21 +0200 schrieb Marcus Boerger:
[...]
Namespaces are new, so it never worked before. But yes, this would
trigger
a warning in the compiler which means you are told to not do this
with apc
or other compiler caches.
You are aware that this is used in a number of PHP libraries/
frameworks?
Additionally, a lot have code like this:
class ...
public function foo()
{
if (!$this-_something) {
require_once 'Foo/Exception.php';
throw new FooException();
}
}
Right, this is quite common. So is including drivers inside factory
methods. Even if they are not explicit, there is obviously also
autoload.
Just so that I get straight why we are doing this:
The namespace of the file is not magically applied to the included
code, so instead one would expect the included code to set the
relevant namespace itself.
Now for any library that would use namespaces and have an include
inside that namespace, it would also set a namespace in the included
file or its likely a bug. Not sure if we could only throw a warning if
we do an include without a namespace being defined in the file that is
being included? That starts being quite fancy in terms of error
handling though, which even if doable probably adds overhead?
The other situation I see would be a namespaced template engine that
loads some template who's content is not namespaced explicitly. It
does not really make sense to start defining namespaces in templates
just to get around that warning.
I guess most of the time those using OP caches know what they are
doing.
So why should a warning be triggered here?
Thats a pretty big assumption.
regards,
Lukas Kahwe Smith
[EMAIL PROTECTED]
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Inconsistencies in 5.3
Hi Lukas,
Am Mittwoch, den 13.08.2008, 16:42 +0200 schrieb Lukas Kahwe Smith:
[...]
Right, this is quite common. So is including drivers inside factory
methods. Even if they are not explicit, there is obviously also
autoload.
Which is not the same, as far as I understand the proposed modification.
The only case where autoload would be triggered is when the autoload
method is a static method inside a namespaced autoloader class.
Just so that I get straight why we are doing this:
The namespace of the file is not magically applied to the included
code, so instead one would expect the included code to set the
relevant namespace itself.
As far as I understood the discussion, it was related to OP code caches.
The opcode result from this snippet ...
?php
namespace Foo;
class Bar {
public function includeFile() {
require_once 'file.php';
}
}
... is not the same as the opcode result from the following:
?php
class Bar {
public function includeFile() {
require_once 'file.php';
}
}
Am I getting this right? Assuming I did, the opcode for including
file.php from Foo::Bar will be the same regardless what happened before,
right? If yes, than I really see no point in this warning.
cu, Lars
signature.asc
Description: Dies ist ein digital signierter Nachrichtenteil
Re: [PHP-DEV] Inconsistencies in 5.3
Hello Lars,
Wednesday, August 13, 2008, 3:35:32 PM, you wrote:
Hi Markus
Am Mittwoch, den 13.08.2008, 15:21 +0200 schrieb Marcus Boerger:
[...]
Namespaces are new, so it never worked before. But yes, this would trigger
a warning in the compiler which means you are told to not do this with apc
or other compiler caches.
You are aware that this is used in a number of PHP libraries/frameworks?
Additionally, a lot have code like this:
Once again, no code can trigger the warning right now. As the warning
requires a namespace before it can be triggered. Autoload should be
declared outside a namespace so that it can load correct namespace classes
anyway. So I do not see an issue here.
class ...
public function foo()
{
if (!$this-_something) {
require_once 'Foo/Exception.php';
throw new FooException();
}
}
I guess most of the time those using OP caches know what they are doing.
So why should a warning be triggered here?
cu, Lars
Best regards,
Marcus
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Inconsistencies in 5.3
Hi! Namespaces are new, so it never worked before. But yes, this would trigger a warning in the compiler which means you are told to not do this with apc or other compiler caches. This has very little to do with APC, AFAIU (it doesn't work differenty with APC than without it), but anyway I think the warning is redundant. It would also produce hundereds if not thousands of warnings on libraries like Zend Framework which include components dynamically (and the components of course would be correctly namespaced). -- Stanislav Malyshev, Zend Software Architect [EMAIL PROTECTED] http://www.zend.com/ (408)253-8829 MSN: [EMAIL PROTECTED] -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Inconsistencies in 5.3
Hi!
As far as I understood the discussion, it was related to OP code caches.
The opcode result from this snippet ...
?php
namespace Foo;
class Bar {
public function includeFile() {
require_once 'file.php';
}
}
... is not the same as the opcode result from the following:
?php
class Bar {
public function includeFile() {
require_once 'file.php';
}
}
These will generate identical opcodes except that the class name in the
former snippet would be Foo::Bar of course.
--
Stanislav Malyshev, Zend Software Architect
[EMAIL PROTECTED] http://www.zend.com/
(408)253-8829 MSN: [EMAIL PROTECTED]
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Inconsistencies in 5.3
Hi! Once again, no code can trigger the warning right now. As the warning requires a namespace before it can be triggered. Autoload should be declared outside a namespace so that it can load correct namespace classes anyway. So I do not see an issue here. autoload can work just fine inside namespace as well as outside, there's no problem with that, and class names given to autoloader are always full class names, so where it is declared has no effect. As for the argument there's no namespaced code so anything goes since we can't break any code - it's bogus. We expect a lot of existing code to be converted to namespaces once 5.3 is out, and we want to make it as painless as possible. Throwing warning each time you have include is not the way. -- Stanislav Malyshev, Zend Software Architect [EMAIL PROTECTED] http://www.zend.com/ (408)253-8829 MSN: [EMAIL PROTECTED] -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Inconsistencies in 5.3
Hi Stas, Am Mittwoch, den 13.08.2008, 11:29 -0700 schrieb Stanislav Malyshev: [...] As for the argument there's no namespaced code so anything goes since we can't break any code - it's bogus. We expect a lot of existing code to be converted to namespaces once 5.3 is out, and we want to make it as painless as possible. Throwing warning each time you have include is not the way. I totally agree with this: a lot of library I can think of uses such inline includes. Hopefully these libraries migrate to namespaces but without allowing inline includes it would be really painful. cu, Lars signature.asc Description: Dies ist ein digital signierter Nachrichtenteil
Re: [PHP-DEV] Inconsistencies in 5.3
Hello Stanislav, Wednesday, August 13, 2008, 8:29:43 PM, you wrote: Hi! Once again, no code can trigger the warning right now. As the warning requires a namespace before it can be triggered. Autoload should be declared outside a namespace so that it can load correct namespace classes anyway. So I do not see an issue here. autoload can work just fine inside namespace as well as outside, there's no problem with that, and class names given to autoloader are always full class names, so where it is declared has no effect. As for the argument there's no namespaced code so anything goes since we can't break any code - it's bogus. We expect a lot of existing code to be converted to namespaces once 5.3 is out, and we want to make it as painless as possible. Throwing warning each time you have include is not the way. As painless as possible, so we want to tell people that they shouldn't just write a shell script that adds the name of the directory as the namespace or the name of the project an dthen never read the documentation. We probably want to tell people that this will probably break opcode caches. And if someone decides that he is fine with the issue as he doesn't use opcode caches and then someone else takes that code, he probably want to know about this issue. Best regards, Marcus -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Inconsistencies in 5.3
Hi! As painless as possible, so we want to tell people that they shouldn't just write a shell script that adds the name of the directory as the namespace or the name of the project an dthen never read the documentation. We No, unfortunately that won't work. I wish it did, but it would not :) probably want to tell people that this will probably break opcode caches. I must be missing something. What would break opcode caches? I don't know any single line of code that would break opcode caches. Can you provide an example that would break opcode caches? -- Stanislav Malyshev, Zend Software Architect [EMAIL PROTECTED] http://www.zend.com/ (408)253-8829 MSN: [EMAIL PROTECTED] -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Inconsistencies in 5.3
Hello Stanislav, Wednesday, August 13, 2008, 10:01:10 PM, you wrote: Hi! As painless as possible, so we want to tell people that they shouldn't just write a shell script that adds the name of the directory as the namespace or the name of the project an dthen never read the documentation. We No, unfortunately that won't work. I wish it did, but it would not :) probably want to tell people that this will probably break opcode caches. I must be missing something. What would break opcode caches? I don't know any single line of code that would break opcode caches. Can you provide an example that would break opcode caches? Simply include a script from two locations with different namespaces or one with namespace and the otherone without. Best regards, Marcus -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Inconsistencies in 5.3
Hi! Simply include a script from two locations with different namespaces or one with namespace and the otherone without. I'm afraid you misunderstand how namespaces work. As I explained numerous times, namespaces are file-local, and this when including file, it does not matter a bit what was including context. -- Stanislav Malyshev, Zend Software Architect [EMAIL PROTECTED] http://www.zend.com/ (408)253-8829 MSN: [EMAIL PROTECTED] -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Inconsistencies in 5.3
On 13.08.2008, at 22:18, Stanislav Malyshev wrote: Simply include a script from two locations with different namespaces or one with namespace and the otherone without. I'm afraid you misunderstand how namespaces work. As I explained numerous times, namespaces are file-local, and this when including file, it does not matter a bit what was including context. I think Marcus is talking about files that are included that do not specify a namespace explicitly. In this situation the context does matter. We do not know if the developer in question is aware that the context would matter in this case. Actually like I said in a previous email it would be nice to at least not throw a warning if the file that is included specifies an explicit namespace (I assume that is possible?). Maybe adding a new include is a solution. This way developers can say explicitly what they want to do without having to suppress the warning. Then again quickly some smartass developer is going to teach people that these annoying warnings go away if you just use this new include everywhere. Then again, I am not sure if I even have my head wrapped around this entire namespace thing. regards, Lukas Kahwe Smith [EMAIL PROTECTED] -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Inconsistencies in 5.3
Lukas Kahwe Smith wrote: On 13.08.2008, at 22:18, Stanislav Malyshev wrote: Simply include a script from two locations with different namespaces or one with namespace and the otherone without. I'm afraid you misunderstand how namespaces work. As I explained numerous times, namespaces are file-local, and this when including file, it does not matter a bit what was including context. I think Marcus is talking about files that are included that do not specify a namespace explicitly. In this situation the context does matter. We do not know if the developer in question is aware that the context would matter in this case. Actually like I said in a previous email it would be nice to at least not throw a warning if the file that is included specifies an explicit namespace (I assume that is possible?). Maybe adding a new include is a solution. This way developers can say explicitly what they want to do without having to suppress the warning. Then again quickly some smartass developer is going to teach people that these annoying warnings go away if you just use this new include everywhere. Then again, I am not sure if I even have my head wrapped around this entire namespace thing. Please, no new include. It's bad enough that we have 4 different ones as it is. The question here comes down to how we are going to teach people how namespaces work when they write code that might visually and logically be expected to add the included functions and classes to the namespace where in fact they won't. We can either throw warnings, as per Marcus' patch, or we can document the crap out of it. The warnings will force people to learn with the big drawback that there are many valid use cases and warnings in PHP, even if turned off via error_reporting, are quite expensive. So, without some sort of short-circuiting of our current error logic, which would break error_get_last(), I am against adding an E_NOTICE or an E_STRICT, for cases that might have a correct use. This is something we are going to have to think more about in PHP 6 because of all the new E_STRICTs. We might want to bite the bullet and change error_get_last to respect the error_reporting level, or perhaps just ignore E_STRICT when it isn't enabled. -Rasmus -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Inconsistencies in 5.3
Hi! I think Marcus is talking about files that are included that do not specify a namespace explicitly. In this situation the context does matter. No it does not. Would anybody check what they are talking about before starting to discuss things? -- Stanislav Malyshev, Zend Software Architect [EMAIL PROTECTED] http://www.zend.com/ (408)253-8829 MSN: [EMAIL PROTECTED] -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Inconsistencies in 5.3
On 14.08.2008, at 00:09, Lukas Kahwe Smith wrote: On 13.08.2008, at 22:18, Stanislav Malyshev wrote: Simply include a script from two locations with different namespaces or one with namespace and the otherone without. I'm afraid you misunderstand how namespaces work. As I explained numerous times, namespaces are file-local, and this when including file, it does not matter a bit what was including context. I think Marcus is talking about files that are included that do not specify a namespace explicitly. In this situation the context does matter. We do not know if the developer in question is aware that the context would matter in this case. Actually like I said in a previous email it would be nice to at least not throw a warning if the file that is included specifies an explicit namespace (I assume that is possible?). Maybe adding a new include is a solution. This way developers can say explicitly what they want to do without having to suppress the warning. Then again quickly some smartass developer is going to teach people that these annoying warnings go away if you just use this new include everywhere. Then again, I am not sure if I even have my head wrapped around this entire namespace thing. So one more thing. If people either explicitly require all their files up front or make use of a properly designed autoload scheme, they will side step this problem. So maybe the solution indeed is to have this warning with a link to guidelines on how to do this properly. With explicit upfront requires and autoload, there is no need to have includes inside classes, except for the scenario of a template engine. Not sure about that one .. regards, Lukas Kahwe Smith [EMAIL PROTECTED] -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Inconsistencies in 5.3
Hi! So one more thing. If people either explicitly require all their files up front or make use of a properly designed autoload scheme, they will side step this problem. So maybe the solution indeed is to have this Which this problem? There's no problem there! warning with a link to guidelines on how to do this properly. With explicit upfront requires and autoload, there is no need to have includes inside classes, except for the scenario of a template engine. Not sure about that one .. Include inside classes work just fine. -- Stanislav Malyshev, Zend Software Architect [EMAIL PROTECTED] http://www.zend.com/ (408)253-8829 MSN: [EMAIL PROTECTED] -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Inconsistencies in 5.3
Lukas Kahwe Smith wrote: On 13.08.2008, at 22:18, Stanislav Malyshev wrote: Simply include a script from two locations with different namespaces or one with namespace and the otherone without. I'm afraid you misunderstand how namespaces work. As I explained numerous times, namespaces are file-local, and this when including file, it does not matter a bit what was including context. I think Marcus is talking about files that are included that do not specify a namespace explicitly. In this situation the context does matter. We do not know if the developer in question is aware that the context would matter in this case. Actually like I said in a previous email it would be nice to at least not throw a warning if the file that is included specifies an explicit namespace (I assume that is possible?). Maybe adding a new include is a solution. This way developers can say explicitly what they want to do without having to suppress the warning. Then again quickly some smartass developer is going to teach people that these annoying warnings go away if you just use this new include everywhere. Then again, I am not sure if I even have my head wrapped around this entire namespace thing. Hi, Currently, if you include a file within a class method that contains function definitions, they remain functions outside the class. If you include a file that contains a class. In short, only global cpde is executed in the scope, and there is no precedent in PHP to redefine re-usable elements based on scope. Why would namespaces be any different? This whole argument makes no sense to me. Greg -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Inconsistencies in 5.3
Gregory Beaver wrote: Lukas Kahwe Smith wrote: On 13.08.2008, at 22:18, Stanislav Malyshev wrote: Simply include a script from two locations with different namespaces or one with namespace and the otherone without. I'm afraid you misunderstand how namespaces work. As I explained numerous times, namespaces are file-local, and this when including file, it does not matter a bit what was including context. I think Marcus is talking about files that are included that do not specify a namespace explicitly. In this situation the context does matter. We do not know if the developer in question is aware that the context would matter in this case. Actually like I said in a previous email it would be nice to at least not throw a warning if the file that is included specifies an explicit namespace (I assume that is possible?). Maybe adding a new include is a solution. This way developers can say explicitly what they want to do without having to suppress the warning. Then again quickly some smartass developer is going to teach people that these annoying warnings go away if you just use this new include everywhere. Then again, I am not sure if I even have my head wrapped around this entire namespace thing. Hi, Currently, if you include a file within a class method that contains function definitions, they remain functions outside the class. If you include a file that contains a class. In short, only global cpde is executed in the scope, and there is no precedent in PHP to redefine re-usable elements based on scope. Why would namespaces be any different? This whole argument makes no sense to me. Well, it depends how you view the scope. If you include a file that defines a variable from within a function or a method, that variable becomes function-scoped, not global. In the case of a namespaced function or method including a file containing functions or classes, those classes become global. That has, of course, always been the case, but we haven't had the concept of a namespace context before and we haven't had anything that was file-scoped like this. So people might extrapolate from the function-context case to this and assume the wrong thing. That's what Marcus' patch it about. I happen to disagree with him and I think we should just write really good docs explaining how namespaces work and provide a lot of examples. -Rasmus -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Inconsistencies in 5.3
On 14.08.2008, at 00:54, Rasmus Lerdorf wrote: Gregory Beaver wrote: Lukas Kahwe Smith wrote: On 13.08.2008, at 22:18, Stanislav Malyshev wrote: Simply include a script from two locations with different namespaces or one with namespace and the otherone without. I'm afraid you misunderstand how namespaces work. As I explained numerous times, namespaces are file-local, and this when including file, it does not matter a bit what was including context. I think Marcus is talking about files that are included that do not specify a namespace explicitly. In this situation the context does matter. We do not know if the developer in question is aware that the context would matter in this case. Actually like I said in a previous email it would be nice to at least not throw a warning if the file that is included specifies an explicit namespace (I assume that is possible?). Maybe adding a new include is a solution. This way developers can say explicitly what they want to do without having to suppress the warning. Then again quickly some smartass developer is going to teach people that these annoying warnings go away if you just use this new include everywhere. Then again, I am not sure if I even have my head wrapped around this entire namespace thing. Hi, Currently, if you include a file within a class method that contains function definitions, they remain functions outside the class. If you include a file that contains a class. In short, only global cpde is executed in the scope, and there is no precedent in PHP to redefine re-usable elements based on scope. Why would namespaces be any different? This whole argument makes no sense to me. Well, it depends how you view the scope. If you include a file that defines a variable from within a function or a method, that variable becomes function-scoped, not global. In the case of a namespaced function or method including a file containing functions or classes, those classes become global. That has, of course, always been the case, but we haven't had the concept of a namespace context before and we haven't had anything that was file-scoped like this. So people might extrapolate from the function-context case to this and assume the wrong thing. That's what Marcus' patch it about. I happen to disagree with him and I think we should just write really good docs explaining how namespaces work and provide a lot of examples. My previous comments were wrong. Sorry about causing confusion. As Rasmus points out what Marcus is trying to solve with the warning is the false expectation that something that is included in a namespace would also be namespaced. This is not the case. As such if you want the included code to be in some namespace you have to explicitly do so in the file that is being included. As such I also agree that we do not need a warning. It will do at least as much harm to legitimate uses as it tries to solve for illegitimate uses. And those problematic users will hopefully decide to read out docs .. regards, Lukas Kahwe Smith [EMAIL PROTECTED] -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Inconsistencies in 5.3
I read parts of the thread and I'm curious about a situation that
seems Marcus' patch will deny.
It seems that it'll be denied the possibility to require/include a
file inside of a method of a class/function inside a namespace.
Now I need to bring a situation where maybe Doctrine will implement.
We may have the namespace Doctrine and inside of it a function or
maybe a method called autoload. This one will be linked with
spl_register_autoload.
This method actually includes a file on script and since the autoload
is inside namespace Doctrine and the file included may be part of
namespace Doctrine::XXX::YYY, how will it work?
It seems Marcus' patch denies this possibility.
I review the earlier implementations of namespace support, but now I'm
curious what's the real issue with namespaces and included files.
Please, please please, that's not a flaming discussion. I just want to
have things clear in my head why this design decision was taken.
IMHO, if I have something like:
namespace Doctrine {
function autoload($class) { include 'Doctrine/Orm/Entity.php'; }
}
And...:
namespace Doctrine::Orm {
class Entity { ... }
}
The included file should have 2 different possibilities of being processed:
1- It is called in global scope, so it'll be able to Doctrine::Orm::Entity
2- It is called in local scope. This is something that would be
awesome, but would lead compilers crazy. How?
The example:
namespace Doctrine {
function autoload($class) { include 'Doctrine/Orm/Entity.php'; }
}
And...:
namespace Orm
{
class Entity { ... }
}
And since include was done inside Doctrine namespace, it'd be
accessible through Doctrine::Orm::Entity.
This would lead after some time into a newer request of users...
namespace Foo {
namespace Bar {
class Baz { ... }
}
}
// Acess as Foo::Bar::Baz
Or even:
namespace Foo::Bar {
namespace Baz::Wee {
class Blah { ... }
}
}
// Acess as Foo::Bar::Baz::Wee:Blah
In this situation, if you separate (using the last example), you could
do a simply:
namespace Foo::Bar {
include 'Baz/Wee.php';
}
And it should result the same thing as my example.
Please notice I do not want to start a why not use my syntax. I want
answers what can be accomplish, what cannot be accomplished and why
things are possible/impossible.
Lukas knows more than anyone else that we from Doctrine team are
expecting 5.3 to be a God master in namespace and waiting for a full
scope to be defined (and win release work) to start to port our code.
Thanks in advance,
Cheers,
On Wed, Aug 13, 2008 at 8:00 PM, Lukas Kahwe Smith [EMAIL PROTECTED] wrote:
On 14.08.2008, at 00:54, Rasmus Lerdorf wrote:
Gregory Beaver wrote:
Lukas Kahwe Smith wrote:
On 13.08.2008, at 22:18, Stanislav Malyshev wrote:
Simply include a script from two locations with different namespaces
or one
with namespace and the otherone without.
I'm afraid you misunderstand how namespaces work. As I explained
numerous times, namespaces are file-local, and this when including
file, it does not matter a bit what was including context.
I think Marcus is talking about files that are included that do not
specify a namespace explicitly. In this situation the context does
matter.
We do not know if the developer in question is aware that the context
would matter in this case. Actually like I said in a previous email it
would be nice to at least not throw a warning if the file that is
included specifies an explicit namespace (I assume that is possible?).
Maybe adding a new include is a solution. This way developers can say
explicitly what they want to do without having to suppress the warning.
Then again quickly some smartass developer is going to teach people that
these annoying warnings go away if you just use this new include
everywhere. Then again, I am not sure if I even have my head wrapped
around this entire namespace thing.
Hi,
Currently, if you include a file within a class method that contains
function definitions, they remain functions outside the class. If you
include a file that contains a class.
In short, only global cpde is executed in the scope, and there is no
precedent in PHP to redefine re-usable elements based on scope.
Why would namespaces be any different? This whole argument makes no
sense to me.
Well, it depends how you view the scope. If you include a file that
defines a variable from within a function or a method, that variable becomes
function-scoped, not global. In the case of a namespaced function or method
including a file containing functions or classes, those classes become
global. That has, of course, always been the case, but we haven't had the
concept of a namespace context before and we haven't had anything that was
file-scoped like this. So people might extrapolate from the
function-context case to this and assume the wrong thing. That's what
Marcus' patch it about.
I happen to disagree with him and I think we should just write really
Re: [PHP-DEV] Inconsistencies in 5.3
On Wednesday 13 August 2008 6:00:21 pm Lukas Kahwe Smith wrote: Currently, if you include a file within a class method that contains function definitions, they remain functions outside the class. If you include a file that contains a class. In short, only global cpde is executed in the scope, and there is no precedent in PHP to redefine re-usable elements based on scope. Why would namespaces be any different? This whole argument makes no sense to me. Well, it depends how you view the scope. If you include a file that defines a variable from within a function or a method, that variable becomes function-scoped, not global. In the case of a namespaced function or method including a file containing functions or classes, those classes become global. That has, of course, always been the case, but we haven't had the concept of a namespace context before and we haven't had anything that was file-scoped like this. So people might extrapolate from the function-context case to this and assume the wrong thing. That's what Marcus' patch it about. I happen to disagree with him and I think we should just write really good docs explaining how namespaces work and provide a lot of examples. My previous comments were wrong. Sorry about causing confusion. As Rasmus points out what Marcus is trying to solve with the warning is the false expectation that something that is included in a namespace would also be namespaced. This is not the case. As such if you want the included code to be in some namespace you have to explicitly do so in the file that is being included. As such I also agree that we do not need a warning. It will do at least as much harm to legitimate uses as it tries to solve for illegitimate uses. And those problematic users will hopefully decide to read out docs .. regards, Lukas Kahwe Smith [EMAIL PROTECTED] From a developer perspective, I do not expect the code's namespace to be dependent on how it's included either. Especially with the non-braces syntax implemented currently, and the way includes of files with function/class definitions work now, I expect them to be globally defined, which is what happens. I would also note that include up front and have a good autoload scheme works great if you are writing all classes. If you're trying to use namespaces and functions, there is no autoload. That makes the autoload argument moot, and pre-loading everything up front can get ridiculously expensive in large systems, and even then you don't always know what to load up front. (Think anything that accepts plugins.) So an answer of well if it throws a warning when you do that, don't do that is simply not realistic in practice. -- Larry Garfield [EMAIL PROTECTED] -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Inconsistencies in 5.3
Larry Garfield wrote: I would also note that include up front and have a good autoload scheme works great if you are writing all classes. If you're trying to use namespaces and functions, there is no autoload. That makes the autoload argument moot, and pre-loading everything up front can get ridiculously expensive in large systems, and even then you don't always know what to load up front. (Think anything that accepts plugins.) So an answer of well if it throws a warning when you do that, don't do that is simply not realistic in practice. With an opcode cache, it is actually often more efficient to load everything up front even if you aren't using it all on any given request. By using autoload or other conditional mechanisms you lose the function and class caching mechanism provided by the opcode cache because you have now pushed the creation of these to the executor instead of letting the opcode cache cache them for you. And assuming your include_path setting and your include hierachy is clean so you don't have any or at least only minimal per-include stat overhead, whether you include 1 or 20 files on a request isn't a big deal since they are all going to be in memory anyway. -Rasmus -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Inconsistencies in 5.3
Hello everybody,
Am Dienstag, den 12.08.2008, 03:04 +0200 schrieb Etienne Kneuss:
[...]
To me
namespace A {
code
}
namespace B {
code
}
code
seems equivalent to
namespace A;
code
namespace B;
code
namespace none;
code
Only nicer. And I can hardly how it's going to cause more problems?
But if that's so, fine.
[...]
Just one thing: we developed around 50.000 lines of code with the
current namespace syntax and it was neither confusing nor inconsistent
to use. I'm very happy with the current syntax and I would like to just
leave it as it is.
Also I'm really against the curly braces: the issue is, that we would
indent the single class in the file then as otherwise the sense of
braces would be caricatured: we indent to make sure we can easily
distinguish control structures. But if we indent the content of a
namespace, we will have less characters until the magic 80-100 character
border and therefore we will have linebreaks in conditions which makes
them hard to read.
cu, Lars
signature.asc
Description: Dies ist ein digital signierter Nachrichtenteil
Re: [PHP-DEV] Inconsistencies in 5.3
Hello Lars,
Tuesday, August 12, 2008, 8:50:16 AM, you wrote:
Hello everybody,
Am Dienstag, den 12.08.2008, 03:04 +0200 schrieb Etienne Kneuss:
[...]
To me
namespace A {
code
}
namespace B {
code
}
code
seems equivalent to
namespace A;
code
namespace B;
code
namespace none;
code
Only nicer. And I can hardly how it's going to cause more problems?
But if that's so, fine.
[...]
Just one thing: we developed around 50.000 lines of code with the
current namespace syntax and it was neither confusing nor inconsistent
to use. I'm very happy with the current syntax and I would like to just
leave it as it is.
Also I'm really against the curly braces: the issue is, that we would
indent the single class in the file then as otherwise the sense of
braces would be caricatured: we indent to make sure we can easily
distinguish control structures. But if we indent the content of a
namespace, we will have less characters until the magic 80-100 character
border and therefore we will have linebreaks in conditions which makes
them hard to read.
So you are saying that the current namespace is not a control structure?
And you are also saying that we are python where whitespace has a
semantical and syntactical meaning? I am sorry but I have written hundreds
of thousands of lines of C++ code and read even more and hardly anyone uses
indentation, simply because it has no additional meaning.
And if 80 chars still is an issue for you, then I'd suggest to get a decent
monitor.
Best regards,
Marcus
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Inconsistencies in 5.3
Hello Stanislav, Tuesday, August 12, 2008, 2:45:12 AM, you wrote: Hi! 3. You want another namespace, just write namespace again. No, that's not for kids to play with. That's grown-up stuff. Rated X. LOL, That pretty much defeats the whole KISS approach. I suggest we drop that after all then. 4. You got lost after the 10th namespace? Welcome to if-else nesting Get your hands away from the keyboard and re-read the part about not using multiple namespaces per file :) If not convincing - stop using namespaces until it is :) That 'not use it then' has always and every single time in the past let us to drop the feature in question. Some coding style guides force curly braces for if-else for a reason. If you know what coding style means you are not using multiple namespaces per file anyway. If you don't - well, then all bets are off :) Personally I wouldn't without curly braces but that doesn't mean other people would. And at the moment we are discussing what we want people to be able to. And we look at past experience from our own with languages we have used and other experience we have made. Hoping that way we can decide on something reasonable for our large user base. Best regards, Marcus -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Inconsistencies in 5.3
Hello Marcus, Am Dienstag, den 12.08.2008, 11:43 +0200 schrieb Marcus Boerger: [...] So you are saying that the current namespace is not a control structure? It is, yes. But it is somewhat special (I'm having a hard time to explain that better, sorry). This being special is well-expressed with the declarative style of the current namespace definition. [...] And if 80 chars still is an issue for you, then I'd suggest to get a decent monitor. From typography we all know, that human brains (of course except those really genius brains) have a hard time grasping more than 80 characters in one line (density and so on). Just in case you wondered why your newspaper has columns as a layout element. But that's probably OT. cu, Lars signature.asc Description: Dies ist ein digital signierter Nachrichtenteil
Re: [PHP-DEV] Inconsistencies in 5.3
Not so lately I read an article about compacting library files into one big
file and with opcode cache it gave 22 times faster aplication load.
Article is in russian, so thouse who can read it be my guest:
http://dklab.ru/chicken/nablas/49.html
For others I will make a quick summary.
What was taken: PHP, eAccelerator Zend Framework.
First testing case:
He took full Zend Framework package and did next thing
function __autoload($className) {
$fname = str_replace('_', '/', $className) . '.php';
$result = require_once($fname);
return $result;
}
// Include classes one by one
class_exists('Zend_Acl_Assert_Interface');
class_exists('Zend_Acl_Exception');
class_exists('Zend_Acl_Resource_Interface');
class_exists('Zend_Acl_Resource');
// and other 790 files like this
Totals:
Without eAccelerator: 911 ms
With eAccelerator: 435 ms
Now he made one big file 4.9 MB in size and included it with one
require_once call:
without eAccelerator: 458 ms
with eAccelerator: 42 ms
So we got a realy big performance boost. Although it is a little
sintetic, but in reality any big enought project will end up in
loading ~40-50 files in megabytes of code. Concatenating thouse
libraries in one file can give very big boost. And rememver,
eAccelerator isn't the fastest opcode cacher - APC and XCache are even
faster.
So my point is that multiple namespaces per file should be allowed.
Also it would be good idea to allow non namespaced code too, because
sometimes you have a few super global tiny functions, with you need
everythere and putting them into namespace is bad idea. Let the people
decide if they want to make a mess or not, because they will find a
way to make a total mess anyway! Let programmers like myself to feel
free.
P.S. I don't understand the people complaining about one more
whitespace - just don't put it if you don't like it. As of me, I earn
enough money to spend 200-300$ on good 19 LCD. Or you will start to
get complains from people coding in command line in vim that they
can't code normaly because they have only 80 symbols per line!
Re: [PHP-DEV] Inconsistencies in 5.3
Hi!
namespace A {
code
}
namespace B {
code
}
code
seems equivalent to
Again, my point exactly. The above construction - which {} syntax
encourages you to use - should never be used at all!
My point is that if we are going to allow multiple namespaces per file
solely on the perspective of permitting packaging, we should also
allow mixing namespaced and non-namespaced code for that same
perspective, and the current syntax is not going to allow that.
Why should we? I don't think we should. Yet less we should encourage it.
In fact, I already regret we allowed it in first place - despite dozens
of explanations, even the members of the core PHP team seem to be unable
to understand seemingly simple concept that this is to be used only for
packaging. Somehow the idea that it is the preferred way to use
namespaces seems to be one many people are stuck to. So what happens
when they start educating other users - I'm afraid to imagine. I suspect
this feature would be abused on the large scale.
--
Stanislav Malyshev, Zend Software Architect
[EMAIL PROTECTED] http://www.zend.com/
(408)253-8829 MSN: [EMAIL PROTECTED]
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Inconsistencies in 5.3
Hi! So you are saying that the current namespace is not a control structure? Simple fact is that is is not. It doesn't even exist at runtime, so it hardly can control execution. And you are also saying that we are python where whitespace has a semantical and syntactical meaning? I am sorry but I have written hundreds of thousands of lines of C++ code and read even more and hardly anyone uses indentation, simply because it has no additional meaning. As I said, PHP is not exactly C++, so while I respect your perspective as C++ programmer, I think it is important to understand that most PHP users didn't actually write thousands of lines of C++ code and thus would have different perspective, for them it isn't the more like C++, the better. -- Stanislav Malyshev, Zend Software Architect [EMAIL PROTECTED] http://www.zend.com/ (408)253-8829 MSN: [EMAIL PROTECTED] -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Inconsistencies in 5.3
Hi! LOL, That pretty much defeats the whole KISS approach. I suggest we drop that after all then. PHP always had some areas that are not as simple as others (references for one). Maybe we should just close the project and go play Tetris? That's very unproductive position - do it as I want or remove it. I think it would be just insane to drop perfectly working, much needed and announced feature - because Marcus Boerger doesn't like the looks of the syntax. I don't understand how we even could discuss it here. That 'not use it then' has always and every single time in the past let us to drop the feature in question. That's bullshit. Each feature has the right way to use it and wrong ways. If we drop each feature that can be misused, we won't have any features left. -- Stanislav Malyshev, Zend Software Architect [EMAIL PROTECTED] http://www.zend.com/ (408)253-8829 MSN: [EMAIL PROTECTED] -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Inconsistencies in 5.3
Hi, I am sorry, but I cannot keep up with this thread. Is anyone even presenting novel arguments? This is why I asked for a vote and not more discussion. I guess my mistake was for asking for a summary. regards, Lukas Kahwe Smith [EMAIL PROTECTED] -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Inconsistencies in 5.3
Hello Marcus,
Tuesday, August 12, 2008, 3:36:36 PM, you wrote:
Hello Etienne,
Tuesday, August 12, 2008, 3:04:48 AM, you wrote:
Hello,
On Tue, Aug 12, 2008 at 2:39 AM, Stanislav Malyshev [EMAIL PROTECTED]
wrote:
Hi!
but if the {} syntax is introduced, it will be made to affect only the
code inside it, right? If so, I fail to see your point, since the new
syntax will solve that problem.
While introducing a whole collection of new problems - such as that we will
have now split scope, that you can get in and out many times in the same
file. As we discussed on the list many times, it's not exactly what we want
and definitely not the use case it was designed for. I don't see any use for
it besides promoting bad coding practices.
To me
namespace A {
code
}
namespace B {
code
}
code
seems equivalent to
namespace A;
code
namespace B;
code
namespace none;
code
Only nicer. And I can hardly how it's going to cause more problems?
But if that's so, fine.
My point is that if we are going to allow multiple namespaces per file
solely on the perspective of permitting packaging, we should also
allow mixing namespaced and non-namespaced code for that same
perspective, and the current syntax is not going to allow that.
I'd really like the {} syntax if multiple namespaces per file is
allowed. If it's not, then it's not much more than syntactic sugar and
I couldn't care less.
Exact same reasoning here. Now, I want to follow up with two things:
I) personal recent encounters
II) collection of argumenmts
III) personal preference
IV) what to do next
I) personal recent encounters
Technically it is pretty easy to come up with parser/lexer changes that
allow anything you want. Starting from real parser support for only one
namespace as the first statement per file down to muliple nested
namespaces after some initial code outside any namespace as in global,
patch for that attached. It does not include zend_language_scanner.c
and is not fully functionally. it just allows getting a feeling for
namespaces with curlies and and a potential limitationt to have non
namespaces code only prior to the first namespace keyword. Also it
could be done much easier but I wanted the extended info stuff the way
it is.
At the end of the day my biggest issues her are:
1) Namespaces without curly braces and concatenation of files lead to
difference code behavior.
I am not saying that curly braces would solve this fully per se, as you
could still use include/require statements. My point is rather that we
do not addredss this issue at all right now.
And btw, with curly braces we could at least disallow include/require
inside namespaces. Just as we don't allow include/require in classes
outside methods.
2) When we allow multiple namespaces per file for concatenation, then
why do we not allow code outside of namespaces. Because sooner or
later we want that too. We would want that for the exact reason we
want to have multiple namespaces today - concatenation of files.
However without curly braces we can never concatenate files with code
outside namespaces.
3) We are moving in the wrong direction here. Instead of keeping the
language easy we make it more complex to understand and deal with. And
the biggest reasons brought up so far are, circled around
- concatenation for speed
- whitespace
- which other language we relate to
I am really sorry for having to keep this running, but we are running
into somethign extremely bad. And it doesn't even work out in the long
run.
Another example. Remember when we first introduced cli? We thought of
adding a new file type that wouldn't need PIs (?php...?). We luckily
decided against that idea to keep the language easy. Without curlies we
will sooner or later be in a situation where there are two kinds of php
files. Those with namespaces and those without and they wouldn't be
able to cooperate.
II) collection of argumenmts
Let me try to summarize up to this point. The following options have been
outlined and discussed in more detail:
1) Kepp all as is: multiple 'namespace' declarations per file, no {}
+ For some people this means no additional whitespace (other people do
not have this issue, yet counted as +)
0 No direct nesting support (some like it, some don't)
0 Looks and feels more or less like Java packages
0 Original namespaces in pre 5.0beta had curlies
0 Is different from C++'s namespaces so it should look different,
more in: http://news.php.net/php.internals/39838
- Indirect nesting (only): php -r 'namespace foo; namespace foo::bar;'
- Like Java but allows multiple per file and has different keyword
- Multiple namespaces per file as a hack that is not meant to be used
- Two types of scripts, those with and those without namespaces, which
also prevents concatenation as a general solution if one file has
global code
- A file included in a namespaced method is not in that
Re: [PHP-DEV] Inconsistencies in 5.3
On 03.08.2008, at 14:26, Marcus Boerger wrote: 1) new keyword 'use'. Semantically it is the same as 'static' or 'global' so it should be used in the same location. 2) namespaces, either use 'package' and only one per file, or use 'namespace' with curly braces. Read this as be consistent with other languages and even if one or two people do not like it the two main languages out there which have it are Java which goes with the former and C++ which does the latter. Please chose and not mix it. Also our mix is a nightmare when developing code. If we feel we have to keep the keyword 'namesapce' but cannot have curly braces, than I suggest we disallow multiple namespace per file. And there is no technical reason and surely no other reason whatsoever to not have curly braces. If there is then we either fix that or went with the wrong approach. 3) __invokable, see Etiene's mail AFAIK 3) is resolved? So it seems to me like 1) and 2) have gone back and forth between people enough. We have also agreed that multiple namespaces per file are a necessary feature to support. But now the question is if we are going to change anything or not. Ideally someone would summarize the discussion (or maybe two people, one from each camp) and then we can have a vote. Make it an RFC or whatever. But this is definitely the last time we are going to vote on the curly brackets stuff for namespaces in 5.3. regards, Lukas Kahwe Smith [EMAIL PROTECTED] -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Inconsistencies in 5.3
Hi!
Ideally someone would summarize the discussion (or maybe two people, one
from each camp) and then we can have a vote. Make it an RFC or
OK, here it goes again:
When we adopt some syntax, especially syntax matching some other
language, we do not just introduce an otherwise meaningless sequence of
symbols to be learned by users. We introduce concepts, and we create
associative links with other languages. So, if we introduced the syntax
for namespaces that is used by C++ - i.e. braces, we would imply that it
has all the properties that C++ one has and that we encourage the usage
patterns that C++ users adopt. Namely, that namespaces can be nested,
that they are hierarchical, that namespaces can be used in any place in
the file, just for one function/class or even variable without any
influence on the surroundings, that using multiple namespaces in the
same file, along with global space, is completely OK.
However, the usage that we want to promote in PHP is very different - we
want to encourage users to use one namespace per file (except for number
of hacks that basically pack multiple logical files into one physical
file), that namespace is to encompass big structured pieces of code and
not to be used in random in-and-out fashion.
Added to that, braced namespaces would imply additional (and
unnecessary) level of hierarchy and indentation for most editors and
code formatters. Of course, special exception can be programmed into
them to make namespace{} behave in a different way from all other
constructs having {} blocks, but this would be working on solving the
problem that we ourselves created, quite unnecessarily.
With all that, there's not one thing that syntax with {} enables us to
do and that is not possible to do right now (and that we want to do :).
Only reason presented for this change is the misguided notion of
consistency, grounded in the belief that semantically different
constructs must look the same, because that way they will be... well,
consistent. While similarity in function in many cases should produce
similarity in looks, I believe there's substantial semantic difference
between namespaces and classes or functions, enough to make them use
different syntax, especially when it better fits the function namespaces
are to serve in PHP.
--
Stanislav Malyshev, Zend Software Architect
[EMAIL PROTECTED] http://www.zend.com/
(408)253-8829 MSN: [EMAIL PROTECTED]
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Inconsistencies in 5.3
On 11/08/2008, Stanislav Malyshev [EMAIL PROTECTED] wrote:
Hi!
Ideally someone would summarize the discussion (or maybe two people, one
from each camp) and then we can have a vote. Make it an RFC or
OK, here it goes again:
When we adopt some syntax, especially syntax matching some other
language, we do not just introduce an otherwise meaningless sequence of
symbols to be learned by users. We introduce concepts, and we create
associative links with other languages. So, if we introduced the syntax
for namespaces that is used by C++ - i.e. braces, we would imply that it
has all the properties that C++ one has and that we encourage the usage
patterns that C++ users adopt. Namely, that namespaces can be nested,
that they are hierarchical, that namespaces can be used in any place in
the file, just for one function/class or even variable without any
influence on the surroundings, that using multiple namespaces in the
same file, along with global space, is completely OK.
So why the $%#$% can't we use package if the implementation has
nothing incommon with namespaces in c++ (your example, not mine)?
Added to that, braced namespaces would imply additional (and
unnecessary) level of hierarchy and indentation for most editors and
code formatters.
[snip]
With all that, there's not one thing that syntax with {} enables us to
do and that is not possible to do right now (and that we want to do :).
Well. I do want that indentation if I ever will be dumb enough to have
multiple namespace in the same file..
There is only one thing I could care less about than consistency, and
that is Windows.
Its not about consistency for me. Its about that little gut feeling you have.
To me it looks, and feels, much more like a namespace when you wrap it
in a namespace block. To me its more natural syntax.
-Hannes
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Inconsistencies in 5.3
Stanislav Malyshev wrote:
When we adopt some syntax, especially syntax matching some other
language, we do not just introduce an otherwise meaningless sequence of
symbols to be learned by users. We introduce concepts, and we create
associative links with other languages. So, if we introduced the syntax
for namespaces that is used by C++ - i.e. braces, we would imply that it
has all the properties that C++ one has and that we encourage the usage
patterns that C++ users adopt. Namely, that namespaces can be nested,
that they are hierarchical, that namespaces can be used in any place in
the file, just for one function/class or even variable without any
influence on the surroundings, that using multiple namespaces in the
same file, along with global space, is completely OK.
Except that C++ is not the only language that uses this syntax, nor is
it the only language with baggage associated with syntax - to say that
I don't want braces because people would think it acts like C++ is as
silly as saying I don't want the current namespace Foo; syntax because
people will think it acts like python
The bottom line is this is new for PHP, and although there will be
confusion when it's first introduced (goodness, PHP5 had plenty of
teaching over __construct) eventually with good documentation people
will learn what to expect from the PHP version - and that it is not like
Java/C++/C#/Python/whatever
snip
With all that, there's not one thing that syntax with {} enables us to
do and that is not possible to do right now (and that we want to do :).
Only reason presented for this change is the misguided notion of
consistency, grounded in the belief that semantically different
constructs must look the same, because that way they will be... well,
consistent.
Thinking as a new user...
How is
namespace foo;
semantically different from
class foo {}
or even
function foo {}
I'm defining something yes? With stuff basically inside it. Yes an
oversimplification, but the strength of PHP has always been simple. So
why should it act differently? Why does it need different syntax to
define something?
While similarity in function in many cases should produce
similarity in looks, I believe there's substantial semantic difference
between namespaces and classes or functions, enough to make them use
different syntax, especially when it better fits the function namespaces
are to serve in PHP.
And here is the difference - I don't believe there's substantial
semantic difference between namespaces or classes or functions, enough
to require teaching a new syntax.
But at the end of the day this is all personal preference. Just
remember the poor people who have to teach this to the new users ;)
Thanks,
Elizabeth Smith
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Inconsistencies in 5.3
[EMAIL PROTECTED] escreveu:
On 11/08/2008, Stanislav Malyshev [EMAIL PROTECTED] wrote:
Hi!
Ideally someone would summarize the discussion (or maybe two people, one
from each camp) and then we can have a vote. Make it an RFC or
OK, here it goes again:
When we adopt some syntax, especially syntax matching some other
language, we do not just introduce an otherwise meaningless sequence of
symbols to be learned by users. We introduce concepts, and we create
associative links with other languages. So, if we introduced the syntax
for namespaces that is used by C++ - i.e. braces, we would imply that it
has all the properties that C++ one has and that we encourage the usage
patterns that C++ users adopt. Namely, that namespaces can be nested,
that they are hierarchical, that namespaces can be used in any place in
the file, just for one function/class or even variable without any
influence on the surroundings, that using multiple namespaces in the
same file, along with global space, is completely OK.
So why the $%#$% can't we use package if the implementation has
nothing incommon with namespaces in c++ (your example, not mine)?
Added to that, braced namespaces would imply additional (and
unnecessary) level of hierarchy and indentation for most editors and
code formatters.
[snip]
With all that, there's not one thing that syntax with {} enables us to
do and that is not possible to do right now (and that we want to do :).
Well. I do want that indentation if I ever will be dumb enough to have
multiple namespace in the same file..
There is only one thing I could care less about than consistency, and
that is Windows.
Its not about consistency for me. Its about that little gut feeling you have.
To me it looks, and feels, much more like a namespace when you wrap it
in a namespace block. To me its more natural syntax.
-Hannes
IMHO it doesn't make sense to have {} around namespaces if PHP
recommends (imposes?) 1 namespace per file. I personally prefer the more
C++-like way, described by Stanislav, where you can do pretty much
anything namespace-wise. But if PHP is sticking to the prior, { } just
looks wrong to me.
--
Rodrigo Saboya
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Inconsistencies in 5.3
Hi!
So why the $%#$% can't we use package if the implementation has
nothing incommon with namespaces in c++ (your example, not mine)?
We could use package or we could use hexaflexagon or we could use
triskaidekaphobia or any other word. But if we have namespace
implementation in PHP, why don't we call it namespace? Because it is
inconsistent with C++? To hell with C++ then, nobody said PHP is C++.
Well. I do want that indentation if I ever will be dumb enough to have
multiple namespace in the same file..
Indentation happens when you do () even once. {} implies that everything
inside it is on next level of hierarchy and thus should be indented.
Of course, it's inconsistent with Python, so maybe we should drop
braces altogether...
Its not about consistency for me. Its about that little gut feeling you have.
Well, of course I can not address little gut feeling with any logical
argument. But to hell with logic and reasoning, let the little gut
feeling rule.
--
Stanislav Malyshev, Zend Software Architect
[EMAIL PROTECTED] http://www.zend.com/
(408)253-8829 MSN: [EMAIL PROTECTED]
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Inconsistencies in 5.3
Hello Stanislav,
Tuesday, August 12, 2008, 12:58:29 AM, you wrote:
Hi!
So why the $%#$% can't we use package if the implementation has
nothing incommon with namespaces in c++ (your example, not mine)?
We could use package or we could use hexaflexagon or we could use
triskaidekaphobia or any other word. But if we have namespace
implementation in PHP, why don't we call it namespace? Because it is
inconsistent with C++? To hell with C++ then, nobody said PHP is C++.
Well. I do want that indentation if I ever will be dumb enough to have
multiple namespace in the same file..
Indentation happens when you do () even once. {} implies that everything
inside it is on next level of hierarchy and thus should be indented.
Of course, it's inconsistent with Python, so maybe we should drop
braces altogether...
Its not about consistency for me. Its about that little gut feeling you have.
Well, of course I can not address little gut feeling with any logical
argument. But to hell with logic and reasoning, let the little gut
feeling rule.
Sorry but you never ever provided any logical reasoning for the current
way. The reasons that were brought up were:
a) JavaScript will have it in some future
- works in the same way as C++ has this or Java that
b) We used to have in our first implementation
- which by the way used curly braces, and the only reason we we dropped it
was because I was outruled by you and Zeev when we encountered the
ternariy ambiguty and noone tought it was fixable even though I said it
was fixable. Sadly I never provided a working patch back then.
c) We said we were adding namespaces at some point, not saying in which way
we would.
Best regards,
Marcus
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Inconsistencies in 5.3
Hi!
I don't want braces because people would think it acts like C++ is as
silly as saying I don't want the current namespace Foo; syntax because
people will think it acts like python
Errr... as far as I know Python has no namespace Foo; syntax. And as I
repeated numerous times, the syntax should be driven primarily by
function, not by what decision some guys (even very smart guys) took
when they designed entirely different language. The function of PHP
namespaces makes {} make little sense, since {} implies bounded (and
potentially nested) scope, that is repeatable and has inside and
outside.
Thinking as a new user...
How is
namespace foo;
semantically different from
class foo {}
or even
function foo {}
1. Namespace is a tag on the entities defined inside this file, function
is not. Class can be viewed as such, kind of, but it'd be very limiting
view (class is more than just tag on set of function names).
2. Class and function exist as stand-alone entity, namespace does not.
3. There can be context outside class/function in this file, but not
outside namespace.
I'm defining something yes? With stuff basically inside it. Yes an
oversimplification, but the strength of PHP has always been simple. So
why should it act differently? Why does it need different syntax to
define something?
Well, it should act differently for the same reason class and function
act differently - because they are different things. ITYM why the
should _look_ differently?. As I said, that is because for them to look
the same would be to imply things about namespaces that are not true.
But at the end of the day this is all personal preference. Just
remember the poor people who have to teach this to the new users ;)
I can help with that. Here's world's shortest course on PHP namespaces:
1. To define namespace for the file, write namespace Foo::Bar; at the
beginning of the file.
2. That's it, enjoy. ;)
--
Stanislav Malyshev, Zend Software Architect
[EMAIL PROTECTED] http://www.zend.com/
(408)253-8829 MSN: [EMAIL PROTECTED]
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Inconsistencies in 5.3
Hi! Sorry but you never ever provided any logical reasoning for the current way. The reasons that were brought up were: It would help the discussion a lot if you actually read my emails. Unfortunately, by now it's clear that you do not. I just wrote a long email outlining the reasons, but I guess reading it would be too much work. a) JavaScript will have it in some future b) We used to have in our first implementation c) We said we were adding namespaces at some point, not saying in which way we would. Sadly, this has nothing to do with my reasoning. -- Stanislav Malyshev, Zend Software Architect [EMAIL PROTECTED] http://www.zend.com/ (408)253-8829 MSN: [EMAIL PROTECTED] -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Inconsistencies in 5.3
Hello,
On Tue, Aug 12, 2008 at 12:58 AM, Stanislav Malyshev [EMAIL PROTECTED] wrote:
Hi!
So why the $%#$% can't we use package if the implementation has
nothing incommon with namespaces in c++ (your example, not mine)?
We could use package or we could use hexaflexagon or we could use
triskaidekaphobia or any other word. But if we have namespace
implementation in PHP, why don't we call it namespace? Because it is
inconsistent with C++? To hell with C++ then, nobody said PHP is C++.
Well. I do want that indentation if I ever will be dumb enough to have
multiple namespace in the same file..
Indentation happens when you do () even once. {} implies that everything
inside it is on next level of hierarchy and thus should be indented.
Of course, it's inconsistent with Python, so maybe we should drop braces
altogether...
I fail to see why { } meaning a different level of hierarchy is a
problem here, that's exactly what it's supposed to mean: code in that
block is affected by that namespace.
We don't expect if's to work until the next if(), do we? Even though
ifs are not entities like classes or functions.
Additionally, I see the packaging argument being raised to advocate
the use of multiple namespaces per file. However, with that syntax,
you can't package namespaced and non namespaced code in the same file
anyway, that sounds to me like a burden and actually a point against
the current syntax.
Its not about consistency for me. Its about that little gut feeling you
have.
Well, of course I can not address little gut feeling with any logical
argument. But to hell with logic and reasoning, let the little gut feeling
rule.
--
Stanislav Malyshev, Zend Software Architect
[EMAIL PROTECTED] http://www.zend.com/
(408)253-8829 MSN: [EMAIL PROTECTED]
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Regards,
--
Etienne Kneuss
http://www.colder.ch
Men never do evil so completely and cheerfully as
when they do it from a religious conviction.
-- Pascal
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Inconsistencies in 5.3
Hi!
I fail to see why { } meaning a different level of hierarchy is a
problem here, that's exactly what it's supposed to mean: code in that
block is affected by that namespace.
Exactly. The thing is that there can be no code that is not affected (at
least not in this file) for namespaces - and {} implies there could be.
We don't expect if's to work until the next if(), do we? Even though
ifs are not entities like classes or functions.
Exactly. That's why it makes sense to have if() with braces - because if
works not until the end of file, but only with the block attached to it,
and after this block ends, it's like there was no if. But namespace
doesn't work this way.
--
Stanislav Malyshev, Zend Software Architect
[EMAIL PROTECTED] http://www.zend.com/
(408)253-8829 MSN: [EMAIL PROTECTED]
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Inconsistencies in 5.3
Hello,
On Tue, Aug 12, 2008 at 2:12 AM, Stanislav Malyshev [EMAIL PROTECTED] wrote:
Hi!
I fail to see why { } meaning a different level of hierarchy is a
problem here, that's exactly what it's supposed to mean: code in that
block is affected by that namespace.
Exactly. The thing is that there can be no code that is not affected (at
least not in this file) for namespaces - and {} implies there could be.
but if the {} syntax is introduced, it will be made to affect only the
code inside it, right? If so, I fail to see your point, since the new
syntax will solve that problem.
We don't expect if's to work until the next if(), do we? Even though
ifs are not entities like classes or functions.
Exactly. That's why it makes sense to have if() with braces - because if
works not until the end of file, but only with the block attached to it, and
after this block ends, it's like there was no if. But namespace doesn't work
this way.
Same as before: but they would work this way with the {} syntax
--
Stanislav Malyshev, Zend Software Architect
[EMAIL PROTECTED] http://www.zend.com/
(408)253-8829 MSN: [EMAIL PROTECTED]
--
Etienne Kneuss
http://www.colder.ch
Men never do evil so completely and cheerfully as
when they do it from a religious conviction.
-- Pascal
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Inconsistencies in 5.3
Hello Stanislav, Tuesday, August 12, 2008, 1:41:08 AM, you wrote: Hi! Sorry but you never ever provided any logical reasoning for the current way. The reasons that were brought up were: It would help the discussion a lot if you actually read my emails. Unfortunately, by now it's clear that you do not. I just wrote a long email outlining the reasons, but I guess reading it would be too much work. a) JavaScript will have it in some future b) We used to have in our first implementation c) We said we were adding namespaces at some point, not saying in which way we would. I just read this from you: We could use package or we could use hexaflexagon or we could use triskaidekaphobia - oh and there was that very polemic pythin argument. Dude I am sorry but ther is no argument at all. Unless your long mail is still on the way. You vary between polemic and spin around arguments reusing them at will. You promise we discuss and never agree too. Sorry but for the namespace discussion that is all that made it to me. And I am sure when I write something hardly anything makes it to you :-) We can just agree to disagree, so it is for others to decide about. That's what Lukas' mail was all about, collecting arguments, actually finding someone to collect and weigh them. And that's why I brought up those three points, because those are the arguments I do remember - apart from tons of mails that had no content at all or somehow got filtered by my incoming mail reading process :-) Best regards, Marcus -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Inconsistencies in 5.3
Hello Stanislav,
Tuesday, August 12, 2008, 1:34:49 AM, you wrote:
Hi!
I don't want braces because people would think it acts like C++ is as
silly as saying I don't want the current namespace Foo; syntax because
people will think it acts like python
Errr... as far as I know Python has no namespace Foo; syntax. And as I
repeated numerous times, the syntax should be driven primarily by
function, not by what decision some guys (even very smart guys) took
when they designed entirely different language. The function of PHP
namespaces makes {} make little sense, since {} implies bounded (and
potentially nested) scope, that is repeatable and has inside and
outside.
Thinking as a new user...
How is
namespace foo;
semantically different from
class foo {}
or even
function foo {}
1. Namespace is a tag on the entities defined inside this file, function
is not. Class can be viewed as such, kind of, but it'd be very limiting
view (class is more than just tag on set of function names).
2. Class and function exist as stand-alone entity, namespace does not.
3. There can be context outside class/function in this file, but not
outside namespace.
I'm defining something yes? With stuff basically inside it. Yes an
oversimplification, but the strength of PHP has always been simple. So
why should it act differently? Why does it need different syntax to
define something?
Well, it should act differently for the same reason class and function
act differently - because they are different things. ITYM why the
should _look_ differently?. As I said, that is because for them to look
the same would be to imply things about namespaces that are not true.
But at the end of the day this is all personal preference. Just
remember the poor people who have to teach this to the new users ;)
I can help with that. Here's world's shortest course on PHP namespaces:
1. To define namespace for the file, write namespace Foo::Bar; at the
beginning of the file.
2. That's it, enjoy. ;)
3. You want another namespace, just write namespace again.
4. You got lost after the 10th namespace? Welcome to if-else nesting
ambiguty all over again.
Some coding style guides force curly braces for if-else for a reason.
Best regards,
Marcus
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Inconsistencies in 5.3
Hi!
but if the {} syntax is introduced, it will be made to affect only the
code inside it, right? If so, I fail to see your point, since the new
syntax will solve that problem.
While introducing a whole collection of new problems - such as that we
will have now split scope, that you can get in and out many times in the
same file. As we discussed on the list many times, it's not exactly what
we want and definitely not the use case it was designed for. I don't see
any use for it besides promoting bad coding practices.
--
Stanislav Malyshev, Zend Software Architect
[EMAIL PROTECTED] http://www.zend.com/
(408)253-8829 MSN: [EMAIL PROTECTED]
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Inconsistencies in 5.3
Hi! triskaidekaphobia - oh and there was that very polemic pythin argument. Dude I am sorry but ther is no argument at all. Unless your long mail is Please ask you sysadmin to fix your mail system, you seem to be losing emails. The email I was referring to please read here: http://news.php.net/php.internals/39838 After that, we can continue discussion to the point, if you wish so. -- Stanislav Malyshev, Zend Software Architect [EMAIL PROTECTED] http://www.zend.com/ (408)253-8829 MSN: [EMAIL PROTECTED] -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Inconsistencies in 5.3
Hi! 3. You want another namespace, just write namespace again. No, that's not for kids to play with. That's grown-up stuff. Rated X. 4. You got lost after the 10th namespace? Welcome to if-else nesting Get your hands away from the keyboard and re-read the part about not using multiple namespaces per file :) If not convincing - stop using namespaces until it is :) Some coding style guides force curly braces for if-else for a reason. If you know what coding style means you are not using multiple namespaces per file anyway. If you don't - well, then all bets are off :) -- Stanislav Malyshev, Zend Software Architect [EMAIL PROTECTED] http://www.zend.com/ (408)253-8829 MSN: [EMAIL PROTECTED] -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Inconsistencies in 5.3
Hello,
On Tue, Aug 12, 2008 at 2:39 AM, Stanislav Malyshev [EMAIL PROTECTED] wrote:
Hi!
but if the {} syntax is introduced, it will be made to affect only the
code inside it, right? If so, I fail to see your point, since the new
syntax will solve that problem.
While introducing a whole collection of new problems - such as that we will
have now split scope, that you can get in and out many times in the same
file. As we discussed on the list many times, it's not exactly what we want
and definitely not the use case it was designed for. I don't see any use for
it besides promoting bad coding practices.
To me
namespace A {
code
}
namespace B {
code
}
code
seems equivalent to
namespace A;
code
namespace B;
code
namespace none;
code
Only nicer. And I can hardly how it's going to cause more problems?
But if that's so, fine.
My point is that if we are going to allow multiple namespaces per file
solely on the perspective of permitting packaging, we should also
allow mixing namespaced and non-namespaced code for that same
perspective, and the current syntax is not going to allow that.
I'd really like the {} syntax if multiple namespaces per file is
allowed. If it's not, then it's not much more than syntactic sugar and
I couldn't care less.
--
Stanislav Malyshev, Zend Software Architect
[EMAIL PROTECTED] http://www.zend.com/
(408)253-8829 MSN: [EMAIL PROTECTED]
--
Etienne Kneuss
http://www.colder.ch
Men never do evil so completely and cheerfully as
when they do it from a religious conviction.
-- Pascal
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Inconsistencies in 5.3
Hi Marcus,
In case you really like this syntax, you can try to implement patch and
propose it to @internals.
I don't like it just because it seems wrong for me, so personally I'll
object your patch.
Thanks. Dmitry.
Marcus Boerger wrote:
Hello Dmitry,
Tuesday, August 5, 2008, 1:28:32 PM, you wrote:
Of course not, but it will be very hard to understand difference and
fix parser conflicts.
How is that hard? we have top_statement and inner_statement in our
parser...problem solved.
Ha, i actually just learned this way that we support inner functions, tsk.
marcus
Thanks. Dmitry.
Marcus Boerger wrote:
Hello Dmitry,
Tuesday, August 5, 2008, 8:38:07 AM, you wrote:
Allowing use inside function body assuming allowing it everywhere.
$x = function($arg) {
if ($arg) {
use $a;
} else {
use $b;
}
};
I don't like such ability and of course we won't be able to use use
keyword as it will conflict with import statement.
So the import statement use can be placed inside the body of a function as
an expression?
Moriyoshi Koizumi wrote:
Dmitry Stogov wrote:
Marcus Boerger wrote:
Hello Dmitry,
Monday, August 4, 2008, 8:55:00 AM, you wrote:
Hi Marcus,
see below
Marcus Boerger wrote:
Hello Internals,
please let's not introduce new inconsistencies. Rather lets make new
stuff consistent with old stuff during the alpha phase of 5.3.
1) new keyword 'use'. Semantically it is the same as 'static' or
'global'
so it should be used in the same location.
For me 'use' is the best keyword as it says that closure uses
variables from current content. (the same keyword is used for import
from namespaces)
To be clear, I wasn't complaining about the keyword per se. I just
prefer
it to be inside the curly braces of a closure next to global rather
than in
front of it.
No. The list of lexical variables is a part of the closure definition.
The earlier implementation had lexical keyword which worked as you
are suggesting, but it was much unclear.
I don't think there are many differences in ambiguity between
$closure = function ($arg) { use $a;
...
};
and
$closure = function ($arg) use ($a) {
};
Moriyoshi
Best regards,
Marcus
Best regards,
Marcus
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Inconsistencies in 5.3
Hello Stanislav, Wednesday, August 6, 2008, 6:42:48 PM, you wrote: Hi! What a nitpicking :) So would I say that the global statement is inconsistent with static because it doesn't allow assignments within the statement :p Sure it is. That's just another thing to show all this consistency talk is blown way out of proportion long ago. Now let's make global accept assignments and ignore them for consistency, should we? So what is your point here? You say we failed a few times to be consistent in the past, so today we should do everything to prevent anything that looks like consistency? Do you read what you write? Best regards, Marcus -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Inconsistencies in 5.3
Hi! So what is your point here? You say we failed a few times to be consistent in the past, so today we should do everything to prevent anything that looks like consistency? Do you read what you write? My point is that changing constructs that work differently to look the same because somebody thinks it should be consistent, whatever that might mean, is pointless. -- Stanislav Malyshev, Zend Software Architect [EMAIL PROTECTED] http://www.zend.com/ (408)253-8829 MSN: [EMAIL PROTECTED] -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Inconsistencies in 5.3
Hello Stanislav,
Wednesday, August 6, 2008, 7:42:29 AM, you wrote:
Hi!
function ($arg) { use $a, $b;
Note that neither static not global allow inside definitions, so from
consistency point of view it doesn't work.
I do not see an argument in complaining about extending a scheme. But I see
the other solution, use in front of the body, as an introduction of a brand
new scheme. Obviously one is very inconsistent. And besides, global could
simply ignore '' as that would have no meaning there at all.
Best regards,
Marcus
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Inconsistencies in 5.3
I think it is good as it is.
Realy, I'd prefer even a change to global like this:
function test ($someparam) global ($someGlobalVariable) {
// code here
}
Or even make it consistent with lamda's and make use of use statment
instead of global.
P.S. I know my comment will be yeald at, so please avoid that so not to
polute the list. Just think a little, maybe it is a good idea.
P.S.S. Sometimes I realy want an ability to define superglobal variables in
some way.
Re: [PHP-DEV] Inconsistencies in 5.3
Stanislav Malyshev wrote:
Hi!
function ($arg) { use $a, $b;
Note that neither static not global allow inside definitions, so from
consistency point of view it doesn't work.
What a nitpicking :) So would I say that the global statement is
inconsistent with static because it doesn't allow assignments within the
statement :p
Moriyoshi
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Inconsistencies in 5.3
Hi! I do not see an argument in complaining about extending a scheme. But I see the other solution, use in front of the body, as an introduction of a brand new scheme. Obviously one is very inconsistent. And besides, global could It will be obviously inconsistent anyway, because it is a new thing, which doesn't work like old things. simply ignore '' as that would have no meaning there at all. So now we should mess with global in order to provide imaginary consistency. Brilliant. -- Stanislav Malyshev, Zend Software Architect [EMAIL PROTECTED] http://www.zend.com/ (408)253-8829 MSN: [EMAIL PROTECTED] -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Inconsistencies in 5.3
Hi! What a nitpicking :) So would I say that the global statement is inconsistent with static because it doesn't allow assignments within the statement :p Sure it is. That's just another thing to show all this consistency talk is blown way out of proportion long ago. Now let's make global accept assignments and ignore them for consistency, should we? -- Stanislav Malyshev, Zend Software Architect [EMAIL PROTECTED] http://www.zend.com/ (408)253-8829 MSN: [EMAIL PROTECTED] -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Inconsistencies in 5.3
Stanislav Malyshev wrote: Hi! What a nitpicking :) So would I say that the global statement is inconsistent with static because it doesn't allow assignments within the statement :p Sure it is. That's just another thing to show all this consistency talk is blown way out of proportion long ago. Now let's make global accept assignments and ignore them for consistency, should we? I'd prefer the opposite way in which no initializers are allowed for static. null type was introduced to mark uninitialized variables in the first place, so if we have strictly kept the original intention, there should be no problem with this idea. (I'd say NULL values from the database or other softwares should have been made effectively differentiable with language-defined null values, but this is another issue) Apart from this, the constructs in question share the same semantics where their role is to define variables that refers to values of a non-local data storage, so making the lexical variable declaration statement look like the others is not inconsistent with the current language syntax, whereas the use construct after the argument list is inconsistent with the ordinary function definition unless my proposal [1] is accepted. [1] http://news.php.net/php.internals/39071 Moriyoshi -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Inconsistencies in 5.3
Hi! language syntax, whereas the use construct after the argument list is inconsistent with the ordinary function definition unless my proposal Because it is _not_ an ordinary function definition. It's like saying '+' is inconsistent with '-' because $a+$b=$b+$a but $a-$b!=$b-$a. I don't have any attachment to any particular syntax in this case, but I am strongly opposed to taking decision on the syntax based on the look of the constructs alone, ignoring underlying semantic differences and all the problems that it would lead to. P.S. btw, in your proposal functions would be inconsistent with methods. -- Stanislav Malyshev, Zend Software Architect [EMAIL PROTECTED] http://www.zend.com/ (408)253-8829 MSN: [EMAIL PROTECTED] -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Inconsistencies in 5.3
Stanislav Malyshev wrote: Hi! language syntax, whereas the use construct after the argument list is inconsistent with the ordinary function definition unless my proposal Because it is _not_ an ordinary function definition. It's like saying '+' is inconsistent with '-' because $a+$b=$b+$a but $a-$b!=$b-$a. Your argument sounds far too extreme. P.S. btw, in your proposal functions would be inconsistent with methods. Should I follow like methods are not functions? or PHP has inconsistent language features. That seems oddly enough. Moriyoshi -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Inconsistencies in 5.3
Allowing use inside function body assuming allowing it everywhere.
$x = function($arg) {
if ($arg) {
use $a;
} else {
use $b;
}
};
I don't like such ability and of course we won't be able to use use
keyword as it will conflict with import statement.
Thanks. Dmitry.
Moriyoshi Koizumi wrote:
Dmitry Stogov wrote:
Marcus Boerger wrote:
Hello Dmitry,
Monday, August 4, 2008, 8:55:00 AM, you wrote:
Hi Marcus,
see below
Marcus Boerger wrote:
Hello Internals,
please let's not introduce new inconsistencies. Rather lets make new
stuff consistent with old stuff during the alpha phase of 5.3.
1) new keyword 'use'. Semantically it is the same as 'static' or
'global'
so it should be used in the same location.
For me 'use' is the best keyword as it says that closure uses
variables from current content. (the same keyword is used for import
from namespaces)
To be clear, I wasn't complaining about the keyword per se. I just
prefer
it to be inside the curly braces of a closure next to global rather
than in
front of it.
No. The list of lexical variables is a part of the closure definition.
The earlier implementation had lexical keyword which worked as you
are suggesting, but it was much unclear.
I don't think there are many differences in ambiguity between
$closure = function ($arg) { use $a;
...
};
and
$closure = function ($arg) use ($a) {
};
Moriyoshi
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Inconsistencies in 5.3
Hello Dmitry,
Tuesday, August 5, 2008, 8:38:07 AM, you wrote:
Allowing use inside function body assuming allowing it everywhere.
$x = function($arg) {
if ($arg) {
use $a;
} else {
use $b;
}
};
I don't like such ability and of course we won't be able to use use
keyword as it will conflict with import statement.
So the import statement use can be placed inside the body of a function as
an expression?
Moriyoshi Koizumi wrote:
Dmitry Stogov wrote:
Marcus Boerger wrote:
Hello Dmitry,
Monday, August 4, 2008, 8:55:00 AM, you wrote:
Hi Marcus,
see below
Marcus Boerger wrote:
Hello Internals,
please let's not introduce new inconsistencies. Rather lets make new
stuff consistent with old stuff during the alpha phase of 5.3.
1) new keyword 'use'. Semantically it is the same as 'static' or
'global'
so it should be used in the same location.
For me 'use' is the best keyword as it says that closure uses
variables from current content. (the same keyword is used for import
from namespaces)
To be clear, I wasn't complaining about the keyword per se. I just
prefer
it to be inside the curly braces of a closure next to global rather
than in
front of it.
No. The list of lexical variables is a part of the closure definition.
The earlier implementation had lexical keyword which worked as you
are suggesting, but it was much unclear.
I don't think there are many differences in ambiguity between
$closure = function ($arg) { use $a;
...
};
and
$closure = function ($arg) use ($a) {
};
Moriyoshi
Best regards,
Marcus
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Inconsistencies in 5.3
Of course not, but it will be very hard to understand difference and
fix parser conflicts.
Thanks. Dmitry.
Marcus Boerger wrote:
Hello Dmitry,
Tuesday, August 5, 2008, 8:38:07 AM, you wrote:
Allowing use inside function body assuming allowing it everywhere.
$x = function($arg) {
if ($arg) {
use $a;
} else {
use $b;
}
};
I don't like such ability and of course we won't be able to use use
keyword as it will conflict with import statement.
So the import statement use can be placed inside the body of a function as
an expression?
Moriyoshi Koizumi wrote:
Dmitry Stogov wrote:
Marcus Boerger wrote:
Hello Dmitry,
Monday, August 4, 2008, 8:55:00 AM, you wrote:
Hi Marcus,
see below
Marcus Boerger wrote:
Hello Internals,
please let's not introduce new inconsistencies. Rather lets make new
stuff consistent with old stuff during the alpha phase of 5.3.
1) new keyword 'use'. Semantically it is the same as 'static' or
'global'
so it should be used in the same location.
For me 'use' is the best keyword as it says that closure uses
variables from current content. (the same keyword is used for import
from namespaces)
To be clear, I wasn't complaining about the keyword per se. I just
prefer
it to be inside the curly braces of a closure next to global rather
than in
front of it.
No. The list of lexical variables is a part of the closure definition.
The earlier implementation had lexical keyword which worked as you
are suggesting, but it was much unclear.
I don't think there are many differences in ambiguity between
$closure = function ($arg) { use $a;
...
};
and
$closure = function ($arg) use ($a) {
};
Moriyoshi
Best regards,
Marcus
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Inconsistencies in 5.3
Hello Dmitry,
Tuesday, August 5, 2008, 1:28:32 PM, you wrote:
Of course not, but it will be very hard to understand difference and
fix parser conflicts.
How is that hard? we have top_statement and inner_statement in our
parser...problem solved.
Ha, i actually just learned this way that we support inner functions, tsk.
marcus
Thanks. Dmitry.
Marcus Boerger wrote:
Hello Dmitry,
Tuesday, August 5, 2008, 8:38:07 AM, you wrote:
Allowing use inside function body assuming allowing it everywhere.
$x = function($arg) {
if ($arg) {
use $a;
} else {
use $b;
}
};
I don't like such ability and of course we won't be able to use use
keyword as it will conflict with import statement.
So the import statement use can be placed inside the body of a function as
an expression?
Moriyoshi Koizumi wrote:
Dmitry Stogov wrote:
Marcus Boerger wrote:
Hello Dmitry,
Monday, August 4, 2008, 8:55:00 AM, you wrote:
Hi Marcus,
see below
Marcus Boerger wrote:
Hello Internals,
please let's not introduce new inconsistencies. Rather lets make new
stuff consistent with old stuff during the alpha phase of 5.3.
1) new keyword 'use'. Semantically it is the same as 'static' or
'global'
so it should be used in the same location.
For me 'use' is the best keyword as it says that closure uses
variables from current content. (the same keyword is used for import
from namespaces)
To be clear, I wasn't complaining about the keyword per se. I just
prefer
it to be inside the curly braces of a closure next to global rather
than in
front of it.
No. The list of lexical variables is a part of the closure definition.
The earlier implementation had lexical keyword which worked as you
are suggesting, but it was much unclear.
I don't think there are many differences in ambiguity between
$closure = function ($arg) { use $a;
...
};
and
$closure = function ($arg) use ($a) {
};
Moriyoshi
Best regards,
Marcus
Best regards,
Marcus
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Inconsistencies in 5.3
On Tuesday 05 August 2008 12:48:37 am Moriyoshi Koizumi wrote:
I don't think there are many differences in ambiguity between
$closure = function ($arg) { use $a;
...
};
and
$closure = function ($arg) use ($a) {
};
Moriyoshi
--
Moriyoshi Koizumi [EMAIL PROTECTED]
The former has no good way to differentiate between by-ref and by-value
importing. The latter has a very intuitive way. That's why (IIRC) it was
used.
--
Larry Garfield
[EMAIL PROTECTED]
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Inconsistencies in 5.3
Larry Garfield wrote:
On Tuesday 05 August 2008 12:48:37 am Moriyoshi Koizumi wrote:
I don't think there are many differences in ambiguity between
$closure = function ($arg) { use $a;
...
};
and
$closure = function ($arg) use ($a) {
};
Moriyoshi
--
Moriyoshi Koizumi [EMAIL PROTECTED]
The former has no good way to differentiate between by-ref and by-value
importing. The latter has a very intuitive way. That's why (IIRC) it was
used.
The only difference I could see between the two is the presence of
parenthesis. I doubt they contribute to the intuitiveness that much.
function ($arg) { use $a, $b;
v.s.
function ($arg) use ($a, $b) {
Moriyoshi
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Inconsistencies in 5.3
Hi!
function ($arg) { use $a, $b;
Note that neither static not global allow inside definitions, so from
consistency point of view it doesn't work.
--
Stanislav Malyshev, Zend Software Architect
[EMAIL PROTECTED] http://www.zend.com/
(408)253-8829 MSN: [EMAIL PROTECTED]
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Inconsistencies in 5.3
Hi Marcus, see below Marcus Boerger wrote: Hello Internals, please let's not introduce new inconsistencies. Rather lets make new stuff consistent with old stuff during the alpha phase of 5.3. 1) new keyword 'use'. Semantically it is the same as 'static' or 'global' so it should be used in the same location. For me 'use' is the best keyword as it says that closure uses variables from current content. (the same keyword is used for import from namespaces) 2) namespaces, either use 'package' and only one per file, or use 'namespace' with curly braces. Read this as be consistent with other languages and even if one or two people do not like it the two main languages out there which have it are Java which goes with the former and C++ which does the latter. Please chose and not mix it. Also our mix is a nightmare when developing code. If we feel we have to keep the keyword 'namesapce' but cannot have curly braces, than I suggest we disallow multiple namespace per file. And there is no technical reason and surely no other reason whatsoever to not have curly braces. If there is then we either fix that or went with the wrong approach. I don't like multiple namespaces per file too. As I remember they were introduced by Greg's request related to ext/phar. May be he already changed his mind. 'package' or 'namespace' is not so important for me. Thanks. Dmitry. 3) __invokable, see Etiene's mail Best regards, Marcus -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Inconsistencies in 5.3
On Mon, Aug 4, 2008 at 08:55, Dmitry Stogov [EMAIL PROTECTED] wrote: I don't like multiple namespaces per file too. As I remember they were introduced by Greg's request related to ext/phar. May be he already changed his mind. I don't think anyone but him likes multiple namespaces per file. I do remember a PhD thesis sized mail from him explaining why multiple namespaces per file was needed though (can hardly believe anyone read the whole thing..). -Hannes -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Inconsistencies in 5.3
Hannes Magnusson schrieb: I don't think anyone but him likes multiple namespaces per file. I do remember a PhD thesis sized mail from him explaining why multiple namespaces per file was needed though (can hardly believe anyone read the whole thing..). In some deployment processes, multiple PHP files are merged together into one file. Symfony, for example, does this, at least optionally. Regards, Stefan -- e-novative - We make IT work for you. e-novative GmbH - HR: Amtsgericht München HRB 139407 Sitz: Wolfratshausen - GF: Dipl. Inform. Stefan Priebsch http://www.e-novative.de - GnuPG Key: 0x7DB67F7F -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Inconsistencies in 5.3
On 04.08.2008, at 10:28, Stefan Priebsch wrote: Hannes Magnusson schrieb: I don't think anyone but him likes multiple namespaces per file. I do remember a PhD thesis sized mail from him explaining why multiple namespaces per file was needed though (can hardly believe anyone read the whole thing..). In some deployment processes, multiple PHP files are merged together into one file. Symfony, for example, does this, at least optionally. Right, this is common practice to reduce disk I/O without having to make development too hard. Also that way people can pick and choose what they want to include (like not all drivers of a DBAL). regards, Lukas Kahwe Smith [EMAIL PROTECTED] -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Inconsistencies in 5.3
Hello Lukas, Monday, August 4, 2008, 10:32:26 AM, you wrote: On 04.08.2008, at 10:28, Stefan Priebsch wrote: Hannes Magnusson schrieb: I don't think anyone but him likes multiple namespaces per file. I do remember a PhD thesis sized mail from him explaining why multiple namespaces per file was needed though (can hardly believe anyone read the whole thing..). In some deployment processes, multiple PHP files are merged together into one file. Symfony, for example, does this, at least optionally. Right, this is common practice to reduce disk I/O without having to make development too hard. Also that way people can pick and choose what they want to include (like not all drivers of a DBAL). If an edgecase optimization is th eonly reason then I am against this even more. Best regards, Marcus -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Inconsistencies in 5.3
Hello Dmitry, Monday, August 4, 2008, 8:55:00 AM, you wrote: Hi Marcus, see below Marcus Boerger wrote: Hello Internals, please let's not introduce new inconsistencies. Rather lets make new stuff consistent with old stuff during the alpha phase of 5.3. 1) new keyword 'use'. Semantically it is the same as 'static' or 'global' so it should be used in the same location. For me 'use' is the best keyword as it says that closure uses variables from current content. (the same keyword is used for import from namespaces) To be clear, I wasn't complaining about the keyword per se. I just prefer it to be inside the curly braces of a closure next to global rather than in front of it. 2) namespaces, either use 'package' and only one per file, or use 'namespace' with curly braces. Read this as be consistent with other languages and even if one or two people do not like it the two main languages out there which have it are Java which goes with the former and C++ which does the latter. Please chose and not mix it. Also our mix is a nightmare when developing code. If we feel we have to keep the keyword 'namesapce' but cannot have curly braces, than I suggest we disallow multiple namespace per file. And there is no technical reason and surely no other reason whatsoever to not have curly braces. If there is then we either fix that or went with the wrong approach. I don't like multiple namespaces per file too. As I remember they were introduced by Greg's request related to ext/phar. May be he already changed his mind. 'package' or 'namespace' is not so important for me. Thanks. Dmitry. 3) __invokable, see Etiene's mail Best regards, Marcus Best regards, Marcus -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Inconsistencies in 5.3
Hello Lukas, Monday, August 4, 2008, 10:49:43 AM, you wrote: On 04.08.2008, at 10:41, Marcus Boerger wrote: Hello Lukas, Monday, August 4, 2008, 10:32:26 AM, you wrote: On 04.08.2008, at 10:28, Stefan Priebsch wrote: Hannes Magnusson schrieb: I don't think anyone but him likes multiple namespaces per file. I do remember a PhD thesis sized mail from him explaining why multiple namespaces per file was needed though (can hardly believe anyone read the whole thing..). In some deployment processes, multiple PHP files are merged together into one file. Symfony, for example, does this, at least optionally. Right, this is common practice to reduce disk I/O without having to make development too hard. Also that way people can pick and choose what they want to include (like not all drivers of a DBAL). If an edgecase optimization is th eonly reason then I am against this even more. its not an edge optimization .. like i said its common practice in many PHP frameworks. this way they can more easily develop the code, while not having to suffer the drawbacks from a lot of disk I/O from files that need to be loaded in every request anyways. and those frameworks are the main users of namespaces, because they pull in libs from all sorts of libraries, add plugins etc. In that case lets have curly braces at least to be consistent with the rest of the language as every other grouping statement has curly braces. Best regards, Marcus -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Inconsistencies in 5.3
On Mon, Aug 4, 2008 at 10:32, Lukas Kahwe Smith [EMAIL PROTECTED] wrote: On 04.08.2008, at 10:28, Stefan Priebsch wrote: Hannes Magnusson schrieb: I don't think anyone but him likes multiple namespaces per file. I do remember a PhD thesis sized mail from him explaining why multiple namespaces per file was needed though (can hardly believe anyone read the whole thing..). In some deployment processes, multiple PHP files are merged together into one file. Symfony, for example, does this, at least optionally. Right, this is common practice to reduce disk I/O without having to make development too hard. Also that way people can pick and choose what they want to include (like not all drivers of a DBAL). Fair enough. Then lets keep the name namespace and use curly braces. -Hannes -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Inconsistencies in 5.3
Hi, Andrey Hristov wrote: isn't that easily solved by using a opcode cache? I think this is also one of the things you won't have often at hosters. I guess there's a speedup by having one file and no cache available, which is the argument here. Question is: where does that leave us :) If I remember correctly in the past it has been appealed to whether the one-file is really a benefit in practice. Who knows and who can tell? cheers, - Markus -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Inconsistencies in 5.3
On 04.08.2008, at 10:41, Marcus Boerger wrote: Hello Lukas, Monday, August 4, 2008, 10:32:26 AM, you wrote: On 04.08.2008, at 10:28, Stefan Priebsch wrote: Hannes Magnusson schrieb: I don't think anyone but him likes multiple namespaces per file. I do remember a PhD thesis sized mail from him explaining why multiple namespaces per file was needed though (can hardly believe anyone read the whole thing..). In some deployment processes, multiple PHP files are merged together into one file. Symfony, for example, does this, at least optionally. Right, this is common practice to reduce disk I/O without having to make development too hard. Also that way people can pick and choose what they want to include (like not all drivers of a DBAL). If an edgecase optimization is th eonly reason then I am against this even more. its not an edge optimization .. like i said its common practice in many PHP frameworks. this way they can more easily develop the code, while not having to suffer the drawbacks from a lot of disk I/O from files that need to be loaded in every request anyways. and those frameworks are the main users of namespaces, because they pull in libs from all sorts of libraries, add plugins etc. regards, Lukas Kahwe Smith [EMAIL PROTECTED] -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Inconsistencies in 5.3
On 04.08.2008, at 11:42, Andrey Hristov wrote: Hi, Lukas Kahwe Smith wrote: On 04.08.2008, at 10:41, Marcus Boerger wrote: Hello Lukas, Monday, August 4, 2008, 10:32:26 AM, you wrote: On 04.08.2008, at 10:28, Stefan Priebsch wrote: Hannes Magnusson schrieb: I don't think anyone but him likes multiple namespaces per file. I do remember a PhD thesis sized mail from him explaining why multiple namespaces per file was needed though (can hardly believe anyone read the whole thing..). In some deployment processes, multiple PHP files are merged together into one file. Symfony, for example, does this, at least optionally. Right, this is common practice to reduce disk I/O without having to make development too hard. Also that way people can pick and choose what they want to include (like not all drivers of a DBAL). If an edgecase optimization is th eonly reason then I am against this even more. its not an edge optimization .. like i said its common practice in many PHP frameworks. this way they can more easily develop the code, while not having to suffer the drawbacks from a lot of disk I/ O from files that need to be loaded in every request anyways. isn't that easily solved by using a opcode cache? The op code cache can reduce the overhead, but not all. Obviously there still needs to be work done to determine if the file has changed. of course you can just tell APC to never do that, but i think this is a setting very few people consider and its definitely not made for general purpose frameworks, that want to be easy to use while still being as fast as possible. regards, Lukas Kahwe Smith [EMAIL PROTECTED] -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Inconsistencies in 5.3
Hi, Lukas Kahwe Smith wrote: On 04.08.2008, at 10:41, Marcus Boerger wrote: Hello Lukas, Monday, August 4, 2008, 10:32:26 AM, you wrote: On 04.08.2008, at 10:28, Stefan Priebsch wrote: Hannes Magnusson schrieb: I don't think anyone but him likes multiple namespaces per file. I do remember a PhD thesis sized mail from him explaining why multiple namespaces per file was needed though (can hardly believe anyone read the whole thing..). In some deployment processes, multiple PHP files are merged together into one file. Symfony, for example, does this, at least optionally. Right, this is common practice to reduce disk I/O without having to make development too hard. Also that way people can pick and choose what they want to include (like not all drivers of a DBAL). If an edgecase optimization is th eonly reason then I am against this even more. its not an edge optimization .. like i said its common practice in many PHP frameworks. this way they can more easily develop the code, while not having to suffer the drawbacks from a lot of disk I/O from files that need to be loaded in every request anyways. isn't that easily solved by using a opcode cache? and those frameworks are the main users of namespaces, because they pull in libs from all sorts of libraries, add plugins etc. Andrey -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Inconsistencies in 5.3
Am 04.08.2008 um 10:58 schrieb Marcus Boerger: Hello Lukas, Monday, August 4, 2008, 10:49:43 AM, you wrote: its not an edge optimization .. like i said its common practice in many PHP frameworks. this way they can more easily develop the code, while not having to suffer the drawbacks from a lot of disk I/O from files that need to be loaded in every request anyways. and those frameworks are the main users of namespaces, because they pull in libs from all sorts of libraries, add plugins etc. In that case lets have curly braces at least to be consistent with the rest of the language as every other grouping statement has curly braces. +1 David -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Inconsistencies in 5.3
On Mon, 4 Aug 2008, Marcus Boerger wrote: Monday, August 4, 2008, 8:55:00 AM, you wrote: Marcus Boerger wrote: Hello Internals, please let's not introduce new inconsistencies. Rather lets make new stuff consistent with old stuff during the alpha phase of 5.3. 1) new keyword 'use'. Semantically it is the same as 'static' or 'global' so it should be used in the same location. For me 'use' is the best keyword as it says that closure uses variables from current content. (the same keyword is used for import from namespaces) To be clear, I wasn't complaining about the keyword per se. I just prefer it to be inside the curly braces of a closure next to global rather than in front of it. I'd have to agree with that... the place where it is used now is kinda strange. regards, Derick -- HEAD before 5_3!: http://tinyurl.com/6d2esb http://derickrethans.nl | http://ezcomponents.org | http://xdebug.org -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Inconsistencies in 5.3
Am 04.08.2008 um 10:42 schrieb Marcus Boerger: Hello Dmitry, Monday, August 4, 2008, 8:55:00 AM, you wrote: Hi Marcus, see below Marcus Boerger wrote: Hello Internals, please let's not introduce new inconsistencies. Rather lets make new stuff consistent with old stuff during the alpha phase of 5.3. 1) new keyword 'use'. Semantically it is the same as 'static' or 'global' so it should be used in the same location. For me 'use' is the best keyword as it says that closure uses variables from current content. (the same keyword is used for import from namespaces) To be clear, I wasn't complaining about the keyword per se. I just prefer it to be inside the curly braces of a closure next to global rather than in front of it. I think that's quite a logical and consistent argument. +1 David -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Inconsistencies in 5.3
Marcus Boerger wrote: Hello Dmitry, Monday, August 4, 2008, 8:55:00 AM, you wrote: Hi Marcus, see below Marcus Boerger wrote: Hello Internals, please let's not introduce new inconsistencies. Rather lets make new stuff consistent with old stuff during the alpha phase of 5.3. 1) new keyword 'use'. Semantically it is the same as 'static' or 'global' so it should be used in the same location. For me 'use' is the best keyword as it says that closure uses variables from current content. (the same keyword is used for import from namespaces) To be clear, I wasn't complaining about the keyword per se. I just prefer it to be inside the curly braces of a closure next to global rather than in front of it. No. The list of lexical variables is a part of the closure definition. The earlier implementation had lexical keyword which worked as you are suggesting, but it was much unclear. Thanks. Dmitry. -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Inconsistencies in 5.3
Dmitry Stogov wrote: I don't like multiple namespaces per file too. As I remember they were introduced by Greg's request related to ext/phar. May be he already changed his mind. 'package' or 'namespace' is not so important for me. To be correct, this has nothing to do with ext/phar, but everything to do with how PHP users do things now. There are several apps such as Doctrine that allow compiling their whole libraries into a single large file. This results in substantial performance improvement depending on app design both with and without opcode cache, verified independently by me and by Stas in Zend's labs. I personally probably won't be using multiple namespaces per file except in rare cases, but I see plenty of good reasons to allow it. Regards, Greg -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Inconsistencies in 5.3
Hannes Magnusson wrote:
On Mon, Aug 4, 2008 at 10:32, Lukas Kahwe Smith [EMAIL PROTECTED] wrote:
On 04.08.2008, at 10:28, Stefan Priebsch wrote:
Hannes Magnusson schrieb:
I don't think anyone but him likes multiple namespaces per file. I do
remember a PhD thesis sized mail from him explaining why multiple
namespaces per file was needed though (can hardly believe anyone read
the whole thing..).
In some deployment processes, multiple PHP files are merged together into
one file. Symfony, for example, does this, at least optionally.
Right, this is common practice to reduce disk I/O without having to make
development too hard. Also that way people can pick and choose what they
want to include (like not all drivers of a DBAL).
Fair enough.
Then lets keep the name namespace and use curly braces.
I said it before, and I'll say it again, I am fine with this approach,
especially with Dmitry's (old) proposed syntax allowing namespace-less
code within namespace {}:
?php
namespace foo {
class blah{}
}
namespace {
// put legacy code here
$a = new blah;
}
?
Greg
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Inconsistencies in 5.3
Hello Andi, Monday, August 4, 2008, 5:29:33 PM, you wrote: -Original Message- From: Stefan Priebsch [mailto:[EMAIL PROTECTED] Sent: Monday, August 04, 2008 1:29 AM To: Hannes Magnusson Cc: Dmitry Stogov; Marcus Boerger; internals@lists.php.net Subject: Re: [PHP-DEV] Inconsistencies in 5.3 Hannes Magnusson schrieb: I don't think anyone but him likes multiple namespaces per file. I do remember a PhD thesis sized mail from him explaining why multiple namespaces per file was needed though (can hardly believe anyone read the whole thing..). In some deployment processes, multiple PHP files are merged together into one file. Symfony, for example, does this, at least optionally. We were not big fans of this but were convinced that for these frameworks it'd be reasonable. We agreed that we would make sure people understand that using multiple namespaces per-file is not a best practice and is discouraged from non-generated code. Re: braces, I don't think it's a big deal but I would prefer without braces. Given that I think people should only have one namespace per file, the braces is a PITA because it already starts you off in an additional layer of indentation. We all know that whitespace does matter :) I fail to see a connection here and any decent editor that does auto-indentation can be configured to not do so for select structures and usually people do so for namespaces. Also another reason to not have braces because then it then makes sure that you don't go back into a global namespace and it is truly only used in these framework concatenation use cases. This can easily be addressed in the parser. Btw, I am both a C++ and Java developer and it honestly doesn't confuse me either way. I do prefer the namespace keyword because for me personally it better reflects what we have here. I always associate package with something that maps more directly to files but again, this could just be my own bias and I am sure I would get used to either very quickly. In general, people will always have pre conceived notions re: names but I have learnt that once a name is picked people will get used to them very quickly. This is true for most naming in life incl. personal life :) Andi Best regards, Marcus -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
