Your answered like "We are not like C#, but we are like Python.". I'm
not the one that will point that Python always try to be a unique
language or will criticize you.
We are not like Python either, really. We try to do what's best for PHP
with it's unique history, usage patterns and problems.
Hi,
At first "import Zend::DB" is equivalent of "import Zend:DB as DB";
-Original Message-
> From: Arpad Ray [mailto:[EMAIL PROTECTED]
> Sent: Monday, July 23, 2007 8:37 PM
> To: [EMAIL PROTECTED]
> Cc: 'Hans Lellelid'; 'PHP internals'
> -Original Message-
> From: Guilherme Blanco [mailto:[EMAIL PROTECTED]
> Sent: Monday, July 23, 2007 8:21 PM
> To: David Coallier
> Cc: David Zulke; Dmitry Stogov; Arpad Ray; Hans Lellelid; PHP
> internals
> Subject: Re: [PHP-DEV] Simple Namespace Proposal
&g
>
> 2) In short and clear, why are braces not being used ? C++,
> C# uses it. (Short answer and if the answer is "Developer
> didn't want to do it..." just say "Usual"
We are not C++. Python doesn't use braces.
The only neediness for braces is placing several namespaces into one file,
but one of
I've the same problem: the patch is there but no real information how
it's supposed to work, i.e. expected feature set. I mean, in one place.
A Wiki would be nice ;-)
It's here:
http://marc.info/?l=php-dev&m=118355320225178&w=2
Maybe also need README and FAQ on that too, and eventually a m
On 7/23/07, David Zülke <[EMAIL PROTECTED]> wrote:
Am 23.07.2007 um 16:44 schrieb Dmitry Stogov:
> It is not the first namespace proposal.
> I made three different concept and saw two other concepts in the
> past .
> This one seems as most awaitble by most PHP users.
This is a pretty random gue
Am 23.07.2007 um 16:44 schrieb Dmitry Stogov:
It is not the first namespace proposal.
I made three different concept and saw two other concepts in the
past .
This one seems as most awaitble by most PHP users.
This is a pretty random guess, but I'd say people are so tired of
having to expl
> -Original Message-
> From: [EMAIL PROTECTED]
> [mailto:[EMAIL PROTECTED] On Behalf Of David Coallier
> Sent: Monday, July 23, 2007 4:31 PM
> To: Dmitry Stogov
> Cc: Arpad Ray; Hans Lellelid; PHP internals
> Subject: Re: [PHP-DEV] Simple Namespace Proposal
>
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Hi,
David Coallier wrote:
> Should be ok for a first draft and this is not some sort of attack, I
> am really trying to compile a list of features absent and present to
> see what *types* of namespaces we have and how to correctly inform
> people on h
1) Do we have unnamed namespaces available ?
I'm not sure what it is but most probably no.
2) In short and clear, why are braces not being used ? C++, C# uses
it. (Short answer and if the answer is "Developer didn't want to do
it..." just say "Usual"
PHP is not C++, C#. For the rest of expla
m: Arpad Ray [mailto:[EMAIL PROTECTED]
> Sent: Sunday, July 15, 2007 7:32 PM
> To: Dmitry Stogov
> Cc: 'Hans Lellelid'; 'PHP internals'
> Subject: Re: [PHP-DEV] Simple Namespace Proposal
>
>
> Dmitry Stogov wrote:
> > The patch is already committ
, July 15, 2007 7:32 PM
> To: Dmitry Stogov
> Cc: 'Hans Lellelid'; 'PHP internals'
> Subject: Re: [PHP-DEV] Simple Namespace Proposal
>
>
> Dmitry Stogov wrote:
> > The patch is already committed to the HEAD.
> >
> > Dmitry.
> >
I'm still trying to figure out why you think this is an acceptable
implementation of namespaces. This isn't namespaces at all. This is
barely an acceptable method of shortening classnames. What are we, as
It's what was attempted to do. If you find it "unacceptable", one would
expect some argume
On 7/21/07, Guilherme Blanco <[EMAIL PROTECTED]> wrote:
I'll give you an example... PHP Doctrine package has a lot of files,
hundreds... there is a way to compile it in a single file, to save
some memory usage for including these files. Including a single file
is better than include hundreds, as
> For 100th time, import Foo is a no-op. I'm thinking about prohibiting
it
> at all... If you do import Foo::bar you'll get an error if Bar is
already
> defined.
I'm still trying to figure out why you think this is an acceptable
implementation of namespaces. This isn't namespaces at all. This is
1 - The official namespace support will not use curly braces? Never or
can be in the future?
Nobody knows what will be is the future. As of now, the autors do not
see a compelling reason to support more than once namespace per file.
I suggest to get things standard-ized. If a class uses brac
> 3 - How will PHP behavior on a situation that you have a naming conflict?
>
> Something like...
>
> class Bar { ... }
>
> namespace Foo {
> class Bar { ... }
> }
>
> import Foo;
>
> $b = new Bar();
Well, PHP's namespaces don't behave like every other language I've ever used
that supports
or feedback and idea.
>>>
>>> >> namespace UTF8;
>>>
>>> overloaded class Exception {
>>> }
>>>
>>> overloaded function strlen() {
>>> }
>>> ?>
>>>
>>> Thanks. Dmitry.
>>>
>>&
On 7/16/07, Stanislav Malyshev <[EMAIL PROTECTED]> wrote:
> a) I was talking about namespace name "A_B" not class/function name.
_ is legal identifier character, so it would not be a good idea to use
it as a separator. :: on the other side is natural scope separator in
many languages. But I'm ra
a) I was talking about namespace name "A_B" not class/function name.
_ is legal identifier character, so it would not be a good idea to use
it as a separator. :: on the other side is natural scope separator in
many languages. But I'm rather reluctant to start the "my separator is
better than
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] On Behalf Of David Coallier
Sent: Thursday, July 05, 2007 5:35 PM
To: Stefan Priebsch
Cc: Dmitry Stogov; PHP internals
Subject: Re: [PHP-DEV] Simple Namespace Proposal
On 7/5/07, Stefan Priebsch <[EMAIL PROTECTED]> wrote:
David Coallier schrieb
On 7/16/07, Stanislav Malyshev <[EMAIL PROTECTED]> wrote:
> The other thing that bothers me is namespaces nesting. It was said
> that namespaces
> nesting is not supported. Then I'm missing a point in having namespace
> named "A::B".
The same reason some people write $a = f($z, $t) and some writ
The other thing that bothers me is namespaces nesting. It was said
that namespaces
nesting is not supported. Then I'm missing a point in having namespace
named "A::B".
The same reason some people write $a = f($z, $t) and some write
$parsed_template = template_parser($template, $data_values) :)
Is this what other languages try to solve with:
import foo::*;
(untested, I don't know if this is implemented) ?
No, not implemented and probably won't be. It isn't necessary for
solving the long names problem and in fact brings the whole same problem
back again by putting all the names back
I've attached some phpt files to test this, but here's a simple
illustration:
foo.php:
bar.php:
That's how it's supposed to work. Import foo is a no-op.
import foo::foobar;
import foo::Foobaz;
foobar(); // error
new Foobaz; // ok
Well, this one might be an error - I think direct import o
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Hi,
Arpad Ray wrote:
> I've attached some phpt files to test this, but here's a simple
> illustration:
>
> foo.php:
> namespace foo;
> function foobar() { }
> class Foobaz { }
> ?>
>
> bar.php:
> import foo;
> foobar(); // error
> new Foobaz; // e
Dmitry Stogov wrote:
The patch is already committed to the HEAD.
Dmitry.
There seem to be some problems with importing across files. The tests
currently in CVS are all in single files so it's not immediately
obvious. When a namespace is declared in one file and imported in
another, classes
Hi,
I read whole discussion and I'd like to share my opinion.
> Similarly, allowing multiple namespaces per file does not limit the
> developer in any way. Not allowing them does. I always thought a
> language should be designed to empower it's developers, not get in
> their way.
My opinion is
We'll think little bit more. Anyway thank you for feedback
> and idea.
> >>
> >> >> namespace UTF8;
> >>
> >> overloaded class Exception {
> >> }
> >>
> >> overloaded function strlen() {
> >> }
> >>
The patch is already committed to the HEAD.
Dmitry.
> -Original Message-
> From: Hans Lellelid [mailto:[EMAIL PROTECTED]
> Sent: Sunday, July 15, 2007 4:37 AM
> Cc: Dmitry Stogov; 'PHP internals'
> Subject: Re: [PHP-DEV] Simple Namespace Proposal
>
&
d function strlen() {
>> }
>> ?>
>>
>> Thanks. Dmitry.
>>
>>> -Original Message-
>>> From: [EMAIL PROTECTED]
>>> [mailto:[EMAIL PROTECTED] On Behalf Of David Coallier
>>> Sent: Thursday, July 05, 2007 5:35 PM
>>> To:
On 7/12/07, Stanislav Malyshev <[EMAIL PROTECTED]> wrote:
> Similarly, allowing multiple namespaces per file does not limit the
> developer in any way. Not allowing them does. I always thought a
> language should be designed to empower it's developers, not get in
> their way.
My opinion is that
Similarly, allowing multiple namespaces per file does not limit the
developer in any way. Not allowing them does. I always thought a
language should be designed to empower it's developers, not get in
their way.
My opinion is that sometimes language *should* "get in the way" - if the
developer i
On Wed, 11 Jul 2007 21:31:34 -0700
[EMAIL PROTECTED] (Stanislav Malyshev) wrote:
> I understand we're forcing some structure here, but I think
> actually it's good - and many other languages have it either
> by design or de-facto.
Personally, I'm of the opinion that file structure should be an ap
On Thu, 2007-07-12 at 09:30 +0200, Stefan Priebsch wrote:
> From a regular PHP developer's perspective, SPL is part of the core
> (read: it is guaranteed that it is always there). The manual says so,
> and it has been said in most, if not all SPL-related presentations.
If manual says that then the
> -Original Message-
> From: Richard Lynch [mailto:[EMAIL PROTECTED]
> Sent: Thursday, July 12, 2007 4:45 AM
> To: Stanislav Malyshev
> Cc: Dmitry Stogov; 'Sebastian Bergmann'; internals@lists.php.net
> Subject: Re: [PHP-DEV] Simple Namespace Proposal
>
Richard Lynch schrieb:
> And for those of us who never use autoload OR SPL, could you please
> not force SPL into core?
>From a regular PHP developer's perspective, SPL is part of the core
(read: it is guaranteed that it is always there). The manual says so,
and it has been said in most, if not all
But some functions ARE so super-common, across the board, that I just
plain don't want them buried in some namespace...
Sure, why not put them into separate file then? I understand we're
forcing some structure here, but I think actually it's good - and many
other languages have it either by de
On Wed, 2007-07-11 at 20:57 -0400, David Coallier wrote:
>
> If you want to do functional programming then go ahead, if you want to
> do OOP, then do real OOP, not sub-oop or some php4-oop.
Pray tell... what exactly is "real OOP"? This sounds like it might be
something extremely subjective and po
On Wed, July 11, 2007 7:57 pm, David Coallier wrote:
> If you want to do functional programming then go ahead, if you want to
> do OOP, then do real OOP, not sub-oop or some php4-oop.
Many users, for many tasks, have absolutely zero need to do any OOP at
all.
And bloating their PHP for OOP they d
On 7/11/07, Richard Lynch <[EMAIL PROTECTED]> wrote:
On Mon, July 9, 2007 4:58 pm, Stefan Priebsch wrote:
> I know, and I use spl_autoload_register. But then I would blatantly
> suggest to remove __autoload() in PHP6 and force SPL to be compiled
> into
> PHP.
Deprecate in 6, remove in 7 might be
On Mon, July 9, 2007 4:58 pm, Stefan Priebsch wrote:
> I know, and I use spl_autoload_register. But then I would blatantly
> suggest to remove __autoload() in PHP6 and force SPL to be compiled
> into
> PHP.
Deprecate in 6, remove in 7 might be a better strategy...
Otherwise you'll hear: "Oh, I ca
On Mon, July 9, 2007 2:49 am, Stanislav Malyshev wrote:
>> +1 for braces.
>>
>> > function
>> super_common_function_every_namespace_in_my_project_uses(){
>> }
>>
>> namespace A::B {
>> function foo() {
>> //arcana of A::B stuff
>> }
>> }
>> ?>
>
> That's what I would like to a
because someone needs to decide in what order autoload strategies are
applied. this is especially important for libraries that do not prefix
Not if we have namespaces :) With namespaces, order doesn't matter.
Without namespaces, libraries not using unique prefixes are asking for
trouble anyway
On 10.07.2007, at 18:55, Stanislav Malyshev wrote:
the application should define how things get loaded, precisely
because it decides about what libraries are used, what approach
each of them has taken etc. also on the application level you may
want to implement some way to override impleme
the application should define how things get loaded, precisely because
it decides about what libraries are used, what approach each of them has
taken etc. also on the application level you may want to implement some
way to override implementations from the library etc.
Why application develope
On 10.07.2007, at 09:17, Stanislav Malyshev wrote:
The application should define this, not the library or module...
Why not? If library needs to load files, why can't it define how to
load them?
-
the application should define how things get loaded, precisely
because it decides about w
o: internals@lists.php.net
> Subject: Re: [PHP-DEV] Simple Namespace Proposal
>
>
>
>
>
> On Mon, 9 Jul 2007 20:13:23 +0200 (CEST), Derick Rethans
> <[EMAIL PROTECTED]> wrote:
> > On Wed, 4 Jul 2007, Dmitry Stogov wrote:
> >
> >> The namespace dec
Derick Rethans schrieb:
> That's what we're doing... however, I don't mind the "force SPL to be
> compiled into PHP" bit. I think we should do that.
Since the manual says "This extension is available and compiled by
default in PHP 5.", so a lot of developers (me included) rely on SPL
funtionality
The application should define this, not the library or module...
Why not? If library needs to load files, why can't it define how to load
them?
--
Stanislav Malyshev, Zend Software Architect
[EMAIL PROTECTED] http://www.zend.com/
(408)253-8829 MSN: [EMAIL PROTECTED]
--
PHP Internals - PHP
On Tue, 10 Jul 2007, Stanislav Malyshev wrote:
> > > Well if we are speaking of best practices, the sensible thing for
> > > libs to do is to provide a function/method users can call inside
> > > their own __autoload() implementation. This way users are free to
> > > make their __autoload() wor
Well if we are speaking of best practices, the sensible thing for libs
to do is to provide a function/method users can call inside their own
__autoload() implementation. This way users are free to make their
__autoload() work as they please/require.
That's OK too, but this requires the user to
On Tue, 10 Jul 2007, Lukas Kahwe Smith wrote:
> On 10.07.2007, at 00:06, Stanislav Malyshev wrote:
>
> > > I know, and I use spl_autoload_register. But then I would
> > > blatantly suggest to remove __autoload() in PHP6 and force SPL to
> > > be compiled into PHP.
> >
> > I wouldn't go as far
nal Message-
> From: Derick Rethans [mailto:[EMAIL PROTECTED]
> Sent: Monday, July 09, 2007 10:38 PM
> To: Dmitry Stogov
> Cc: 'Larry Garfield'; internals@lists.php.net
> Subject: RE: [PHP-DEV] Simple Namespace Proposal
>
>
> On Sun, 8 Jul 2007, Dmitry Stogov
On 10.07.2007, at 00:06, Stanislav Malyshev wrote:
I know, and I use spl_autoload_register. But then I would blatantly
suggest to remove __autoload() in PHP6 and force SPL to be
compiled into
PHP.
I wouldn't go as far as removing it, but definitely would go as far
as not recommending to
On Mon, 9 Jul 2007 16:40:09 -0400, "Nicolas Bérard-Nault" <[EMAIL PROTECTED]>
wrote:
> header() doesn't have to be the first statement in a file at all. It has to
> be called before any data is sent.
Thanks for the response.
Just wanted to see if there were any potential collisions here.
Thank
On Mon, 9 Jul 2007 16:40:09 -0400, "Nicolas Bérard-Nault" <[EMAIL PROTECTED]>
wrote:
> header() doesn't have to be the first statement in a file at all. It has to
> be called before any data is sent.
Thanks for the response.
Just wanted to see if there were any potential collisions here.
Thank
I know, and I use spl_autoload_register. But then I would blatantly
suggest to remove __autoload() in PHP6 and force SPL to be compiled into
PHP.
I wouldn't go as far as removing it, but definitely would go as far as
not recommending to use it if writing a library or application that
includes
Stanislav Malyshev schrieb:
>> Will there be an exception [as in: special case, not as in: new
>> Exception()] for an __autoload function?
>
> __autoload is actually not that great an idea, as it appears now.
> spl_autoload_register works much better for complicated libraries.
I know, and I use s
header() doesn't have to be the first statement in a file at all. It has to
be called before any data is sent.
On 7/9/07, chris# <[EMAIL PROTECTED]> wrote:
On Mon, 9 Jul 2007 20:13:23 +0200 (CEST), Derick Rethans <[EMAIL PROTECTED]>
wrote:
> On Wed, 4 Jul 2007, Dmitry Stogov wrote:
>
>> The
On Mon, 9 Jul 2007 20:13:23 +0200 (CEST), Derick Rethans <[EMAIL PROTECTED]>
wrote:
> On Wed, 4 Jul 2007, Dmitry Stogov wrote:
>
>> The namespace declaration statement must be the very first statement in
>> file.
>
> I thought that was reserved in PHP 6 for the "pragma(encoding=UTF-8);"
> sta
declare(encoding=...) may be used befor or right after namespace
declaration.
Dmitry.
> -Original Message-
> From: Derick Rethans [mailto:[EMAIL PROTECTED]
> Sent: Monday, July 09, 2007 10:13 PM
> To: Dmitry Stogov
> Cc: internals@lists.php.net
> Subject: Re: [PHP-DEV
On Sun, 8 Jul 2007, Dmitry Stogov wrote:
> Note that multiple files in namespace won't allow autoloading.
That got me confused a bit. I was wondering whether the following would
work (with autoload):
In file "a/b.php":
in file "a/c.php":
In file "a/d.php":
in file "a/e.php":
in "
That's why I proposed (privately) to Dmitry to use declare() for
namespace declaration.
-Andrei
On Jul 9, 2007, at 11:13 AM, Derick Rethans wrote:
On Wed, 4 Jul 2007, Dmitry Stogov wrote:
The namespace declaration statement must be the very first
statement in
file.
I thought that was
On Wed, 4 Jul 2007, Dmitry Stogov wrote:
> The namespace declaration statement must be the very first statement in
> file.
I thought that was reserved in PHP 6 for the "pragma(encoding=UTF-8);"
statement? Which of the two needs to be first, and which second?
regards,
Derick
--
Derick Rethans
Will there be an exception [as in: special case, not as in: new
Exception()] for an __autoload function?
__autoload is actually not that great an idea, as it appears now.
spl_autoload_register works much better for complicated libraries.
--
Stanislav Malyshev, Zend Software Architect
[EMAIL PR
I agree, FWIW.
-Andrei
On Jul 9, 2007, at 12:49 AM, Stanislav Malyshev wrote:
+1 for braces.
function super_common_function_every_namespace_in_my_project_uses
(){
}
namespace A::B {
function foo() {
//arcana of A::B stuff
}
}
?>
That's what I would like to avoid. Bec
> -Original Message-
> From: Stefan Priebsch [mailto:[EMAIL PROTECTED]
> Sent: Monday, July 09, 2007 6:17 PM
> To: Dmitry Stogov
> Cc: 'Sebastian Bergmann'; internals@lists.php.net
> Subject: Re: [PHP-DEV] Simple Namespace Proposal
>
>
> Dmitry,
Stanislav Malyshev schrieb:
>> function super_common_function_every_namespace_in_my_project_uses(){
>> }
>>
>> namespace A::B {
> That's what I would like to avoid. Because if you need namespaces, then
> you want to segment your naming space. If you in the same time pollute
> the global space
Dmitry,
>>> Note that multiple files in namespace won't allow autoloading.
>> Can you please explain why that is so?
>
> Now autoloading maps class name into file name, however if you have several
> classes in one file, only one of them may be autoloaded(). The same with
> namespaces.
Did you co
+1 for braces.
That's what I would like to avoid. Because if you need namespaces, then
you want to segment your naming space. If you in the same time pollute
the global space with non-namespaced function names, the whole namespace
business is kind of meaningless. Or you want your library no
On Sun, July 8, 2007 2:58 am, Dmitry Stogov wrote:
> -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.
>
> namespac
> -Original Message-
> From: Stefan Priebsch [mailto:[EMAIL PROTECTED]
> Sent: Sunday, July 08, 2007 3:51 PM
> To: Dmitry Stogov
> Cc: 'Sebastian Bergmann'; internals@lists.php.net
> Subject: Re: [PHP-DEV] Simple Namespace Proposal
>
>
> Hi Dm
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
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 th
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
ment namespaces without such core
functionality as this.
Regards,
Jeremy
-Original Message-
From: Larry Garfield [mailto:[EMAIL PROTECTED]
Sent: Sunday, July 08, 2007 1:13 PM
To: internals@lists.php.net
Subject: Re: [PHP-DEV] Simple Namespace Proposal
Yes, it would be. What's the probl
-Original Message-
> > From: news [mailto:[EMAIL PROTECTED] On Behalf Of Sebastian Bergmann
> > Sent: Sunday, July 08, 2007 10:13 AM
> > To: internals@lists.php.net
> > Subject: Re: [PHP-DEV] Simple Namespace Proposal
> >
> > Nicolas Bérard-Nault schrieb:
>
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" app
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
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 per
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
s [mailto:[EMAIL PROTECTED] On Behalf Of Sebastian Bergmann
> Sent: Sunday, July 08, 2007 10:13 AM
> To: internals@lists.php.net
> Subject: Re: [PHP-DEV] Simple Namespace Proposal
>
>
> Nicolas Bérard-Nault schrieb:
> > +1 for braces around namespace definition.
>
> -0 on t
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
&g
> 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 reg
y, July 07, 2007 2:45 PM
> To: Dmitry Stogov
> Cc: 'David Coallier'; 'Stefan Walk'; 'Brian Moon';
> internals@lists.php.net
> Subject: Re: [PHP-DEV] Simple Namespace Proposal
>
>
> Hi Dmitry,
>
> Allowing only one namespace per file is
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 actua
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 g
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].
> Note that what you are saving by combining the files into one is just a
> single stat syscall per file. And that can be alleviated by setting
> apc.stat=0 in your config. That of course means you need to restart
> your server or flush your cache whenever you want to update the files.
> In apc.s
Stefan Priebsch wrote:
> Hi Ramus,
>
> Rasmus Lerdorf schrieb:
>> Note that what you are saving by combining the files into one is just a
>> single stat syscall per file. And that can be alleviated by setting
>> apc.stat=0 in your config. That of course means you need to restart
>> your server o
+1 for braces around namespace definition.
Personally I'm not really convinced that imposing a coding standard we see
as clean/more acceptable is really useful in that case.
On 7/7/07, Larry Garfield <[EMAIL PROTECTED]> wrote:
On Saturday 07 July 2007, Stefan Priebsch wrote:
> Hi Dmitry,
>
> A
On Saturday 07 July 2007, Stefan Priebsch wrote:
> Hi Dmitry,
>
> Allowing only one namespace per file is a clean concept which I like
> very much. I have a use case for putting multiple namespaces into one
> file, though.
>
> OOP-PHP applications are usually one class per file with conditional
> l
Hi Ramus,
Rasmus Lerdorf schrieb:
> Note that what you are saving by combining the files into one is just a
> single stat syscall per file. And that can be alleviated by setting
> apc.stat=0 in your config. That of course means you need to restart
> your server or flush your cache whenever you w
Stefan Priebsch wrote:
> Hi Dmitry,
>
> Allowing only one namespace per file is a clean concept which I like
> very much. I have a use case for putting multiple namespaces into one
> file, though.
>
> OOP-PHP applications are usually one class per file with conditional
> loading. This does not pl
Stefan Priebsch schrieb:
> 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)?
This is part of the functionality that needs to be, IMHO, added to the
Refle
Sebastian Bergmann schrieb:
> Why not "expand" namespaces during these step? The resulting file would
> then have either only one namespace or no namespace at all.
A good idea, but (much) more work of course, since it requires parsing
and rewriting every file. And I am not sure, if this really w
Stefan Priebsch schrieb:
> I am working on gluing together all files of a project into one large
> source file on deployment
Why not "expand" namespaces during these step? The resulting file would
then have either only one namespace or no namespace at all.
--
Sebastian Bergmann
Hi Dmitry,
Allowing only one namespace per file is a clean concept which I like
very much. I have a use case for putting multiple namespaces into one
file, though.
OOP-PHP applications are usually one class per file with conditional
loading. This does not play well with caching. I am working on g
Lets not say what i didnt say...did anyone ask for
class a (
class b (
)
)
i believe not.. the point was to keep the same coding standards if i
may say so than classes, interfaces, abstracts, etc. simply for
consistency and normalization..
ps sorry for brackets its from my mobile phone
1 - 100 of 123 matches
Mail list logo
