Re: [PHP-DEV] Simple Namespace Proposal
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 created a benchmark that allows to compare conditional/unconditional include with and without opcode cache? I'm working on some PHP benchmarks like this, and would really appreciate any pointer to existing work in this area. 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 -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
RE: [PHP-DEV] Simple Namespace Proposal
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. > -Original Message- > From: Stefan Priebsch [mailto:[EMAIL PROTECTED] > Sent: Saturday, 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 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 > -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
RE: [PHP-DEV] Simple Namespace Proposal
> 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,
>
> 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
>
> --
> 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
RE: [PHP-DEV] Simple Namespace Proposal
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 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 GarfieldAIM: LOLG42 > [EMAIL PROTECTED] 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 > -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
RE: [PHP-DEV] Simple Namespace Proposal
-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. Dmitry. > -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: > > +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]. > > -- > [1] > http://java.sun.com/docs/books/jls/third_edition/html/packages.html > [2] http://www.jaggersoft.com/csharp_standard/8.12.htm > > -- > Sebastian Bergmann > http://sebastian-bergmann.de/ > GnuPG Key: 0xB85B5D69 / 27A7 2B14 09E4 98CD 6277 0E5B 6867 > C514 B85B 5D69 > > -- > 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
Re: [PHP-DEV] Simple Namespace Proposal
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 [EMAIL PROTECTED] http://www.zend.com/ (408)253-8829 MSN: [EMAIL PROTECTED] -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Simple Namespace Proposal
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 [EMAIL PROTECTED] http://www.zend.com/ (408)253-8829 MSN: [EMAIL PROTECTED] -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] RIP PHP 4?
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 too :) Now we only need to choose a suitable timezone :) -- Stanislav Malyshev, Zend Software Architect [EMAIL PROTECTED] http://www.zend.com/ (408)253-8829 MSN: [EMAIL PROTECTED] -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] RIP PHP 4?
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 declare official PHP 4 end-of-life > to be on 8:08:08 pm too :) Now we only need to choose a suitable timezone :) GMT+8 of course... Derick -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] Why not skip libc for _all_ random functions?
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 speed. So basically what I am saying is this: Implement the mersenne twister in the back of all random functions. 1. Make rand() an alias to mt_rand() 2. Make srand() an alias to mt_srand() 3. Make getrandmax() an alias to mt_getrandmax() 4. Have array_rand() implement MT in the back (if it is not doing so already) However, I am not a C-coder. I can not help out in this task myself, but thinks it makes sense and could be quite easy to do - for someone that do knows how to C. Lars Gunther P.S. For an introduction to who I am one might read: http://www.webstandards.org/action/edutf/interviews/gunther-en/ and look at http://www.flickr.com/photos/keryxgunther/143376264/ -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Simple Namespace Proposal
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 trick
in my case, though, since would need to calculate a fully-qualified name
from *outside* the current namespace. BUT:
> 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.
Right. As I said before, I'd like to have this if it is not difficult to
do. Given the recent discussion with Rasmus about caching I think that y
original idea of glueing together files to improve performance will go
down the drain anyway. Bottom line: I'm with you.
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
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Simple Namespace Proposal
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 -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] RIP PHP 4?
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 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 too :) Now we only need to choose a suitable timezone :) > > GMT+8 of course... Which, appropriately enough, includes China. So: support for PHP4 ends when the Olympics start. http://upload.wikimedia.org/wikipedia/commons/3/3d/Timezones_optimized.png -- Alain Williams Linux Consultant - Mail systems, Web sites, Networking, Programmer, IT Lecturer. +44 (0) 787 668 0256 http://www.phcomp.co.uk/ Parliament Hill Computers Ltd. Registration Information: http://www.phcomp.co.uk/contact.php #include -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] RIP PHP 4?
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 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 too :) Now we only need to choose a suitable timezone :) GMT+8 of course... Which, appropriately enough, includes China. So: support for PHP4 ends when the Olympics start. one day porting to the next major version of PHP will be olympic ;) regards, Lukas -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] RIP PHP 4?
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 this event. Lars Gunther -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Simple Namespace Proposal
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 namespace. If we can't do that then we're back to using static classes
as if they were namespaces.
On Sunday 08 July 2007, 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.
>
> namespace A::B {
>
> function foo() {
> }
>
> }
>
> function bar() {
> }
> ?>
>
> Dmitry.
>
> > -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:
> > > +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].
> >
> > --
> > [1]
> > http://java.sun.com/docs/books/jls/third_edition/html/packages.html
> > [2] http://www.jaggersoft.com/csharp_standard/8.12.htm
> >
> > --
> > Sebastian Bergmann
> > http://sebastian-bergmann.de/
> > GnuPG Key: 0xB85B5D69 / 27A7 2B14 09E4 98CD 6277 0E5B 6867
> > C514 B85B 5D69
> >
> > --
> > PHP Internals - PHP Runtime Development Mailing List
> > To unsubscribe, visit: http://www.php.net/unsub.php
--
Larry Garfield AIM: LOLG42
[EMAIL PROTECTED] 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
RE: [PHP-DEV] Simple Namespace Proposal
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 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 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 namespace. If we can't do that then we're back to using static classes
as if they were namespaces.
On Sunday 08 July 2007, 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.
>
> namespace A::B {
>
> function foo() {
> }
>
> }
>
> function bar() {
> }
> ?>
>
> Dmitry.
>
> > -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:
> > > +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].
> >
> > --
> > [1]
> > http://java.sun.com/docs/books/jls/third_edition/html/packages.html
> > [2] http://www.jaggersoft.com/csharp_standard/8.12.htm
> >
> > --
> > Sebastian Bergmann
> > http://sebastian-bergmann.de/
> > GnuPG Key: 0xB85B5D69 / 27A7 2B14 09E4 98CD 6277 0E5B 6867
> > C514 B85B 5D69
> >
> > --
> > PHP Internals - PHP Runtime Development Mailing List
> > To unsubscribe, visit: http://www.php.net/unsub.php
--
Larry Garfield AIM: LOLG42
[EMAIL PROTECTED] 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
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Simple Namespace Proposal
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 benchmark it. > > Kind regards, > > Stefan Some incomplete data: I work mostly on Drupal, and in the next version we're splitting up the code base into a lot more smaller files that we can load conditionally. The benchmarks we've done so far indicate that without an opcode cache there's a huge benefit in speed from not loading/parsing code that we're not going to be using (there's a lot of it at this point) as well as a sizable reduction in RAM usage. With an opcode cache the speed difference is negligible, but I believe there's still a RAM savings per-process. More on that when we've completed the process. So it all depends on your caching configuration and use-case. Loading a ton of code that you never use is not good for performance. -- Larry Garfield AIM: LOLG42 [EMAIL PROTECTED] 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
Re: [PHP-DEV] Simple Namespace Proposal
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 the countless other languages that already have this functionality. You're gimping the language further if you And take look around at languages that don't - such as Python. Or Perl, that though allows using package declaration in any block multiple times, almost always uses it the same way we do, and even when it doesn't it easily could. Or Java. I think we need to officially declare "If it's not my way PHP is not a real language" nonargument and automatically post monthly reminder of that. I'm sure there are better arguments for any position. -- Stanislav Malyshev, Zend Software Architect [EMAIL PROTECTED] http://www.zend.com/ (408)253-8829 MSN: [EMAIL PROTECTED] -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] RIP PHP 4?
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 speak and write about this event. Except no real geek would schedule anything for 8am. -R -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Simple Namespace Proposal
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 be useful. I don't want it "my way" and I'm sure everybody not against braces wants it "their way", we want to be able to choose which way we'd like to use. Must we say please for that ? If it's the case: please ! ;-). Alright, I'm out of this discussion. On 7/8/07, Stanislav Malyshev <[EMAIL PROTECTED]> wrote: > 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 the countless other languages that already > have this functionality. You're gimping the language further if you And take look around at languages that don't - such as Python. Or Perl, that though allows using package declaration in any block multiple times, almost always uses it the same way we do, and even when it doesn't it easily could. Or Java. I think we need to officially declare "If it's not my way PHP is not a real language" nonargument and automatically post monthly reminder of that. I'm sure there are better arguments for any position. -- Stanislav Malyshev, Zend Software Architect [EMAIL PROTECTED] http://www.zend.com/ (408)253-8829 MSN: [EMAIL PROTECTED] -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php -- Nicolas Bérard-Nault ([EMAIL PROTECTED]) Étudiant D.E.C. Sciences, Lettres & Arts Cégep de Sherbrooke Homepage: http://nicobn.googlepages.com
Re: [PHP-DEV] RIP PHP 4?
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 this event. > > Except no real geek would schedule anything for 8am. Easy. Schedule it for 8am in China. Do it in Canada, UK or Israel. :) -- Tomas -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] RIP PHP 4?
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 otherwise will be 20:08:08 when we speak and write about this event. > > Except no real geek would schedule anything for 8am. Easy. Schedule it for 8am in China. Do it in Canada, UK or Israel. :) What about 8/8/8 8pm in china and 01/01/08 Canada, UK, USA.. that way we can get rid of it quickly and if it's meaningful for chinese people to use the number 8, we can do it on 8/8/8 for them (irony/joke) ? Seriously.. I don't really see the point in keeping it for another year.. imho end of the year is great and more than enough time to upgrade, we've got to cut the cord sometimes.. why not keep it until 9/9/9 since it's 6/6/6 upside down and means the devil.. the end of things.. could also be the end of php4 -- Tomas -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php D -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
RE: [PHP-DEV] RIP PHP 4?
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 end-of-life coming up. Andi > -Original Message- > From: [EMAIL PROTECTED] > [mailto:[EMAIL PROTECTED] On Behalf Of David Coallier > Sent: Sunday, July 08, 2007 2:21 PM > To: Tomas Kuliavas > Cc: internals@lists.php.net > Subject: Re: [PHP-DEV] RIP PHP 4? > > 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 otherwise will be 20:08:08 when we speak > and write about this event. > > > > > > Except no real geek would schedule anything for 8am. > > > > Easy. Schedule it for 8am in China. Do it in Canada, UK or > Israel. :) > > > > What about 8/8/8 8pm in china and 01/01/08 Canada, UK, USA.. > that way we can get rid of it quickly and if it's meaningful > for chinese people to use the number 8, we can do it on 8/8/8 > for them (irony/joke) ? > Seriously.. I don't really see the point in keeping it for > another year.. imho end of the year is great and more than > enough time to upgrade, we've got to cut the cord sometimes.. > why not keep it until > 9/9/9 since it's 6/6/6 upside down and means the devil.. the > end of things.. could also be the end of php4 > > > > > -- > > Tomas > > > > -- > > PHP Internals - PHP Runtime Development Mailing List To > unsubscribe, > > visit: http://www.php.net/unsub.php > > > > > > > D > > -- > 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
Re: [PHP-DEV] RIP PHP 4?
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 end-of-life coming up. Andi But after PHP4 is dropped, people can still use it, so if people really need to use it longer then they can just continue using it, once they are done they can still move on. Tijnema > -Original Message- > From: [EMAIL PROTECTED] > [mailto:[EMAIL PROTECTED] On Behalf Of David Coallier > Sent: Sunday, July 08, 2007 2:21 PM > To: Tomas Kuliavas > Cc: internals@lists.php.net > Subject: Re: [PHP-DEV] RIP PHP 4? > > 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 otherwise will be 20:08:08 when we speak > and write about this event. > > > > > > Except no real geek would schedule anything for 8am. > > > > Easy. Schedule it for 8am in China. Do it in Canada, UK or > Israel. :) > > > > What about 8/8/8 8pm in china and 01/01/08 Canada, UK, USA.. > that way we can get rid of it quickly and if it's meaningful > for chinese people to use the number 8, we can do it on 8/8/8 > for them (irony/joke) ? > Seriously.. I don't really see the point in keeping it for > another year.. imho end of the year is great and more than > enough time to upgrade, we've got to cut the cord sometimes.. > why not keep it until > 9/9/9 since it's 6/6/6 upside down and means the devil.. the > end of things.. could also be the end of php4 > > > > > -- > > Tomas > > > > -- > > PHP Internals - PHP Runtime Development Mailing List To > unsubscribe, > > visit: http://www.php.net/unsub.php > > > > > > > D > > -- > 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 -- Vote for PHP Color Coding in Gmail! -> http://gpcc.tijnema.info -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] CVS Account Request: bugra
Greetings, I'm using Php over 5 years and I really would like to help translation of Php Documentation. As far as i see there is a lot of work in Turkish Documentation (it is even not in the list), so i decided to spend my spare time for translating, besides I can use both English and Turkish fluently. Best regards, Bugra Yazar -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] RIP PHP 4?
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 year some time. The PHP dev team, however, has a different set of targets. It has to include distros and business servers. A longer warning period is sensible. Which of course means that the sooner an EOL date is announced, the sooner PHP 4 can be retired. :-) Sometime next summer sounds reasonable, and I've no problem whatsoever with kitch dates[1]. [1] http://gophp5.org/faq#n9 On Sunday 08 July 2007, Andi Gutmans 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 end-of-life coming up. > Andi > > > -Original Message- > > From: [EMAIL PROTECTED] > > [mailto:[EMAIL PROTECTED] On Behalf Of David Coallier > > Sent: Sunday, July 08, 2007 2:21 PM > > To: Tomas Kuliavas > > Cc: internals@lists.php.net > > Subject: Re: [PHP-DEV] RIP PHP 4? > > > > 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 otherwise will be 20:08:08 when we speak > > > > and write about this event. > > > > > > Except no real geek would schedule anything for 8am. > > > > > > Easy. Schedule it for 8am in China. Do it in Canada, UK or > > > > Israel. :) > > > > > > What about 8/8/8 8pm in china and 01/01/08 Canada, UK, USA.. > > that way we can get rid of it quickly and if it's meaningful > > for chinese people to use the number 8, we can do it on 8/8/8 > > for them (irony/joke) ? > > Seriously.. I don't really see the point in keeping it for > > another year.. imho end of the year is great and more than > > enough time to upgrade, we've got to cut the cord sometimes.. > > why not keep it until > > 9/9/9 since it's 6/6/6 upside down and means the devil.. the > > end of things.. could also be the end of php4 > > > > > -- > > > Tomas > > > > > > -- > > > PHP Internals - PHP Runtime Development Mailing List To > > > > unsubscribe, > > > > > visit: http://www.php.net/unsub.php > > > > D > > > > -- > > PHP Internals - PHP Runtime Development Mailing List To > > unsubscribe, visit: http://www.php.net/unsub.php -- Larry Garfield AIM: LOLG42 [EMAIL PROTECTED] 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
RE: [PHP-DEV] RIP PHP 4?
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 PHP 4? > > 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 > end-of-life coming up. > > Andi > > But after PHP4 is dropped, people can still use it, so if > people really need to use it longer then they can just > continue using it, once they are done they can still move on. > > Tijnema > > > > > -Original Message- > > > From: [EMAIL PROTECTED] > > > [mailto:[EMAIL PROTECTED] On Behalf Of David Coallier > > > Sent: Sunday, July 08, 2007 2:21 PM > > > To: Tomas Kuliavas > > > Cc: internals@lists.php.net > > > Subject: Re: [PHP-DEV] RIP PHP 4? > > > > > > 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 otherwise will be 20:08:08 when we speak > > > and write about this event. > > > > > > > > > > Except no real geek would schedule anything for 8am. > > > > > > > > Easy. Schedule it for 8am in China. Do it in Canada, UK or > > > Israel. :) > > > > > > > > > > What about 8/8/8 8pm in china and 01/01/08 Canada, UK, USA.. > > > that way we can get rid of it quickly and if it's meaningful for > > > chinese people to use the number 8, we can do it on 8/8/8 > for them > > > (irony/joke) ? > > > Seriously.. I don't really see the point in keeping it > for another > > > year.. imho end of the year is great and more than enough time to > > > upgrade, we've got to cut the cord sometimes.. > > > why not keep it until > > > 9/9/9 since it's 6/6/6 upside down and means the devil.. > the end of > > > things.. could also be the end of php4 > > > > > > > > > > > -- > > > > Tomas > > > > > > > > -- > > > > PHP Internals - PHP Runtime Development Mailing List To > > > unsubscribe, > > > > visit: http://www.php.net/unsub.php > > > > > > > > > > > > > > > > > D > > > > > > -- > > > 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 > > > > > > > -- > Vote for PHP Color Coding in Gmail! -> http://gpcc.tijnema.info > -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] RIP PHP 4?
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 Debian or BSD setups (have been used a 4.3 or 4.2 in the last months). Some Linux distributors will certainly take care of php5 for an even longer period. It is not really important if it is one year or six months (not like php4 gives us a lot of work :), my preference still goes to the end of this year. From my point of view, the year is merely a marketing argument, if it helps us to get a better image, why not... --Pierre -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] RIP PHP 4?
On 7/9/07, Pierre <[EMAIL PROTECTED]> wrote: That's the ideal world. Unfortunately yes. They should really not use it anymore but they can and they will. No matter what we do. Right. Some Linux distributors will certainly take care of php5 for an even longer period. Yes, about 6 or 7 years more. It is not really important if it is one year or six months (not like php4 gives us a lot of work :), my preference still goes to the end of this year. From my point of view, the year is merely a marketing argument, if it helps us to get a better image, why not... IMHO this should be done this way 1. Announce **clearly** that PHP4 has reached EOL ASAP. 2. Stop any kind of non-security bugfixing **inmediately** ( well. that is happening now anyway, :-) ) This include marking as wont fix all the opened PHP4 bug reports and removing PHP4 from the version list in the bugtracker as well adding a warning in the bug report form about this. 3. Move PHP4 releases to the Museum ASAP. 4. gave users a reasonable time to discontinue security fixes (no less that 8 months IMHO) also state clearly that this covers only critical security bugs. 5. Fix the documentation, the migration to PHP5 documents are missing many backward incompatible changes. just as an example. http://php.net/manual/en/migration5.incompatible.php does not list the fact that you cannot reasign $this and that unset($this) does nothing. there are many others. 6. finally people will attempt to use backward compatibilty hacks like the horrendous and non-working like zend.ze1_compatibility_mode, it is very important to either fix it or remove it ( I suggest removing it) , there are many extensions that dont even work or crash with it enabled. my $2 chilean pesos. -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
RE: [PHP-DEV] Simple Namespace Proposal
> -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 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?
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.
Dmitry.
>
> > function namespace_name($name) {
> > return __NAMESPACE__ . "::" . $name;
> >}
> Thanks for posting this - I am not sure wether this would do
> the trick in my case, though, since would need to calculate a
> fully-qualified name from *outside* the current namespace. BUT:
>
>
> > 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.
> Right. As I said before, I'd like to have this if it is not
> difficult to do. Given the recent discussion with Rasmus
> about caching I think that y original idea of glueing
> together files to improve performance will go down the drain
> anyway. Bottom line: I'm with you.
>
>
> 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
>
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] RIP PHP 4?
With the benefit of a lot of reading in this thread... And not sure my vote even counts. +1 PHP4 link to museum +1 Announce ASAP "security fixes only until 8/8/8" It is not "abandoning" users, at this point, to do this, imho. They've had years to switch to PHP 5. They've got another years' worth of legacy security-only support. PHP 5 is stable enough and easy enough to switch to, for 99.99% of the code-base, that only inertia keeps most of these folks on PHP 4. I don't think it's wise to tie it to PHP 6 release. That sets a bad precedent. What if PHP 8 takes "forever" to get released, and PHP 6 *needs* to die? The only real thing to tie it to is the availability of a stable next release, and a reasonable "do or die" time-frame to migrate. -- Some people have a "gift" link here. Know what I want? I want you to buy a CD from some indie artist. http://cdbaby.com/browse/from/lynch Yeah, I get a buck. So? -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
