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.
-
new keyword 'use'. Semantically it is the same as 'static' or 'global'
so it should be used in the same location. -
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.
- __invokable, see Etiene's mail
Best regards,
Marcus
Fully agreed with all of those. (especially for 1)
Moriyoshi
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.
new keyword 'use'. Semantically it is the same as 'static' or 'global'
so it should be used in the same location.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.
- __invokable, see Etiene's mail
Best regards,
Marcus
--
Moriyoshi Koizumi <moriyoshi@at.wakwak.com
Hi!
- new keyword 'use'. Semantically it is the same as 'static' or 'global'
so it should be used in the same location.
Of course it's not. It does entirely different thing from static or
global, it doesn't even deal with variables.
- 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
I don't see any requirement for PHP to mimic other languages up to
minute detail of keyword and separator usage.
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.
There are reason, and they were amply explained in past 10 revolutions
of this topic.
Stanislav Malyshev, Zend Software Architect
stas@zend.com http://www.zend.com/
(408)253-8829 MSN: stas@zend.com
Hi!
Of course it's not. It does entirely different thing from static or
global, it doesn't even deal with variables.
Or you meant "use" in lambda definition? Then I don't have opinion to
either side :)
Stanislav Malyshev, Zend Software Architect
stas@zend.com http://www.zend.com/
(408)253-8829 MSN: stas@zend.com
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.
- 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)
- 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.
- __invokable, see Etiene's mail
Best regards,
Marcus
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
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
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
mls@pooteeweet.org
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
Hannes Magnusson 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
Hello Lukas,
Monday, August 4, 2008, 10:32:26 AM, you 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
Hello Lukas,
Monday, August 4, 2008, 10:32:26 AM, you 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
mls@pooteeweet.org
Hello Lukas,
Monday, August 4, 2008, 10:49:43 AM, you wrote:
Hello Lukas,
Monday, August 4, 2008, 10:32:26 AM, you 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
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
Marcus Boerger wrote:
Hello Lukas,
Monday, August 4, 2008, 10:49:43 AM, you wrote:
Hello Lukas,
Monday, August 4, 2008, 10:32:26 AM, you 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.
I think the point is that PHP doesn't have the concept of compilation
units unlike major namespaced programming languages such as C++ and
Java. PHP so far chose to differentiate grammatical contexts with braces
or blocked statements, so should namespace.
Moriyoshi
Moriyoshi Koizumi <moriyoshi@at.wakwak.com
Hi,
Lukas Kahwe Smith wrote:
Hello Lukas,
Monday, August 4, 2008, 10:32:26 AM, you 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
Hi,
Lukas Kahwe Smith wrote:Hello Lukas,
Monday, August 4, 2008, 10:32:26 AM, you 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
mls@pooteeweet.org
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
-----Original Message-----
From: Stefan Priebsch [mailto:stefan.priebsch@e-novative.de]
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.3Hannes 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 :)
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.
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
Hello Andi,
Monday, August 4, 2008, 5:29:33 PM, you wrote:
-----Original Message-----
From: Stefan Priebsch [mailto:stefan.priebsch@e-novative.de]
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.3Hannes 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
On Monday 04 August 2008 10:29:33 am Andi Gutmans wrote:
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 :) 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.
There's always
class Foo::Bar { ... }
if you want to avoid too much indentation. :-)
runs
Seriously though, the main problem I see with the non-braces mechanism is
that, as others have observed, it is the only place in PHP (AFAIK) where file
matters. All other code can be shuffled about from file to file without
breaking. That's rather inconsistent.
--
Larry Garfield
larry@garfieldtech.com
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.
- 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.
- 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.
- __invokable, see Etiene's mail
Best regards,
Marcus
Best regards,
Marcus
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.
- 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
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.
- 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
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.
- 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.
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.
- 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
--
Moriyoshi Koizumi <moriyoshi@at.wakwak.com
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.
- 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
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.
- 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
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.
- 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
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.
- 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
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.
- 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,
MarcusBest regards,
Marcus
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 moriyoshi@at.wakwak.com
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
larry@garfieldtech.com
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 moriyoshi@at.wakwak.comThe 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
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
stas@zend.com http://www.zend.com/
(408)253-8829 MSN: stas@zend.com
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
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.
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
stas@zend.com http://www.zend.com/
(408)253-8829 MSN: stas@zend.com
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
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
stas@zend.com http://www.zend.com/
(408)253-8829 MSN: stas@zend.com
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 :pSure 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
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
stas@zend.com http://www.zend.com/
(408)253-8829 MSN: stas@zend.com
Stanislav Malyshev wrote:
Hi!
language syntax, whereas the "use" construct after the argument list
is inconsistent with the ordinary function definition unless my proposalBecause 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
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
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
stas@zend.com http://www.zend.com/
(408)253-8829 MSN: stas@zend.com
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
new keyword 'use'. Semantically it is the same as 'static' or
'global'
so it should be used in the same location.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.
- __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
mls@pooteeweet.org
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
stas@zend.com http://www.zend.com/
(408)253-8829 MSN: stas@zend.com
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 orOK, 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
hannes.magnusson@gmail.com escreveu:
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
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
stas@zend.com http://www.zend.com/
(408)253-8829 MSN: stas@zend.com
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
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
stas@zend.com http://www.zend.com/
(408)253-8829 MSN: stas@zend.com
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
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
stas@zend.com http://www.zend.com/
(408)253-8829 MSN: stas@zend.com
Hello,
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
stas@zend.com http://www.zend.com/
(408)253-8829 MSN: stas@zend.com--
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
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
stas@zend.com http://www.zend.com/
(408)253-8829 MSN: stas@zend.com
Hello,
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
stas@zend.com http://www.zend.com/
(408)253-8829 MSN: stas@zend.com
--
Etienne Kneuss
http://www.colder.ch
Men never do evil so completely and cheerfully as
when they do it from a religious conviction.
-- Pascal
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
stas@zend.com http://www.zend.com/
(408)253-8829 MSN: stas@zend.com
Hello,
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
stas@zend.com http://www.zend.com/
(408)253-8829 MSN: stas@zend.com
--
Etienne Kneuss
http://www.colder.ch
Men never do evil so completely and cheerfully as
when they do it from a religious conviction.
-- Pascal
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>;
codeOnly 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
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>;
codeOnly 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
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
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
stas@zend.com http://www.zend.com/
(408)253-8829 MSN: stas@zend.com
Hello Etienne,
Tuesday, August 12, 2008, 3:04:48 AM, you wrote:
Hello,
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:
- 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.
-
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. -
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:
- 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 same namespace,
if we fix this we end up in different behavior of include/require for
namespe/non namespace files. If we disallow that, we make it harder
to understand when it is allowed and when not. - A file included from a namespaced function/method body ends up in
that function method but not in its namespace:
http://lxr.php.net/source/ZendEngine2/tests/ns_069.phpt
http://lxr.php.net/source/ZendEngine2/tests/ns_069.inc
- Change keyword 'namespace' to 'package'
0 Besides the file concatenation this would be exactly what Java does
- Namespace has been a reserved keyword, added 15th August 2007:
http://cvs.php.net/viewvc.cgi/phpdoc/en/appendices/reserved.xml?r1=1.66&r2=1.67 - 'Package' is not a reserved keyword at all
[The arguments of 1) aply]
2b) Like 2) but no multiple namespaces per file (no file concatenation)
0 Phar can be used to put several file in one anyway
- Add curly braces to 'namespace'
- Real nesting (some people don't like it but we support it anyway)
- Allows for global, non namespaced code, and thus full concatenation of
files
0 Looks and feels exactly like C++ (besides we need to discuss whether to
allow code outside namespace).
0 Makes it a block structure like class which uses {}
- For some people this means additional whitespace (other people do not
have this issue, yet counted as -)
Why reuse keyword 'namespace' to identify root namespace (namespace::)?
- Why not use ':::' instead (re2c allows that easily) ?
Why no non namespced code?
- Issues with compiler caches
Do we need to support concatenation of files at all costs?
- We actually ship phar which allows to pack as many namespaced files
in a single php file, no matter what namespace support we end up
allowing.
III) personal preference
My preference is 3) and the next one would be 2) without file
concatenation support, as in one namespace per file only.
IV) what to do next
Someone should collect more arguments from the various threads (I am
sure there are more) and put them on a wiki. This pretty much looks
like a job for Lukas :-)
Best regards,
Marcus
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!
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,
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:
- 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.
- 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.
- 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:
- 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 same namespace,
if we fix this we end up in different behavior of include/require for
namespe/non namespace files. If we disallow that, we make it harder
to understand when it is allowed and when not.- A file included from a namespaced function/method body ends up in
that function method but not in its namespace:
http://lxr.php.net/source/ZendEngine2/tests/ns_069.phpt
http://lxr.php.net/source/ZendEngine2/tests/ns_069.inc
- Change keyword 'namespace' to 'package'
0 Besides the file concatenation this would be exactly what Java does
- Namespace has been a reserved keyword, added 15th August 2007:
http://cvs.php.net/viewvc.cgi/phpdoc/en/appendices/reserved.xml?r1=1.66&r2=1.67
- 'Package' is not a reserved keyword at all
[The arguments of 1) aply]
2b) Like 2) but no multiple namespaces per file (no file concatenation)
0 Phar can be used to put several file in one anyway
- Add curly braces to 'namespace'
- Real nesting (some people don't like it but we support it anyway)
- Allows for global, non namespaced code, and thus full concatenation of
files
0 Looks and feels exactly like C++ (besides we need to discuss whether to
allow code outside namespace).
0 Makes it a block structure like class which uses {}
- For some people this means additional whitespace (other people do not
have this issue, yet counted as -)
Why reuse keyword 'namespace' to identify root namespace (namespace::)?
- Why not use ':::' instead (re2c allows that easily) ?
Why no non namespced code?
- Issues with compiler caches
Do we need to support concatenation of files at all costs?
- We actually ship phar which allows to pack as many namespaced files
in a single php file, no matter what namespace support we end up
allowing.
III) personal preference
My preference is 3) and the next one would be 2) without file
concatenation support, as in one namespace per file only.
IV) what to do next
Someone should collect more arguments from the various threads (I am
sure there are more) and put them on a wiki. This pretty much looks
like a job for Lukas :-)
In a pretty long IRC discussion we discussed besides other stuff the
following:
a) Prevent include/require inside namespaced functions.
Patch: php-no-include-in-namespaced-functions-6.0-20080812.diff.txt
Should pretty much work.
b) Allow both 'namspace foo;' as well as 'namespace foo {}'.
Patch: php-namespaces-with-curlies-6.0-20080812.diff.txt
Note that this patch does not come with test updates and necessary error
message adjustage.
Best regards,
Marcus
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
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
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
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
mls@pooteeweet.org
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
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
stas@zend.com http://www.zend.com/
(408)253-8829 MSN: stas@zend.com
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
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
stas@zend.com http://www.zend.com/
(408)253-8829 MSN: stas@zend.com
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
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
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
stas@zend.com http://www.zend.com/
(408)253-8829 MSN: stas@zend.com
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
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
stas@zend.com http://www.zend.com/
(408)253-8829 MSN: stas@zend.com
Simply include a script from two locations with different namespaces
or onewith 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
mls@pooteeweet.org
Lukas Kahwe Smith wrote:
Simply include a script from two locations with different namespaces
or onewith 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
Simply include a script from two locations with different
namespaces or onewith 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
mls@pooteeweet.org
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
stas@zend.com http://www.zend.com/
(408)253-8829 MSN: stas@zend.com
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
stas@zend.com http://www.zend.com/
(408)253-8829 MSN: stas@zend.com
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
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
stas@zend.com http://www.zend.com/
(408)253-8829 MSN: stas@zend.com
Lukas Kahwe Smith wrote:
Simply include a script from two locations with different namespaces
or onewith 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
Gregory Beaver wrote:
Lukas Kahwe Smith wrote:
Simply include a script from two locations with different namespaces
or onewith 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
Gregory Beaver wrote:
Lukas Kahwe Smith wrote:
Simply include a script from two locations with different
namespaces
or onewith 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
mls@pooteeweet.org
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,
Gregory Beaver wrote:
Lukas Kahwe Smith wrote:
Simply include a script from two locations with different namespaces
or onewith 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
mls@pooteeweet.org--
--
Guilherme Blanco - Web Developer
CBC - Certified Bindows Consultant
Cell Phone: +55 (16) 9166-6902
MSN: guilhermeblanco@hotmail.com
URL: http://blog.bisna.com
Rio de Janeiro - RJ/Brazil
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,
Gregory Beaver wrote:
Lukas Kahwe Smith wrote:
Simply include a script from two locations with different namespaces
or onewith 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 ..
Autoload is different and I am still collecting opinions here to see what
needs to be done. One solution might be to invoke the autoload chain always
from the global namespace. Maybe only do the namespace reset from within
SPLs autoload. This is by the way independend from the discussion whether
we should issue warnings when include/require occurs inside a namespaced
function/method.
Best regards,
Marcus
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
mls@pooteeweet.org
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
larry@garfieldtech.com
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
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
larry@garfieldtech.com
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
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
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
larry@garfieldtech.com
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
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
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:stas@zend.com]
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
stas@zend.com http://www.zend.com/
(408)253-8829 MSN: stas@zend.com
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
stas@zend.com http://www.zend.com/
(408)253-8829 MSN: stas@zend.com
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
stas@zend.com http://www.zend.com/
(408)253-8829 MSN: stas@zend.com
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
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
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 {}
- 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). - Class and function exist as stand-alone entity, namespace does not.
- 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:
- To define namespace for the file, write "namespace Foo::Bar;" at the
beginning of the file. - That's it, enjoy. ;)
--
Stanislav Malyshev, Zend Software Architect
stas@zend.com http://www.zend.com/
(408)253-8829 MSN: stas@zend.com
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 {}
- 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).- Class and function exist as stand-alone entity, namespace does not.
- 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:
- To define namespace for the file, write "namespace Foo::Bar;" at the
beginning of the file.- That's it, enjoy. ;)
-
You want another namespace, just write namespace again.
-
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
Hi!
- You want another namespace, just write namespace again.
No, that's not for kids to play with. That's grown-up stuff. Rated X.
- 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
stas@zend.com http://www.zend.com/
(408)253-8829 MSN: stas@zend.com
Hello Stanislav,
Tuesday, August 12, 2008, 2:45:12 AM, you wrote:
Hi!
- 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.
- 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
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
stas@zend.com http://www.zend.com/
(408)253-8829 MSN: stas@zend.com
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
mls@pooteeweet.org