Everything
php
Learn Community Releases The PHP Project
Home » Project » Newsgroups » php.internals » Simple Namespace Proposal »

Simple Namespace Proposal

php.internals

Dmitry Stogov

19 years ago
Hi, Please review the following concept and patch for php6... http://dev.daylessday.org/diff/ns-06.diff.txt http://dev.daylessday.org/diff/tests.tar.gz Main assumption of the model is that the problem that we are to solve is the problem of the very long class names in PHP libraries. We would not attempt to take autoloader's job or create packaging model - only make names manageable. Namespaces are defined the following way: Zend/DB/Connection.php: <?php namespace Zend::DB; class Connection { } function connect() { } ?> Namespace definition does the following: All class and function names inside are automatically prefixed with namespace name. Inside namespace, local name always takes precedence over global name. It is possible to use the same namespace in several PHP files. The namespace declaration statement must be the very first statement in file. Every class and function from namespace can be referred to by the full name - e.g. Zend::DB::Connection or Zend::DB::connect - at any time. <?php require 'Zend/Db/Connection.php'; $x = new Zend::DB::Connection; Zend::DB::connect(); ?> Namespace or class name can be imported: <?php require 'Zend/Db/Connection.php'; import Zend::DB; import Zend::DB::Connection as DbConnection; $x = new Zend::DB::Connection(); $y = new DB::connection(); $z = new DbConnection(); DB::connect(); ?> import statement only defines name aliasing. It may create name alias for namespace or class. The simple form of statement "import A::B::C::D;" is equivalent to "import A::B::C::D as D;". Import statement can be used at any time in global scope (not inside function/class) and takes effect from the point of definition down to the end of file. It is recommended however to place imports at the beginning of the file. Import statements have effect only on file where they are written. The special "empty" namespace (:: prefix) is useful as explicit global namespace qualification. All class and function names started from :: interpreted as global. <?php namespace A::B::C; $con = ::mysql_connect(...); ?> A special constant __NAMESPACE__ indicates the current namespace. It can be used to construct fully-qualified names to pass them as callbacks. <?php namespace A::B::C; function foo() { } set_error_handler(__NAMESPACE__ . "::foo"); ?> In global namespace __NAMESPACE__ constant has value of empty string. Names inside namespace are resolved according to the following rules. 1) all qualified names are translated during compilation according to current import rules. So if we have "import A::B::C;" and then "C::D::e();" it is translated to "A::B::C::D::e()" 2) unqualified class names translated during compilation according to current import rules. So if we have "import A::B::C;" and then "new C();" it is translated to "new A::B::C()" 3) calls to unqualified functions that are defined in current namespace interpreted as calls to corresponding functions 4) calls to unqualified functions that are not defined in current namespace are resolved in run-time. The call to function foo() inside namespace (A::B) first tries to find and call function from current namespace A::B::foo() and if it doesn't exist PHP tries to call internal function foo(). Note that using foo() in namespace you can call only internal PHP functions, however using ::foo() you are able to call any function from global namespace. 5) unqualified class names are resolved at run-time. E.q. "new Exception()" first tries to use (end even __autoload()) class from current namespace and in case of failure uses internal PHP class. Note that using "new A" in namespace you can call only create internal PHP class, however using "new ::A" you are able to create any class from global namespace 6) Calls to qualified functions are resolved at run-time. Call to "A::B::foo()" first tries to call function foo() from namespace "A::B", then it tries to find class "A::B (__autoload() it if necessary) and call its static function foo() 7) qualified class names are interpreted as class from corresponding namespace. So "new A::B::C()" creates class "C" from namespace "A::B". Thanks. Dmitry.

Brian Moon

19 years ago
> It is possible to use the same namespace in several PHP files.
Does this mean that a project like Phorum could declare the same namespace at the top of all of our files and all the code in those files would exist in the same namespace? common.php: <?php namespace Phorum; $PHORUM = get_settings(); function phorum_build_url(){ return $url; } ?> list.php: <?php namespace Phorum; $url - phorum_build_url(); ?> Or, would list.php have to import the Phorum namespace? Also, I don't see any mention of variables in namespaces. Will there be no effect on variables?
-- Brian Moon Senior Developer ------------------------------ http://dealnews.com/ It's good to be cheap =)

Dmitry Stogov

19 years ago
> > It is possible to use the same namespace in several PHP files. > > Does this mean that a project like Phorum could declare the same > namespace at the top of all of our files and all the code in > those files > would exist in the same namespace?
Exactly.
> common.php: > <?php > namespace Phorum; > > $PHORUM = get_settings(); > > function phorum_build_url(){ > return $url; > } > ?> > > list.php: > <?php > namespace Phorum; > > $url - phorum_build_url(); > > ?> > > > Or, would list.php have to import the Phorum namespace? > > Also, I don't see any mention of variables in namespaces. > Will there be > no effect on variables?
Nor variables naither constants. They are defined in run-time. Dmitry.

Stefan Walk

19 years ago
On 04/07/07, Dmitry Stogov <dmitry@zend.com> wrote:
> Nor variables naither constants. > They are defined in run-time.
This seems to me like a bit of drawback. Would it be possible to add compile-time constants, then (like const FOO = 1; outside a class)? Creating a class inside a namespace for constants doesn't seem clean to me. Regards, Stefan

Dmitry Stogov

19 years ago
PHP itself (without classes) hasn't compile-time constants (and variables). You can define constants only in run-time using define(). This is the reason why this proposal don't try to use constants and variables in namespaces. So ithis approach is absolutely consistent. BTW you can "import" not only namespace but also class from namespace. <?php namespace A::B; class Foo { const C = 5; } <?php import A::B::Foo; echo Foo::C; I would like to start with this "simple" proposal and may be extend it with constants and variables in the future. Thanks. Dmitry.

David Coallier

19 years ago
On 7/6/07, Dmitry Stogov <dmitry@zend.com> wrote:
> PHP itself (without classes) hasn't compile-time constants (and variables). > You can define constants only in run-time using define(). This is the reason > why this proposal don't try to use constants and variables in namespaces. So > ithis approach is absolutely consistent. > > BTW you can "import" not only namespace but also class from namespace. > > <?php > namespace A::B; > > class Foo { > const C = 5; > } > > <?php > import A::B::Foo; > echo Foo::C; > > I would like to start with this "simple" proposal and may be extend it with > constants and variables in the future. > > Thanks. Dmitry. > > > -----Original Message----- > > From: Stefan Walk [mailto:stefan.walk@gmail.com] > > Sent: Friday, July 06, 2007 10:26 PM > > To: Dmitry Stogov > > Cc: Brian Moon; internals@lists.php.net > > Subject: Re: [PHP-DEV] Simple Namespace Proposal > > > > > > On 04/07/07, Dmitry Stogov <dmitry@zend.com> wrote: > > > Nor variables naither constants. > > > They are defined in run-time. > > > > This seems to me like a bit of drawback. Would it be possible > > to add compile-time constants, then (like const FOO = 1; > > outside a class)? Creating a class inside a namespace for > > constants doesn't seem clean to me. > > > > Regards, > > Stefan > > > > -- > > PHP Internals - PHP Runtime Development Mailing List > > To unsubscribe, visit: http://www.php.net/unsub.php > > > > -- > PHP Internals - PHP Runtime Development Mailing List > To unsubscribe, visit: http://www.php.net/unsub.php > >
One thing I'm wondering (might have missed it on the list but we discussed that a little bit on irc..) Do we have to have a namespace per file or could we have our braces ? :) namespace A::B { class BooYa { const C = 'Foo'; } } --- Then.. import A::B::BooYa; echo BooYa::C; That way we can put more than one namespace within a file or such... just point me if I am replying to an existing question or re-asking :) Thanks,
-- David Coallier, Founder & Software Architect, Agora Production (http://agoraproduction.com) 51.42.06.70.18

Stanislav Malyshev

19 years ago
> namespace A::B > { > class BooYa > { > const C = 'Foo'; > } > } > > --- Then.. > > import A::B::BooYa; > echo BooYa::C;
Well, we could have braces but...
> That way we can put more than one namespace within a file or such...
That is exactly what I don't want to have, since then you can't see in the file which name means what - you'd have to trace it back to including namespace to see what is the real name of the class. Also if we do braces next thing would be asked to do namespace { namespace {} } and we don't want that either :) We try to keep it really simple.
-- Stanislav Malyshev, Zend Software Architect stas@zend.com http://www.zend.com/ (408)253-8829 MSN: stas@zend.com

David Coallier

19 years ago
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 On 7/6/07, Stanislav Malyshev <stas@zend.com> wrote:
> > namespace A::B > > { > > class BooYa > > { > > const C = 'Foo'; > > } > > } > > > > --- Then.. > > > > import A::B::BooYa; > > echo BooYa::C; > > Well, we could have braces but... > > > That way we can put more than one namespace within a file or such... > > That is exactly what I don't want to have, since then you can't see in > the file which name means what - you'd have to trace it back to > including namespace to see what is the real name of the class. > > Also if we do braces next thing would be asked to do namespace { > namespace {} } and we don't want that either :) We try to keep it really > simple. > > -- > Stanislav Malyshev, Zend Software Architect > stas@zend.com http://www.zend.com/ > (408)253-8829 MSN: stas@zend.com > >
-- David Coallier, Founder & Software Architect, Agora Production (http://agoraproduction.com) 51.42.06.70.18

Stanislav Malyshev

19 years ago
> 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 elegant way. And other benefits of nested classes, IMHO, not worth the trouble.
-- Stanislav Malyshev, Zend Software Architect stas@zend.com http://www.zend.com/ (408)253-8829 MSN: stas@zend.com

Dmitry Stogov

19 years ago
One file may contain only one namespace and nothing else. Several files may have the same namespace. Dmitry.

Stefan Priebsch

19 years ago
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 gluing together all files of a project into one large source file on deployment (a phing task will do this) so it can be opcode cached as one large application binary. I will then compare the performance of both apporaches, but I have a feeling that the "single binary" approach will be faster. As APC will be part of PHP6, I think this approach could improve general performance of PHP applications and easw deployment. Allowing only one namespace per file will obviously kill this approach. So if there is there a chance of allowing a namespace in braces, it would be great if you could make this possible. Kind regards, Stefan
-- >e-novative> - We make IT work for you. e-novative GmbH - HR: Amtsgericht München HRB 139407 Sitz: Wolfratshausen - GF: Dipl. Inform. Stefan Priebsch http://www.e-novative.de

Sebastian Bergmann

19 years ago
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 http://sebastian-bergmann.de/ GnuPG Key: 0xB85B5D69 / 27A7 2B14 09E4 98CD 6277 0E5B 6867 C514 B85B 5D69

Stefan Priebsch

19 years ago
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 works out when it comes to dynamically creating class and function names. 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)? Kind regards, Stefan
-- >e-novative> - We make IT work for you. e-novative GmbH - HR: Amtsgericht München HRB 139407 Sitz: Wolfratshausen - GF: Dipl. Inform. Stefan Priebsch http://www.e-novative.de

Rasmus Lerdorf

19 years ago
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 play well with caching. I am working on gluing > together all files of a project into one large source file on deployment > (a phing task will do this) so it can be opcode cached as one large > application binary. I will then compare the performance of both > apporaches, but I have a feeling that the "single binary" approach will > be faster. As APC will be part of PHP6, I think this approach could > improve general performance of PHP applications and easw deployment.
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.stat=0 mode you gain nothing by merging all the files. -Rasmus

Stefan Priebsch

19 years ago
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 want to update the files. > In apc.stat=0 mode you gain nothing by merging all the files.
Hmmm, in earlier posts of yours (BTW, there was quite some confusion about those, I believe) you mentioned that/how cache-unfriendly conditional includes (i.e. autoload) were. Are we talking about new APC development here or did I misread your earlier comments on caching? Kind regards, Stefan
-- >e-novative> - We make IT work for you. e-novative GmbH - HR: Amtsgericht München HRB 139407 Sitz: Wolfratshausen - GF: Dipl. Inform. Stefan Priebsch http://www.e-novative.de

Lucas Nealan

19 years ago
> 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.stat=0 mode you gain nothing by merging all the files. > > -Rasmus
This was our belief as well but we have been experimenting with file combining and have seen as much a 2x speed improvement over using includes even with apc.stat=0. I need to spend some time investigating this more but from some initial profiling the most significant difference is that when all functions are in a single file execution goes through ZEND_DO_FCALL_SPEC_CONST_HANDLER. When functions are in included files execution seems to go through ZEND_DO_FCALL_BY_NAME_SPEC_HANDLER and ZEND_INIT_FCALL_BY_NAME_SPEC_CONTS_HANDLER. The latter function spends a good amount of time in zend_str_tolower_dup and overall we spend more time in memory allocation. I'm not too familiar with zend internals and do not yet undersand the logic here but today there is an actual benefit to inlining files when working with a large enough code base. -lucas
-- lucas@facebook.com lucas@sizzo.org

Larry Garfield

19 years ago
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 > loading. This does not play well with caching. I am working on gluing > together all files of a project into one large source file on deployment > (a phing task will do this) so it can be opcode cached as one large > application binary. I will then compare the performance of both > apporaches, but I have a feeling that the "single binary" approach will > be faster. As APC will be part of PHP6, I think this approach could > improve general performance of PHP applications and easw deployment. > > Allowing only one namespace per file will obviously kill this approach. > So if there is there a chance of allowing a namespace in braces, it > would be great if you could make this possible. > > Kind regards, > > Stefan
I would also prefer a braces-based namespace approach. Namespace organization and file organization do not always match 1:1, especially if you're doing function-based programming rather than OO. Being able to put 2 namespaces in one file would add a great deal of flexibility, stat-count aside.
-- Larry Garfield AIM: LOLG42 larry@garfieldtech.com ICQ: 6817012 "If nature has made any one thing less susceptible than all others of exclusive property, it is the action of the thinking power called an idea, which an individual may exclusively possess as long as he keeps it to himself; but the moment it is divulged, it forces itself into the possession of every one, and the receiver cannot dispossess himself of it." -- Thomas Jefferson

=?ISO-8859-1?Q?Nicolas_B=E9rard-Nault?=

19 years ago
+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 <larry@garfieldtech.com> wrote:
> > 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 > > loading. This does not play well with caching. I am working on gluing > > together all files of a project into one large source file on deployment > > (a phing task will do this) so it can be opcode cached as one large > > application binary. I will then compare the performance of both > > apporaches, but I have a feeling that the "single binary" approach will > > be faster. As APC will be part of PHP6, I think this approach could > > improve general performance of PHP applications and easw deployment. > > > > Allowing only one namespace per file will obviously kill this approach. > > So if there is there a chance of allowing a namespace in braces, it > > would be great if you could make this possible. > > > > Kind regards, > > > > Stefan > > I would also prefer a braces-based namespace approach. Namespace > organization > and file organization do not always match 1:1, especially if you're doing > function-based programming rather than OO. Being able to put 2 namespaces > in > one file would add a great deal of flexibility, stat-count aside. > > -- > Larry Garfield AIM: LOLG42 > larry@garfieldtech.com ICQ: 6817012 > > "If nature has made any one thing less susceptible than all others of > exclusive property, it is the action of the thinking power called an idea, > which an individual may exclusively possess as long as he keeps it to > himself; but the moment it is divulged, it forces itself into the > possession > of every one, and the receiver cannot dispossess himself of it." -- > Thomas > Jefferson > > -- > PHP Internals - PHP Runtime Development Mailing List > To unsubscribe, visit: http://www.php.net/unsub.php > >
-- Nicolas Bérard-Nault (nicobn@gmail.com) Étudiant D.E.C. Sciences, Lettres & Arts Cégep de Sherbrooke Homepage: http://nicobn.googlepages.com

Dmitry Stogov

19 years ago
Note that multiple files in namespace won't allow autoloading. Dmitry.

Dmitry Stogov

19 years ago
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 namespaces and files to much so with modified APC you can cache multiple files at once. You can also use something like PHAR that is made especially for deployment. Thanks. Dmitry.

Stanislav Malyshev

19 years ago
> 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 performance of both > apporaches, but I have a feeling that the "single binary" approach will > be faster. As APC will be part of PHP6, I think this approach could
I don't think "one binary" approach makes sense for PHP. PHP application is usually composed of many files, some of them are library files not used at all, some are rarely used, etc. Also, this approach does not allow to change individual files without having all the system lose performance significantly.
-- Stanislav Malyshev, Zend Software Architect stas@zend.com http://www.zend.com/ (408)253-8829 MSN: stas@zend.com

Stefan Priebsch

19 years ago
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" approach makes sense for PHP. PHP application > is usually composed of many files, some of them are library files not > used at all, some are rarely used, etc. Also, this approach does not > allow to change individual files without having all the system lose > performance significantly.
I wouldn't want to make it a new standard, but I'd say there could be a use for it. You could deploy a PHP application like a statically linked binary without external dependencies. That means, for example, no problems when "wrong" versions of external libraries are loaded because of an unexpected include path etc. Also, it is easier to ensure the application's integrity, because users cannot easily change or swap out a single file. 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 benchmark it. Kind regards, Stefan
-- >e-novative> - We make IT work for you. e-novative GmbH - HR: Amtsgericht München HRB 139407 Sitz: Wolfratshausen - GF: Dipl. Inform. Stefan Priebsch http://www.e-novative.de

Stanislav Malyshev

19 years ago
> Does this mean that a project like Phorum could declare the same > namespace at the top of all of our files and all the code in those files > would exist in the same namespace?
Theoretically, yes, that's the idea. Practically there could be some problems with variable names - right now the patch does not resolve names, so if you do $name = "func", $name("foo"); it might not work, you'd need to use __NAMESPACE__ currently. I'm not sure how much of a trouble it is.
> Or, would list.php have to import the Phorum namespace?
no, no import is necessary for same-namespace references.
> Also, I don't see any mention of variables in namespaces. Will there be > no effect on variables?
No namespace variables, right. For grouping variables you have arrays and classes, should be good enough ;)
-- Stanislav Malyshev, Zend Software Architect stas@zend.com http://www.zend.com/ (408)253-8829 MSN: stas@zend.com

Stefan Priebsch

19 years ago
Hi Dmitry, it would be great to have namespaces in PHP6, as these always longer-getting classnames are somewhat annoying. I don't want to start a discussion about the separator (I think there was one before), but:
> > 6) Calls to qualified functions are resolved at run-time. Call to > > "A::B::foo()" first tries to call function foo() from namespace
"A::B", then
> > it tries to find class "A::B (__autoload() it if necessary) and call its > > static function foo()
If I am not mislead this ambiguity is due to the fact that :: is the namespace separator? If, so I'd rather suggest changing the separator, because one could alter the program's behaviour by adding a function foo() to a namespace thus making PHP call this function instead of the method. Besides, a lot of less experiences programmers would not be sure when which function/method is actually called.
> > All class and function names inside are automatically prefixed with > > namespace name. Inside namespace, local name always takes precedence
over
> > global name. It is possible to use the same namespace in several PHP
files.
> > The namespace declaration statement must be the very first statement in > > file.
I take it that when I include or conditionally include, the included file has its own namespace, if one is declared in that file. What if I do not declare a namespace in an include file? Does this file "inherit" the current namespace or are the contents added to the global namespace?
> > point of definition down to the end of file. It is recommended
however to
> > place imports at the beginning of the file. Import statements have
effect
> > only on file where they are written.
Could this result in name conflicts when including files that have their own import statements?
> > 4) calls to unqualified functions that are not defined in current
namespace
> > are resolved in run-time. The call to function foo() inside namespace
(A::B)
> > first tries to find and call function from current namespace
A::B::foo() and
> > if it doesn't exist PHP tries to call internal function foo(). Note that > > using foo() in namespace you can call only internal PHP functions,
however
> > using ::foo() you are able to call any function from global namespace.
Does this mean that a programmer could "override" an internal PHP function, possibly accidentally? Kind regards, Stefan
-- >e-novative> - We make IT work for you. e-novative GmbH - HR: Amtsgericht München HRB 139407 Sitz: Wolfratshausen - GF: Dipl. Inform. Stefan Priebsch http://www.e-novative.de

Stanislav Malyshev

19 years ago
> I take it that when I include or conditionally include, the included > file has its own namespace, if one is declared in that file. What if I > do not declare a namespace in an include file? Does this file "inherit" > the current namespace or are the contents added to the global namespace?
No, namespaces are per-file. No namespace means global namespace. Non-local namespaces can be very problematic for bytecode caches since it would not be possible to know "true" names of the classes per-file and actually same file could generate very different names.
> Could this result in name conflicts when including files that have their > own import statements?
Note that import defines local (per-file) name transformation. I.e. if you do import Zend::Some::Class as Myclass, it means in this file, once you say Myclass, you actually mean Zend::Some::Class. But it should not have any effects on other files.
> Does this mean that a programmer could "override" an internal PHP > function, possibly accidentally?
Yes, it would be possible to "override" internal functions in namespace. I don't think it's too much of a problem - tools can deal with it.
-- Stanislav Malyshev, Zend Software Architect stas@zend.com http://www.zend.com/ (408)253-8829 MSN: stas@zend.com

Derick Rethans

19 years ago
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 http://derickrethans.nl | http://ez.no | http://xdebug.org

Andrei Zmievski

19 years ago
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:

Dmitry Stogov

19 years ago
declare(encoding=...) may be used befor or right after namespace declaration. Dmitry.

chris#

19 years ago
On Mon, 9 Jul 2007 20:13:23 +0200 (CEST), Derick Rethans <derick@php.net> 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);" > statement? Which of the two needs to be first, and which second?
And what of header(); ?
> > regards, > Derick > > -- > Derick Rethans > http://derickrethans.nl | http://ez.no | http://xdebug.org > > -- > PHP Internals - PHP Runtime Development Mailing List > To unsubscribe, visit: http://www.php.net/unsub.php
///////////////////////////////////////////////////// Service provided by hitOmeter.NET internet messaging! .

=?ISO-8859-1?Q?Nicolas_B=E9rard-Nault?=

19 years ago
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# <chris#@codewarehouse.net> wrote:
> > > > > On Mon, 9 Jul 2007 20:13:23 +0200 (CEST), Derick Rethans <derick@php.net> > 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);" > > statement? Which of the two needs to be first, and which second? > And what of header(); ? > > > > regards, > > Derick > > > > -- > > Derick Rethans > > http://derickrethans.nl | http://ez.no | http://xdebug.org > > > > -- > > PHP Internals - PHP Runtime Development Mailing List > > To unsubscribe, visit: http://www.php.net/unsub.php > ///////////////////////////////////////////////////// > Service provided by hitOmeter.NET internet messaging! > . > > -- > PHP Internals - PHP Runtime Development Mailing List > To unsubscribe, visit: http://www.php.net/unsub.php > >
-- Nicolas Bérard-Nault (nicobn@gmail.com) Étudiant D.E.C. Sciences, Lettres & Arts Cégep de Sherbrooke Homepage: http://nicobn.googlepages.com

chrish

19 years ago
On Mon, 9 Jul 2007 16:40:09 -0400, "Nicolas Bérard-Nault" <nicobn@php.net> 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. Thanks again.
> > On 7/9/07, chris# <chris#@codewarehouse.net> wrote: >> >> >> >> >> On Mon, 9 Jul 2007 20:13:23 +0200 (CEST), Derick Rethans > <derick@php.net> >> 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);" >> > statement? Which of the two needs to be first, and which second? >> And what of header(); ? >> > >> > regards, >> > Derick >> > >> > -- >> > Derick Rethans >> > http://derickrethans.nl | http://ez.no | http://xdebug.org >> > >> > -- >> > PHP Internals - PHP Runtime Development Mailing List >> > To unsubscribe, visit: http://www.php.net/unsub.php >> ///////////////////////////////////////////////////// >> Service provided by hitOmeter.NET internet messaging! >> . >> >> -- >> PHP Internals - PHP Runtime Development Mailing List >> To unsubscribe, visit: http://www.php.net/unsub.php >> >> > > >
///////////////////////////////////////////////////// Service provided by hitOmeter.NET internet messaging! .

chris#

19 years ago
On Mon, 9 Jul 2007 16:40:09 -0400, "Nicolas Bérard-Nault" <nicobn@php.net> 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. Thanks again.
> > On 7/9/07, chris# <chris#@codewarehouse.net> wrote: >> >> >> >> >> On Mon, 9 Jul 2007 20:13:23 +0200 (CEST), Derick Rethans > <derick@php.net> >> 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);" >> > statement? Which of the two needs to be first, and which second? >> And what of header(); ? >> > >> > regards, >> > Derick >> > >> > -- >> > Derick Rethans >> > http://derickrethans.nl | http://ez.no | http://xdebug.org >> > >> > -- >> > PHP Internals - PHP Runtime Development Mailing List >> > To unsubscribe, visit: http://www.php.net/unsub.php >> ///////////////////////////////////////////////////// >> Service provided by hitOmeter.NET internet messaging! >> . >> >> -- >> PHP Internals - PHP Runtime Development Mailing List >> To unsubscribe, visit: http://www.php.net/unsub.php >> >> > > >
///////////////////////////////////////////////////// Service provided by hitOmeter.NET internet messaging! .

Dmitry Stogov

19 years ago
header() is a regular function, you can call it from anywhere (e.q. as top-level statement), butof course you cannot use it before namespace declaration. <?php namespace HTTP::Connection; header('Connection: close'); ?> Dmitry.