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
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.
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,
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
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
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
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
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
: [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
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
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
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
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
On 13.08.2008, at 15:35, Lars Strojny wrote:
Hi Markus
Am Mittwoch, den 13.08.2008, 15:21 +0200 schrieb Marcus Boerger:
[...]
Namespaces are new, so it never worked before. But yes, this would
trigger
a warning in the compiler which means you are told to not do this
with apc
or other
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
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
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
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
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
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
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
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 :)
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
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
On 13.08.2008, at 22:18, Stanislav Malyshev wrote:
Simply include a script from two locations with different namespaces
or one
with namespace and the otherone without.
I'm afraid you misunderstand how namespaces work. As I explained
numerous times, namespaces are file-local, and this
Lukas Kahwe Smith wrote:
On 13.08.2008, at 22:18, Stanislav Malyshev wrote:
Simply include a script from two locations with different namespaces
or one
with namespace and the otherone without.
I'm afraid you misunderstand how namespaces work. As I explained
numerous times, namespaces are
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
On 14.08.2008, at 00:09, Lukas Kahwe Smith wrote:
On 13.08.2008, at 22:18, Stanislav Malyshev wrote:
Simply include a script from two locations with different
namespaces or one
with namespace and the otherone without.
I'm afraid you misunderstand how namespaces work. As I explained
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
Lukas Kahwe Smith wrote:
On 13.08.2008, at 22:18, Stanislav Malyshev wrote:
Simply include a script from two locations with different namespaces
or one
with namespace and the otherone without.
I'm afraid you misunderstand how namespaces work. As I explained
numerous times, namespaces
Gregory Beaver wrote:
Lukas Kahwe Smith wrote:
On 13.08.2008, at 22:18, Stanislav Malyshev wrote:
Simply include a script from two locations with different namespaces
or one
with namespace and the otherone without.
I'm afraid you misunderstand how namespaces work. As I explained
numerous
On 14.08.2008, at 00:54, Rasmus Lerdorf wrote:
Gregory Beaver wrote:
Lukas Kahwe Smith wrote:
On 13.08.2008, at 22:18, Stanislav Malyshev wrote:
Simply include a script from two locations with different
namespaces
or one
with namespace and the otherone without.
I'm afraid you
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.
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
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
Hello everybody,
Am Dienstag, den 12.08.2008, 03:04 +0200 schrieb Etienne Kneuss:
[...]
To me
namespace A {
code
}
namespace B {
code
}
code
seems equivalent to
namespace A;
code
namespace B;
code
namespace none;
code
Only nicer. And I can hardly how it's going
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
Hello Stanislav,
Tuesday, August 12, 2008, 2:45:12 AM, you wrote:
Hi!
3. You want another namespace, just write namespace again.
No, that's not for kids to play with. That's grown-up stuff. Rated X.
LOL, That pretty much defeats the whole KISS approach. I suggest we drop
that after all
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
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
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
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
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
Hi,
I am sorry, but I cannot keep up with this thread. Is anyone even
presenting novel arguments? This is why I asked for a vote and not
more discussion. I guess my mistake was for asking for a summary.
regards,
Lukas Kahwe Smith
[EMAIL PROTECTED]
--
PHP Internals - PHP Runtime
Hello Marcus,
Tuesday, August 12, 2008, 3:36:36 PM, you wrote:
Hello Etienne,
Tuesday, August 12, 2008, 3:04:48 AM, you wrote:
Hello,
On Tue, Aug 12, 2008 at 2:39 AM, Stanislav Malyshev [EMAIL PROTECTED]
wrote:
Hi!
but if the {} syntax is introduced, it will be made to affect only
On 03.08.2008, at 14:26, Marcus Boerger wrote:
1) new keyword 'use'. Semantically it is the same as 'static' or
'global'
so it should be used in the same location.
2) namespaces, either use 'package' and only one per file, or use
'namespace' with curly braces. Read this as be consistent
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
On 11/08/2008, Stanislav Malyshev [EMAIL PROTECTED] wrote:
Hi!
Ideally someone would summarize the discussion (or maybe two people, one
from each camp) and then we can have a vote. Make it an RFC or
OK, here it goes again:
When we adopt some syntax, especially syntax matching some other
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
[EMAIL PROTECTED] escreveu:
On 11/08/2008, Stanislav Malyshev [EMAIL PROTECTED] wrote:
Hi!
Ideally someone would summarize the discussion (or maybe two people, one
from each camp) and then we can have a vote. Make it an RFC or
OK, here it goes again:
When we adopt some syntax, especially
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
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
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
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
Hello,
On Tue, Aug 12, 2008 at 12:58 AM, Stanislav Malyshev [EMAIL PROTECTED] wrote:
Hi!
So why the $%#$% can't we use package if the implementation has
nothing incommon with namespaces in c++ (your example, not mine)?
We could use package or we could use hexaflexagon or we could use
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 -
Hello,
On Tue, Aug 12, 2008 at 2:12 AM, Stanislav Malyshev [EMAIL PROTECTED] wrote:
Hi!
I fail to see why { } meaning a different level of hierarchy is a
problem here, that's exactly what it's supposed to mean: code in that
block is affected by that namespace.
Exactly. The thing is that
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
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
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
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:
Hi!
3. You want another namespace, just write namespace again.
No, that's not for kids to play with. That's grown-up stuff. Rated X.
4. You got lost after the 10th namespace? Welcome to if-else nesting
Get your hands away from the keyboard and re-read the part about not
using multiple
Hello,
On Tue, Aug 12, 2008 at 2:39 AM, Stanislav Malyshev [EMAIL PROTECTED] wrote:
Hi!
but if the {} syntax is introduced, it will be made to affect only the
code inside it, right? If so, I fail to see your point, since the new
syntax will solve that problem.
While introducing a whole
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,
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
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
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
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
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
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
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
Stanislav Malyshev wrote:
Hi!
What a nitpicking :) So would I say that the global statement is
inconsistent with static because it doesn't allow assignments within
the statement :p
Sure it is. That's just another thing to show all this consistency
talk is blown way out of proportion long
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
Stanislav Malyshev wrote:
Hi!
language syntax, whereas the use construct after the argument list
is inconsistent with the ordinary function definition unless my proposal
Because it is _not_ an ordinary function definition. It's like saying
'+' is inconsistent with '-' because $a+$b=$b+$a
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
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;
}
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) {
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
On Tuesday 05 August 2008 12:48:37 am Moriyoshi Koizumi wrote:
I don't think there are many differences in ambiguity between
$closure = function ($arg) { use $a;
...
};
and
$closure = function ($arg) use ($a) {
};
Moriyoshi
--
Moriyoshi Koizumi [EMAIL PROTECTED]
The former has
Larry Garfield wrote:
On Tuesday 05 August 2008 12:48:37 am Moriyoshi Koizumi wrote:
I don't think there are many differences in ambiguity between
$closure = function ($arg) { use $a;
...
};
and
$closure = function ($arg) use ($a) {
};
Moriyoshi
--
Moriyoshi Koizumi [EMAIL PROTECTED]
Hi!
function ($arg) { use $a, $b;
Note that neither static not global allow inside definitions, so from
consistency point of view it doesn't work.
--
Stanislav Malyshev, Zend Software Architect
[EMAIL PROTECTED] http://www.zend.com/
(408)253-8829 MSN: [EMAIL PROTECTED]
--
PHP
Hi Marcus,
see below
Marcus Boerger wrote:
Hello Internals,
please let's not introduce new inconsistencies. Rather lets make new
stuff consistent with old stuff during the alpha phase of 5.3.
1) new keyword 'use'. Semantically it is the same as 'static' or 'global'
so it should be used in
On Mon, Aug 4, 2008 at 08:55, Dmitry Stogov [EMAIL PROTECTED] wrote:
I don't like multiple namespaces per file too.
As I remember they were introduced by Greg's request related to ext/phar.
May be he already changed his mind.
I don't think anyone but him likes multiple namespaces per file. I
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
On 04.08.2008, at 10:28, Stefan Priebsch wrote:
Hannes Magnusson schrieb:
I don't think anyone but him likes multiple namespaces per file. I do
remember a PhD thesis sized mail from him explaining why multiple
namespaces per file was needed though (can hardly believe anyone read
the whole
Hello Lukas,
Monday, August 4, 2008, 10:32:26 AM, you wrote:
On 04.08.2008, at 10:28, Stefan Priebsch wrote:
Hannes Magnusson schrieb:
I don't think anyone but him likes multiple namespaces per file. I do
remember a PhD thesis sized mail from him explaining why multiple
namespaces per
Hello Dmitry,
Monday, August 4, 2008, 8:55:00 AM, you wrote:
Hi Marcus,
see below
Marcus Boerger wrote:
Hello Internals,
please let's not introduce new inconsistencies. Rather lets make new
stuff consistent with old stuff during the alpha phase of 5.3.
1) new keyword 'use'.
Hello Lukas,
Monday, August 4, 2008, 10:49:43 AM, you wrote:
On 04.08.2008, at 10:41, Marcus Boerger wrote:
Hello Lukas,
Monday, August 4, 2008, 10:32:26 AM, you wrote:
On 04.08.2008, at 10:28, Stefan Priebsch wrote:
Hannes Magnusson schrieb:
I don't think anyone but him likes
On Mon, Aug 4, 2008 at 10:32, Lukas Kahwe Smith [EMAIL PROTECTED] wrote:
On 04.08.2008, at 10:28, Stefan Priebsch wrote:
Hannes Magnusson schrieb:
I don't think anyone but him likes multiple namespaces per file. I do
remember a PhD thesis sized mail from him explaining why multiple
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
On 04.08.2008, at 10:41, Marcus Boerger wrote:
Hello Lukas,
Monday, August 4, 2008, 10:32:26 AM, you wrote:
On 04.08.2008, at 10:28, Stefan Priebsch wrote:
Hannes Magnusson schrieb:
I don't think anyone but him likes multiple namespaces per file.
I do
remember a PhD thesis sized mail
On 04.08.2008, at 11:42, Andrey Hristov wrote:
Hi,
Lukas Kahwe Smith wrote:
On 04.08.2008, at 10:41, Marcus Boerger wrote:
Hello Lukas,
Monday, August 4, 2008, 10:32:26 AM, you wrote:
On 04.08.2008, at 10:28, Stefan Priebsch wrote:
Hannes Magnusson schrieb:
I don't think anyone but
Hi,
Lukas Kahwe Smith wrote:
On 04.08.2008, at 10:41, Marcus Boerger wrote:
Hello Lukas,
Monday, August 4, 2008, 10:32:26 AM, you wrote:
On 04.08.2008, at 10:28, Stefan Priebsch wrote:
Hannes Magnusson schrieb:
I don't think anyone but him likes multiple namespaces per file. I do
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
On Mon, 4 Aug 2008, Marcus Boerger wrote:
Monday, August 4, 2008, 8:55:00 AM, you wrote:
Marcus Boerger wrote:
Hello Internals,
please let's not introduce new inconsistencies. Rather lets make
new stuff consistent with old stuff during the alpha phase of 5.3.
1) new keyword
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
Marcus Boerger wrote:
Hello Dmitry,
Monday, August 4, 2008, 8:55:00 AM, you wrote:
Hi Marcus,
see below
Marcus Boerger wrote:
Hello Internals,
please let's not introduce new inconsistencies. Rather lets make new
stuff consistent with old stuff during the alpha phase of 5.3.
1)
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
Hannes Magnusson wrote:
On Mon, Aug 4, 2008 at 10:32, Lukas Kahwe Smith [EMAIL PROTECTED] wrote:
On 04.08.2008, at 10:28, Stefan Priebsch wrote:
Hannes Magnusson schrieb:
I don't think anyone but him likes multiple namespaces per file. I do
remember a PhD thesis sized mail from him
Hello Andi,
Monday, August 4, 2008, 5:29:33 PM, you wrote:
-Original Message-
From: Stefan Priebsch [mailto:[EMAIL PROTECTED]
Sent: Monday, August 04, 2008 1:29 AM
To: Hannes Magnusson
Cc: Dmitry Stogov; Marcus Boerger; internals@lists.php.net
Subject: Re: [PHP-DEV] Inconsistencies
1 - 100 of 108 matches
Mail list logo
