Nicolas Bérard-Nault schrieb:
+1 for braces around namespace definition.
-0 on that, because there is no clear standard with regard to how
other programming languages solve this.
Java does not require braces with its package construct [1] and C#
does for its namespace construct [2].
--
It seems that in contrast with a lot of people on this list, I don't preach
a standard way of doing things. What I do believe is that, in the end, it
is the programmer's choice. I for one won't use namespaces that much if I
can't have more than one in the same file. Using an inductive logic, I
Rasmus Lerdorf schrieb:
Stefan Priebsch wrote:
Hi Rasmus,
Or you may get it by conditionally including the file that defines it.
Note that the opcodes are still cached, it just means that the executor
has a bit more work to do on each request.
Thanks for clarifying this. Has anybody actually
Hi Stefan,
Putting multiple namespaces in one file is really unusual case.
It may be implemented, but I don't like to do it, because it may give more
mess then advantage.
Probably you'll have to create separate file for each namespace to make your
idea work.
BTW byte-code doesn't depend on
Is there a chance to add a PHP function that returns a fully
qualified name for a given name (thus letting the engine do
the expansion, which would ensure that correct rules are used)?
function namespace_name($name) {
return __NAMESPACE__ . :: . $name;
}
Thanks. Dmitry.
Kind regards,
Note that multiple files in namespace won't allow autoloading.
Dmitry.
-Original Message-
From: Larry Garfield [mailto:[EMAIL PROTECTED]
Sent: Saturday, July 07, 2007 11:15 PM
To: internals@lists.php.net
Subject: Re: [PHP-DEV] Simple Namespace Proposal
On Saturday 07 July
-1 for braces and multiple namespaces per file
Braces will allow define something outside namespace and I like to avoid
this possibility.
In the following correct example function bar() is defined in global
namespace.
?php
namespace A::B {
function foo() {
}
}
function bar() {
}
?
Lets not say what i didnt say...did anyone ask for
class a (
class b (
)
)
There were such proposals. But nested classes bring the whole set of
problems with them, and I don't really see a need for them. As we see,
we can solve long names problems in much simpler, and I daresay, more
OOP-PHP applications are usually one class per file with conditional
loading. This does not play well with caching. I am working on gluing
Why wouldn't it play well with caching?
(a phing task will do this) so it can be opcode cached as one large
application binary. I will then compare the
The number 8 also has lots of meaning in Chinese culture. For example
the Beijing Olympics will begin on 8/8/8 at 8:08:08 pm because the word
for 8 sounds like 发 which means prosper or wealth.
Well, then I guess we have no choice but to declare official PHP 4
end-of-life to be on 8:08:08 pm
On Sun, 8 Jul 2007, Stanislav Malyshev wrote:
The number 8 also has lots of meaning in Chinese culture. For example
the Beijing Olympics will begin on 8/8/8 at 8:08:08 pm because the word
for 8 sounds like 发 which means prosper or wealth.
Well, then I guess we have no choice but to
Hi all on this list!
My first post here.
This is a suggestion I think would not be too hard to implement:
Skip libc for all random functions. As I see it there is no reason to
keep it. I can't think of any application that would break if rand()
would produce better random results at a higher
Hi Dmitry,
I am merging together your various posts:
Note that multiple files in namespace won't allow autoloading.
Can you please explain why that is so?
function namespace_name($name) {
return __NAMESPACE__ . :: . $name;
}
Thanks for posting this - I am not sure wether this would do the
Stanislav Malyshev schrieb:
Why wouldn't it play well with caching?
My statement refered to a statment Rasmus had made somewhere else a
while ago (conditional includes not playing well with caches) that got
me confused. See Rasmus' clarifications in this thread.
I don't think one binary
On Sun, Jul 08, 2007 at 11:46:08AM +0200, Derick Rethans wrote:
On Sun, 8 Jul 2007, Stanislav Malyshev wrote:
The number 8 also has lots of meaning in Chinese culture. For example
the Beijing Olympics will begin on 8/8/8 at 8:08:08 pm because the word
for 8 sounds like 发 which means
On 08.07.2007, at 16:15, Alain Williams wrote:
On Sun, Jul 08, 2007 at 11:46:08AM +0200, Derick Rethans wrote:
On Sun, 8 Jul 2007, Stanislav Malyshev wrote:
The number 8 also has lots of meaning in Chinese culture. For
example
the Beijing Olympics will begin on 8/8/8 at 8:08:08 pm because
Well, then I guess we have no choice but to declare official PHP 4 end-of-life
to be on 8:08:08 pm too :) Now we only need to choose a suitable timezone :)
Well, for us using the 24 hr clock I'd say 8:08:08 am (ante meridiem) as
it otherwise will be 20:08:08 when we speak and write about
Yes, it would be. What's the problem with that?
I'm coming from the background of a plugin-based architecture where plugins
routinely add functions that would, conceptually, exist in a different
namespace.
That would require having both multiple namespaces per file and multiple files
per
I'm going to have to agree with Larry, here. If there's no *real* namespace
implementation in PHP6, there may as well not be one at all. Take a look around
at the countless other languages that already have this functionality. You're
gimping the language further if you implement namespaces
On Sunday 08 July 2007, Stefan Priebsch wrote:
I was asking myself wether loading one large file - possibly from a
cache - might be a lot faster than loading n files. This of course
depends on how expensive disk access is compared to how large your
binary gets. That's why I was planning to
I'm going to have to agree with Larry, here. If there's no *real*
namespace implementation in PHP6, there may as well not be one at
This implementation, while being simple, is as real as it gets. There's
nothing unreal in not having multiple namespaces per file.
all. Take a look around at
Keryx Web wrote:
Well, then I guess we have no choice but to declare official PHP 4
end-of-life
to be on 8:08:08 pm too :) Now we only need to choose a suitable
timezone :)
Well, for us using the 24 hr clock I'd say 8:08:08 am (ante meridiem) as
it otherwise will be 20:08:08 when we
Simplicity is not always dumb, but it can be if it limits usability. It
might be my PHP way to define the language as pragmatic and I may be wrong
in assuming this. Nevertheless, we've demonstrated with great length that
multiple namespaces per file / namespaces delimited by braces can and
will
Well, then I guess we have no choice but to declare official PHP 4
end-of-life
to be on 8:08:08 pm too :) Now we only need to choose a suitable
timezone :)
Well, for us using the 24 hr clock I'd say 8:08:08 am (ante meridiem) as
it otherwise will be 20:08:08 when we speak and write about
On 7/8/07, Tomas Kuliavas [EMAIL PROTECTED] wrote:
Well, then I guess we have no choice but to declare official PHP 4
end-of-life
to be on 8:08:08 pm too :) Now we only need to choose a suitable
timezone :)
Well, for us using the 24 hr clock I'd say 8:08:08 am (ante meridiem) as
it
On 7/9/07, Andi Gutmans [EMAIL PROTECTED] wrote:
Because some of us don't believe 6 months is enough time for the broad
market to make the move.
One year is more suitable.
As we already stated the message would already be strong today and
people wouldn't wait until the year ends with an
I have to agree with Andi. The GoPHP5 effort wanted to have a fairly
aggressive timeline because its main target is projects and shared hosts, and
if it was too far in the future no one would notice. The involved projects
also won't actually have their next feature release until later in the
No. If they don't get security updates then they can't really use it
anymore...
-Original Message-
From: Tijnema [mailto:[EMAIL PROTECTED]
Sent: Sunday, July 08, 2007 4:29 PM
To: Andi Gutmans
Cc: David Coallier; Tomas Kuliavas; internals@lists.php.net
Subject: Re: [PHP-DEV] RIP
On 7/9/07, Andi Gutmans [EMAIL PROTECTED] wrote:
No. If they don't get security updates then they can't really use it
anymore...
That's the ideal world. They should really not use it anymore but they
can and they will. No matter what we do. I saw many hosts with
outdated versions or using old
29 matches
Mail list logo
