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
Re: [PHP-DEV] Simple Namespace Proposal
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 guess we can say a lot of PHP developers would like to have the choice, too. I believe we should stop trying to find a solution to a problem that should not be solved by us in the first place. Let it be my choice, however right or wrong it may seem, to obey the standard which seems fit to me, thank you. P.S.: This opinion only applies to this particular case. Generally speaking, I'm all for a loosely defined PHP way. On 7/8/07, Sebastian Bergmann [EMAIL PROTECTED] wrote: 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 -- 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] 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.
?php
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
--
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 std_disclaimer.h -- 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.
?php
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.
?php
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?
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?
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
