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 auto
.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-loca
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
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 mak
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 names
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 befor
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-o
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
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.
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
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
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
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.
W
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 misunderst
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 tim
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 t
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 guide
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
nu
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
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 f
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 whe
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
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 documentati
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, 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 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
> m
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 nam
Hi!
As far as I understood the discussion, it was related to OP code caches.
The opcode result from this snippet ...
These will generate identical opcodes except that the class name in the
former snippet would be Foo::Bar of course.
--
Stanislav Malyshev, Zend Software Architect
[EMAIL PROT
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 th
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
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 mo
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 comp
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
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
>>
>> Sho
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 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 mad
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 Developm
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!
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
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 perspe
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 take
Hello Etienne,
Tuesday, August 12, 2008, 3:04:48 AM, you wrote:
> Hello,
> On Tue, Aug 12, 2008 at 2:39 AM, Stanislav Malyshev <[EMAIL PROTECTED]> wrote:
>> Hi!
>>
>>> but if the {} syntax is introduced, it will be made to affect only the
>>> code inside it, right? If so, I fail to see your poin
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 wit
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 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;
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 ;
> code
>
> Only nicer. And I can hardly
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
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 na
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
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 i
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 Pyth
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 cl
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 thi
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 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
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
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 synt
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
> "triskai
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
[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
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 introduce
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
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 03.08.2008, at 14:26, Marcus Boerger wrote:
1) new keyword 'use'. Semantically it is the same as 'static' or
'global'
so it should be used in the same location.
2) namespaces, either use 'package' and only one per file, or use
'namespace' with curly braces. Read this as be consistent with
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 somebod
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 "co
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,
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+$
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
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!
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
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 ne
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 al
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 ple
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.
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 Inter
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]>
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]>
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
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, 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;
>
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
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
Marcus Boerger wrote:
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
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 indentat
p.net
>> Subject: Re: [PHP-DEV] Inconsistencies in 5.3
>>
>> Hannes Magnusson schrieb:
>> > I don't think anyone but him likes multiple namespaces per file. I do
>> > remember a PhD thesis sized mail from him explaining why multiple
>> > namespaces
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 explaini
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 ever
> -Original Message-
> From: Stefan Priebsch [mailto:[EMAIL PROTECTED]
> Sent: Monday, August 04, 2008 1:29 AM
> To: Hannes Magnusson
> Cc: Dmitry Stogov; Marcus Boerger; internals@lists.php.net
> Subject: Re: [PHP-DEV] Inconsistencies in 5.3
>
> Hannes Magnus
Marcus Boerger wrote:
Hello Dmitry,
Monday, August 4, 2008, 8:55:00 AM, you wrote:
Hi Marcus,
see below
Marcus Boerger wrote:
Hello Internals,
please let's not introduce new inconsistencies. Rather lets make new
stuff consistent with old stuff during the alpha phase of 5.3.
1) new
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.
> >>
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 a
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
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 11:42, Andrey Hristov wrote:
Hi,
Lukas Kahwe Smith wrote:
On 04.08.2008, at 10:41, Marcus Boerger wrote:
Hello Lukas,
Monday, August 4, 2008, 10:32:26 AM, you wrote:
On 04.08.2008, at 10:28, Stefan Priebsch wrote:
Hannes Magnusson schrieb:
I don't think anyone but him
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
reme
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 any
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
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
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
>>> namespa
1 - 100 of 110 matches
Mail list logo
