RE: [PHP-DEV] Renaming namespaces to packages
Hi, We are still working on namespace concept and its features. I am not sure that existing concept will work well as is. So please, don't make us additional troubles. The name is important but it may be changed later, first look into concept itself. Do you completely satisfied with it? Have you tried to use it in real life applications or frameworks? Have you measured slowdown? Do you see holes in concept? These questions are more important then the name... BTW: I personally would accept 'package' for current implementation, but in the future we would need to rename it back :) Thanks. Dmitry. -Original Message- From: Johannes Schlьter [mailto:[EMAIL PROTECTED] Sent: Thursday, August 16, 2007 10:14 PM To: Dmitry Stogov Cc: 'PHP Internals List' Subject: RE: [PHP-DEV] Renaming namespaces to packages Hi, On Thu, 2007-08-16 at 09:33 +0400, Dmitry Stogov wrote: At least, I have one additional namespace related patch, that is not accepted yet. Renaming may require a lot of additional work with it. Well, in my experience it's simpler to do such renaming inside an patch (then it's a simple sed command) than after committing it to the tree where you have to make sure not to accidentally rename other, unrelated, stuff, too. That's the reason why I tried to do the renaming asap. Also, I am not sure that allbody agree with package. I didn't read all mails in that thread but from what I saw only Stanislaw was against renaming it. I for myself don't care really much about the name, but I tend to follow Marcus's argumentation[1] for package, it tastes a bit better for me. What I would like is a soonish decision so we can advertise that feature and get people testing it and playing with it without having to fear that their (test-)code breaks the next day. (I didn't say it won't brake the next day then, but it's good to give less excuses for not testing that stuff. This testing would also include mysqlnd, unicode and whatever else we have in HEAD right now) johannes [1] http://news.php.net/php.internals/31328 Thanks. Dmitry. -Original Message- From: Derick Rethans [mailto:[EMAIL PROTECTED] Sent: Wednesday, August 15, 2007 10:25 PM To: Dmitry Stogov Cc: 'PHP Internals List' Subject: RE: [PHP-DEV] Renaming namespaces to packages On Fri, 10 Aug 2007, Dmitry Stogov wrote: I have no serious objections about renaming. I am asking to wait a bit. If you think package is fine, why wait with renaming it? 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
Re: [Fwd: Re: [PHP-DEV] Renaming namespaces to packages]
I've been reading this lengthy discussion and here's a sumup of what I found: - PHP's implementation is only a part of what most people expect to find when they hear php has namespace support - PHP's implementation looks a bit like JAVA's package support, and a bit like many other (differently names) features in other languages. It however does not match 1:1 to any of those. So, everyone here has agreed already that namespaces !=== PHP's implementation (it might ==, but not ===). Same goes for Package. I find the idea of Greg to be very good though, reading the original proposal, it often names things not namespace but simply prefix. What do you do with your names? you use a prefix, you don't expect it to have full namespace support just like [insert any other language here], nor do you expect it to be exactly like a JAVA package. When announced, you could simply state PHP now has support for prefixing, PHP's own specific implementation of namespaces. Because that's what you have, you can complain that according to the definition of [word] it _is_ that., but you can't really. The definition of a word like namespace, package, etc. is not independent of its implementation in majorly used languages unfortunately. If you ask a random coder what is a namespace, the answer will always be based on an implementation in a language the person uses/likes a lot. You can quote from wikipedia, but that doesn't really mean anything (sorry Stas), what we should try to do here is find the proper name which identifies the implementation we have for what it is. prefix Foo; alias Foo:Bar as Quux; Looks very good to me as it clearly shows what happens, internally and externally. It's not a namespace as such, it's not a package as such, it's simply what PHP _does_. I hope this will help the discussion steer away from the standard arguments that have been used constantly, and that will simply not change. - Tul Gregory Beaver wrote: Hi, All of the debate over whether this is a true namespace implementation is in my opinion completely bogus (translate: I think namespace is a fine choice for the reserved word, and package is a dangerously misleading choice), but since there is so much noisy dissent, I have an alternative proposal I'd like to float: How about using the keyword prefix or nameprefix instead of namespace? This will be clearer and can be easily defined with 2 sentences similar to the original proposal: All class and function names inside the file are automatically prefixed with the (prefix|nameprefix) name. In other files, classes and functions can be imported with different names (aliases) to eliminate naming conflicts or reduce typing needed. I quote from the original Simple Namespace Proposal message by Dmitry: From the beginning: 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. From the middle: Namespace definition does the following: All class and function names inside are automatically prefixed with namespace name. As stated, because this proposal *only* defines a prefix for functions and class names, it is not a packaging model. All package models in existence define some kind of self-contained entity that groups related *files* and their contents together in a way that allows them to be packaged into a single thing, like a jar, a PEAR .tgz, or a .phar file. This proposal does none of these things. Simply because the prefix is defined per-file does not a package make. By the same logic, using .php at the end of a file or .dat at the end of a file creates special packages of php or dat information, because the extension applies to the whole file at once. Simply defining the contents of a file does not imply any organization whatsoever. What the original proposal *does* do is provide a namespace prefix - it defines a scope within which all names have a special prefix. This is not rocket science. rantOn a personal note, if you feel you must reply to this thread further, please follow this checklist: 1) is anything I am saying bring a new idea to the debate? 2) is there a patch that converts my new idea into a reality attached to the message? If you can't answer yes to either of these, please go immediately to jail, do not pass go, do not collect $200./rant Thank you to Dmitry for this much-needed idea. Thanks, Greg -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Re: #40581 [Opn-Asn]: Pass Struct type to COM object from PHP
On 8/17/07, Andy Wharmby [EMAIL PROTECTED] wrote: Hi Pierre Sorry been very busy on other things in last few months and so have not had the time to give COM any TLC. I will do my best to find some time in the coming weeks to work on some of the outstanding COM defects and of course when I do so I will look at all the outstanding COM defects; whether OPEN or assigned to Wez. There is no hurry (all about freetime) :) The goal of this mail was to send you a notice about the bugs assigned to Wez. As long as it is about com/dotnet, you can freely take the hand on them. Thanks for your work! --Pierre -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [Fwd: [PHP-CVS] cvs: php-src /ext/standard formatted_print.c]
Ilia? Greg? Any comments? On 14.08.2007 15:42, Antony Dovgal wrote: This patch breaks PEAR phar install on 64bit. From what I can see in the source code, it compares data in the phar with the result of sprintf(%u..), which is different on 32bit and 64bit because of this patch. Either phar should be changed to detect this situation or this patch should be reverted. Original Message Subject: [PHP-CVS] cvs: php-src /ext/standard formatted_print.c Date: Sun, 03 Jun 2007 09:11:52 - From: Brian Shire [EMAIL PROTECTED] To: [EMAIL PROTECTED] shire Sun Jun 3 09:11:52 2007 UTC Modified files: /php-src/ext/standard formatted_print.c Log: Change printf %u behavior so that it does not truncate numbers at 32-bits. (Reported by Aditya Agarwal.) http://cvs.php.net/viewvc.cgi/php-src/ext/standard/formatted_print.c?r1=1.100r2=1.101diff_format=u Index: php-src/ext/standard/formatted_print.c diff -u php-src/ext/standard/formatted_print.c:1.100 php-src/ext/standard/formatted_print.c:1.101 --- php-src/ext/standard/formatted_print.c:1.100Thu May 17 17:29:09 2007 +++ php-src/ext/standard/formatted_print.c Sun Jun 3 09:11:52 2007 @@ -16,7 +16,7 @@ +--+ */ -/* $Id: formatted_print.c,v 1.100 2007/05/17 17:29:09 tony2001 Exp $ */ +/* $Id: formatted_print.c,v 1.101 2007/06/03 09:11:52 shire Exp $ */ #include math.h/* modf() */ #include php.h @@ -278,7 +278,7 @@ PRINTF_DEBUG((sprintf: appenduint(%x, %x, %x, %d, %d, '%c', %d)\n, *buffer, pos, size, number, width, padding, alignment)); - magn = (unsigned int) number; + magn = (unsigned long) number; /* Can't right-pad 0's on integers */ if (alignment == 0 padding == '0') padding = ' '; -- Wbr, Antony Dovgal -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [Fwd: [PHP-CVS] cvs: php-src /ext/standard formatted_print.c]
I think the C behaviour is correct and we need to make a (hopefully) slight adjustment to the pear installer code. On 17-Aug-07, at 8:14 AM, Antony Dovgal wrote: Ilia? Greg? Any comments? On 14.08.2007 15:42, Antony Dovgal wrote: This patch breaks PEAR phar install on 64bit. From what I can see in the source code, it compares data in the phar with the result of sprintf(%u..), which is different on 32bit and 64bit because of this patch. Either phar should be changed to detect this situation or this patch should be reverted. Original Message Subject: [PHP-CVS] cvs: php-src /ext/standard formatted_print.c Date: Sun, 03 Jun 2007 09:11:52 - From: Brian Shire [EMAIL PROTECTED] To: [EMAIL PROTECTED] shire Sun Jun 3 09:11:52 2007 UTC Modified files: /php-src/ext/standard formatted_print.c Log: Change printf %u behavior so that it does not truncate numbers at 32-bits. (Reported by Aditya Agarwal.) http://cvs.php.net/viewvc.cgi/php-src/ext/standard/ formatted_print.c?r1=1.100r2=1.101diff_format=u Index: php-src/ext/standard/formatted_print.c diff -u php-src/ext/standard/formatted_print.c:1.100 php-src/ext/ standard/formatted_print.c:1.101 --- php-src/ext/standard/formatted_print.c:1.100 Thu May 17 17:29:09 2007 +++ php-src/ext/standard/formatted_print.c Sun Jun 3 09:11:52 2007 @@ -16,7 +16,7 @@ + --+ */ -/* $Id: formatted_print.c,v 1.100 2007/05/17 17:29:09 tony2001 Exp $ */ +/* $Id: formatted_print.c,v 1.101 2007/06/03 09:11:52 shire Exp $ */ #include math.h /* modf() */ #include php.h @@ -278,7 +278,7 @@ PRINTF_DEBUG((sprintf: appenduint(%x, %x, %x, %d, %d, '%c', %d) \n, *buffer, pos, size, number, width, padding, alignment)); - magn = (unsigned int) number; + magn = (unsigned long) number; /* Can't right-pad 0's on integers */ if (alignment == 0 padding == '0') padding = ' '; -- Wbr, Antony Dovgal Ilia Alshanetsky -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] 5.2.4RC2
Hopefully Edin will have the time to upgrade the MySQL lib on the build farm, thanks letting me know. On 17-Aug-07, at 7:06 AM, Scott MacVicar wrote: We still need to get the Windows builds using the latest libmysql or at least a downgrade to solve bug #41350. The code is already checked in to fix it, we just need the new library. I've emailed Edin and assigned him the bug a few weeks ago but no reply yet, is someone else got access to the build machine to do the upgrade? I believe this should block 5.2.4 as on Windows when using CGI / CLI this causes an error message to get printed at the bottom of every page as well as holding on to a connection for 30s more than needed as MySQL waits for the resources to be freed. Scott Ilia Alshanetsky wrote: As promised two weeks ago, the 5.2.4RC2 was released today and the sources for the release can be found here: http://downloads.php.net/ilia/php-5.2.4RC2.tar.bz2 (md5sum: dc6589d253b4ac5010603c5927f33546 ) Windows binaries should become available in short order as well. All in all the feedback on RC1 has been largely positive and since it was released another 20+ fixes were added to the code as well as a plethora of new test cases, which bumps up the code coverage to 53%. The number of changes in the CVS have petered off in the last few days, which is usually a sign that we are ready for a final release, or that everyone is on vacation. Please try this RC out on your code and report back any critical issues you may discover. If all goes well the plan is to have the final release done by the end of next week. Ilia Alshanetsky Ilia Alshanetsky -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Re: #40581 [Opn-Asn]: Pass Struct type to COM object from PHP
Hi Pierre Sorry been very busy on other things in last few months and so have not had the time to give COM any TLC. I will do my best to find some time in the coming weeks to work on some of the outstanding COM defects and of course when I do so I will look at all the outstanding COM defects; whether OPEN or assigned to Wez. Regards Andy Andy Wharmby IBM United Kingdom Limited Hursley Park, UK Pierre wrote: On 8/16/07, Wez Furlong [EMAIL PROTECTED] wrote: Per previous discussion on internals, there are other more active maintainers for COM right now, and by assigning to me, you're assigning to the wrong person. Andy Wharmby is active. I added him in CC. Andy, can you take a look at all COM/dotnet bugs including those assigned to Wez? Jani assigned to Wet a lot of them yesterday :) If you don't care, that's fine, it's just that assigned is not really the correct disposition for the ticket in that case; better to leave it open so that someone else can clearly see that nothing is happening, and perhaps then fix it themselves. The idea behind assign was to get some love for a given bug. That's not really the right way to do it though. I hope the new issues tracker will let us send mails to a group of maintainers when a new issue is raised. Then they can do the right action (and define who will work on it). For now it is just a big source of noises. Cheers, --Pierre -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: RE: [PHP-DEV] Renaming namespaces to packages
Why not use both names? For all of those distributing frameworks and such, use package. And for everybody else, who just wants to shorten their class names, use namespace. It's probably easier said than done, but why not just alias one to the other? Tyler -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [Fwd: Re: [PHP-DEV] Renaming namespaces to packages]
Hi, Has anyone thought of the keyword phpspace? 2007/8/17, M. Sokolewicz [EMAIL PROTECTED]: I've been reading this lengthy discussion and here's a sumup of what I found: - PHP's implementation is only a part of what most people expect to find when they hear php has namespace support - PHP's implementation looks a bit like JAVA's package support, and a bit like many other (differently names) features in other languages. It however does not match 1:1 to any of those. So, everyone here has agreed already that namespaces !=== PHP's implementation (it might ==, but not ===). Same goes for Package. I find the idea of Greg to be very good though, reading the original proposal, it often names things not namespace but simply prefix. What do you do with your names? you use a prefix, you don't expect it to have full namespace support just like [insert any other language here], nor do you expect it to be exactly like a JAVA package. When announced, you could simply state PHP now has support for prefixing, PHP's own specific implementation of namespaces. Because that's what you have, you can complain that according to the definition of [word] it _is_ that., but you can't really. The definition of a word like namespace, package, etc. is not independent of its implementation in majorly used languages unfortunately. If you ask a random coder what is a namespace, the answer will always be based on an implementation in a language the person uses/likes a lot. You can quote from wikipedia, but that doesn't really mean anything (sorry Stas), what we should try to do here is find the proper name which identifies the implementation we have for what it is. prefix Foo; alias Foo:Bar as Quux; Looks very good to me as it clearly shows what happens, internally and externally. It's not a namespace as such, it's not a package as such, it's simply what PHP _does_. I hope this will help the discussion steer away from the standard arguments that have been used constantly, and that will simply not change. - Tul Gregory Beaver wrote: Hi, All of the debate over whether this is a true namespace implementation is in my opinion completely bogus (translate: I think namespace is a fine choice for the reserved word, and package is a dangerously misleading choice), but since there is so much noisy dissent, I have an alternative proposal I'd like to float: How about using the keyword prefix or nameprefix instead of namespace? This will be clearer and can be easily defined with 2 sentences similar to the original proposal: All class and function names inside the file are automatically prefixed with the (prefix|nameprefix) name. In other files, classes and functions can be imported with different names (aliases) to eliminate naming conflicts or reduce typing needed. I quote from the original Simple Namespace Proposal message by Dmitry: From the beginning: 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. From the middle: Namespace definition does the following: All class and function names inside are automatically prefixed with namespace name. As stated, because this proposal *only* defines a prefix for functions and class names, it is not a packaging model. All package models in existence define some kind of self-contained entity that groups related *files* and their contents together in a way that allows them to be packaged into a single thing, like a jar, a PEAR .tgz, or a .phar file. This proposal does none of these things. Simply because the prefix is defined per-file does not a package make. By the same logic, using .php at the end of a file or .dat at the end of a file creates special packages of php or dat information, because the extension applies to the whole file at once. Simply defining the contents of a file does not imply any organization whatsoever. What the original proposal *does* do is provide a namespace prefix - it defines a scope within which all names have a special prefix. This is not rocket science. rantOn a personal note, if you feel you must reply to this thread further, please follow this checklist: 1) is anything I am saying bring a new idea to the debate? 2) is there a patch that converts my new idea into a reality attached to the message? If you can't answer yes to either of these, please go immediately to jail, do not pass go, do not collect $200./rant Thank you to Dmitry for this much-needed idea. Thanks, Greg -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php -- Best regards, Jingcheng Zhang Room 304, Dormitory 26 of Yuquan Campus, Zhejiang University P.R.China
Re: [PHP-DEV] 5.2.4RC2
PCRE was updated, GD tests are non-critical, but I don't believe they were merged. Keep in mind that TODO was not done by me, so its not a word of law in terms of what's required to make the 5.2.4 release. On 17-Aug-07, at 8:51 AM, Lukas Kahwe Smith wrote: Ilia Alshanetsky wrote: Hopefully Edin will have the time to upgrade the MySQL lib on the build farm, thanks letting me know. add to the todo: http://oss.backendmedia.com/PhP52 What about GD2 tests and PCRE update .. are those done? regards, Lukas Ilia Alshanetsky -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Renaming namespaces to packages
Hi, I've updated the patch to be compatible with Dmitry's latest changes: http://schlueters.de/~johannes/php/zend_namespace_to_package_20070817.diff johannes On Fri, 2007-08-10 at 11:26 +0200, Johannes Schlüter wrote: Hi, I think we reached the consensus to rename namespaces to packages as our implementation is more package-like. Therefore I wrote the corresponding patch which tries to get rid of all namespaces and ns (well, not all ns only the namespace-related ones of course) used in the code. Additionally I changed all package-tests. Any objections? Does anybody (with the move-on-CVS-server powers) care about the history of the tests? Then please cp ZendEngine2/tests/ns_* to pkg_* there else I'll do a simple cvs rm and cvs add. The patch is at http://schlueters.de/~johannes/php/zend_namespace_to_package.diff and the tarball with the changed tests at http://schlueters.de/~johannes/php/zend_package_tests.tar.bz2 johannes -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Renaming namespaces to packages
Great stuff man! :) Thanks On 8/17/07, Johannes Schlüter [EMAIL PROTECTED] wrote: Hi, I've updated the patch to be compatible with Dmitry's latest changes: http://schlueters.de/~johannes/php/zend_namespace_to_package_20070817.diff johannes On Fri, 2007-08-10 at 11:26 +0200, Johannes Schlüter wrote: Hi, I think we reached the consensus to rename namespaces to packages as our implementation is more package-like. Therefore I wrote the corresponding patch which tries to get rid of all namespaces and ns (well, not all ns only the namespace-related ones of course) used in the code. Additionally I changed all package-tests. Any objections? Does anybody (with the move-on-CVS-server powers) care about the history of the tests? Then please cp ZendEngine2/tests/ns_* to pkg_* there else I'll do a simple cvs rm and cvs add. The patch is at http://schlueters.de/~johannes/php/zend_namespace_to_package.diff and the tarball with the changed tests at http://schlueters.de/~johannes/php/zend_package_tests.tar.bz2 johannes -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php -- David Coallier, Founder Software Architect, Agora Production (http://agoraproduction.com) 51.42.06.70.18 -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Renaming namespaces to packages
Oh dear. I thought the general feeling was to stick with namespaces? On 17/08/07, Johannes Schlüter [EMAIL PROTECTED] wrote: Hi, I've updated the patch to be compatible with Dmitry's latest changes: http://schlueters.de/~johannes/php/zend_namespace_to_package_20070817.diff johannes On Fri, 2007-08-10 at 11:26 +0200, Johannes Schlüter wrote: Hi, I think we reached the consensus to rename namespaces to packages as our implementation is more package-like. Therefore I wrote the corresponding patch which tries to get rid of all namespaces and ns (well, not all ns only the namespace-related ones of course) used in the code. Additionally I changed all package-tests. Any objections? Does anybody (with the move-on-CVS-server powers) care about the history of the tests? Then please cp ZendEngine2/tests/ns_* to pkg_* there else I'll do a simple cvs rm and cvs add. The patch is at http://schlueters.de/~johannes/php/zend_namespace_to_package.diff and the tarball with the changed tests at http://schlueters.de/~johannes/php/zend_package_tests.tar.bz2 johannes -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php -- - Richard Quadling Zend Certified Engineer : http://zend.com/zce.php?c=ZEND002498r=213474731 Standing on the shoulders of some very clever giants!
Re: [PHP-DEV] Renaming namespaces to packages
On 8/17/07, Ilia Alshanetsky [EMAIL PROTECTED] wrote: While PHP implementation of namespaces is may not be 100% of what people consider to be namespaces it is close enough and I think the name namespaces is most appropriate and clear cut. We don't call PHP objects Zend Objects or some other strange name, I don't see why namespaces should be any different IMHO. If we start calling things what they are, then we might as well do it for the *namespaces* as well ? So ccall them package. And Stanislav, it's not only because java does it that way, it's because python also does, and also because c++ doesn't. After all, why discussing the color of the bikeshed when it's already painted and it's a dogshed ? On 17-Aug-07, at 11:06 AM, Richard Quadling wrote: Oh dear. I thought the general feeling was to stick with namespaces? On 17/08/07, Johannes Schlüter [EMAIL PROTECTED] wrote: Hi, I've updated the patch to be compatible with Dmitry's latest changes: http://schlueters.de/~johannes/php/ zend_namespace_to_package_20070817.diff johannes On Fri, 2007-08-10 at 11:26 +0200, Johannes Schlüter wrote: Hi, I think we reached the consensus to rename namespaces to packages as our implementation is more package-like. Therefore I wrote the corresponding patch which tries to get rid of all namespaces and ns (well, not all ns only the namespace-related ones of course) used in the code. Additionally I changed all package-tests. Any objections? Does anybody (with the move-on-CVS-server powers) care about the history of the tests? Then please cp ZendEngine2/tests/ns_* to pkg_* there else I'll do a simple cvs rm and cvs add. The patch is at http://schlueters.de/~johannes/php/zend_namespace_to_package.diff and the tarball with the changed tests at http://schlueters.de/~johannes/php/zend_package_tests.tar.bz2 johannes -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php -- - Richard Quadling Zend Certified Engineer : http://zend.com/zce.php? c=ZEND002498r=213474731 Standing on the shoulders of some very clever giants! Ilia Alshanetsky -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php -- David Coallier, Founder Software Architect, Agora Production (http://agoraproduction.com) 51.42.06.70.18 -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [Fwd: Re: [PHP-DEV] Renaming namespaces to packages]
prefix Foo; alias Foo:Bar as Quux; If namespaces have to be renamed, then IMHO this proposal is the best so far. alias would also remove confusion from statement like ``import Foo`` because ``alias Foo`` is clearly no-op per se. At least to me ;-) Regards, Giedrius -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Renaming namespaces to packages
David, Most people don't know wtf you are referring to by package, but nearly everyone knows the concept of namespaces. Packages is name for an implementation of namespaces, calling it packages just because language XYZ that I like, does not sound like the best of ideas. On 17-Aug-07, at 11:18 AM, David Coallier wrote: On 8/17/07, Ilia Alshanetsky [EMAIL PROTECTED] wrote: While PHP implementation of namespaces is may not be 100% of what people consider to be namespaces it is close enough and I think the name namespaces is most appropriate and clear cut. We don't call PHP objects Zend Objects or some other strange name, I don't see why namespaces should be any different IMHO. If we start calling things what they are, then we might as well do it for the *namespaces* as well ? So ccall them package. And Stanislav, it's not only because java does it that way, it's because python also does, and also because c++ doesn't. After all, why discussing the color of the bikeshed when it's already painted and it's a dogshed ? On 17-Aug-07, at 11:06 AM, Richard Quadling wrote: Oh dear. I thought the general feeling was to stick with namespaces? On 17/08/07, Johannes Schlüter [EMAIL PROTECTED] wrote: Hi, I've updated the patch to be compatible with Dmitry's latest changes: http://schlueters.de/~johannes/php/ zend_namespace_to_package_20070817.diff johannes On Fri, 2007-08-10 at 11:26 +0200, Johannes Schlüter wrote: Hi, I think we reached the consensus to rename namespaces to packages as our implementation is more package-like. Therefore I wrote the corresponding patch which tries to get rid of all namespaces and ns (well, not all ns only the namespace-related ones of course) used in the code. Additionally I changed all package-tests. Any objections? Does anybody (with the move-on-CVS-server powers) care about the history of the tests? Then please cp ZendEngine2/tests/ns_* to pkg_* there else I'll do a simple cvs rm and cvs add. The patch is at http://schlueters.de/~johannes/php/zend_namespace_to_package.diff and the tarball with the changed tests at http://schlueters.de/~johannes/php/zend_package_tests.tar.bz2 johannes -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php -- - Richard Quadling Zend Certified Engineer : http://zend.com/zce.php? c=ZEND002498r=213474731 Standing on the shoulders of some very clever giants! Ilia Alshanetsky -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php -- David Coallier, Founder Software Architect, Agora Production (http://agoraproduction.com) 51.42.06.70.18 Ilia Alshanetsky -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Renaming namespaces to packages
Again, you are trying to use a keyword based on what developer's most
know. You want to release a sort of namespace implementation and
frustrate users, that expect a true namespace implementation.
I'd like that language MyPersonalFckinLang implemented it. Everything
in this discussion is motivated by Java does this or C++ or C# or
Python does that.
One package is a specific implementation of namespace which,
unhappilly was incorporated by Java. One package ***IS*** a namespace,
but applies restrictions. WTF? Yes, look at PHP... it's a kind of
namespace implementation (ah packages too), and apply restrictions
(one package per file) (ah, packages too, but namespaces allow more
than one per file).
For your announcement, PHP has namespace support provided by packages.
I am not the bad guy in this entire history, and I hope we can drink a
dozen bottles of beer =) together in the future, but PLEASE don't
frustrate PHP users by providing them a basic functionality of what
you have announced.
The filescope is another workaround for namespace implementation. One
namespace local import should work in the entire namespace, not only
in the file it was imported.
AGAIN, here are the list of changes that will make everyone accept
namespace as the keyword:
- Remove the restriction to one package/namespace per file
- Use curly braces to define one namespace
- Allow nested definitions namespace N1 { namespace SubN1 { ... }
namespace Sub2N1 { ... } }
- using/import is related to the namespace/package/whatever scope.
If you say these functionalities will be implemented (ok, maybe in
PHP6.1 or 6.X), I'd change my vote and I'll fight in the namespaces
side. I think not only me, but everyone that is currently suggesting
to rename it to packages.
I can even try to help in the development of them, but I'll need some
help to understand the background of ZE. Sara's book will arrive at
home in 4-6 weeks.
Regards,
On 8/17/07, Ilia Alshanetsky [EMAIL PROTECTED] wrote:
David,
Most people don't know wtf you are referring to by package, but
nearly everyone knows the concept of namespaces. Packages is name for
an implementation of namespaces, calling it packages just because
language XYZ that I like, does not sound like the best of ideas.
On 17-Aug-07, at 11:18 AM, David Coallier wrote:
On 8/17/07, Ilia Alshanetsky [EMAIL PROTECTED] wrote:
While PHP implementation of namespaces is may not be 100% of what
people consider to be namespaces it is close enough and I think the
name namespaces is most appropriate and clear cut. We don't call
PHP objects Zend Objects or some other strange name, I don't see
why namespaces should be any different IMHO.
If we start calling things what they are, then we might as well do it
for the *namespaces* as well ? So ccall them package. And Stanislav,
it's not only because java does it that way, it's because python also
does, and also because c++ doesn't.
After all, why discussing the color of the bikeshed when it's already
painted and it's a dogshed ?
On 17-Aug-07, at 11:06 AM, Richard Quadling wrote:
Oh dear. I thought the general feeling was to stick with namespaces?
On 17/08/07, Johannes Schlüter [EMAIL PROTECTED] wrote:
Hi,
I've updated the patch to be compatible with Dmitry's latest
changes:
http://schlueters.de/~johannes/php/
zend_namespace_to_package_20070817.diff
johannes
On Fri, 2007-08-10 at 11:26 +0200, Johannes Schlüter wrote:
Hi,
I think we reached the consensus to rename namespaces to packages
as our
implementation is more package-like. Therefore I wrote the
corresponding
patch which tries to get rid of all namespaces and ns (well,
not all
ns only the namespace-related ones of course) used in the code.
Additionally I changed all package-tests. Any objections?
Does anybody (with the move-on-CVS-server powers) care about the
history
of the tests? Then please cp ZendEngine2/tests/ns_* to pkg_*
there else
I'll do a simple cvs rm and cvs add.
The patch is at
http://schlueters.de/~johannes/php/zend_namespace_to_package.diff
and
the tarball with the changed tests at
http://schlueters.de/~johannes/php/zend_package_tests.tar.bz2
johannes
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
--
-
Richard Quadling
Zend Certified Engineer : http://zend.com/zce.php?
c=ZEND002498r=213474731
Standing on the shoulders of some very clever giants!
Ilia Alshanetsky
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
--
David Coallier,
Founder Software Architect,
Agora Production (http://agoraproduction.com)
51.42.06.70.18
Ilia Alshanetsky
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
--
Guilherme Blanco - Web Developer
CBC - Certified Bindows
Re: [PHP-DEV] Renaming namespaces to packages
While PHP implementation of namespaces is may not be 100% of what people consider to be namespaces it is close enough and I think the name namespaces is most appropriate and clear cut. We don't call PHP objects Zend Objects or some other strange name, I don't see why namespaces should be any different IMHO. On 17-Aug-07, at 11:06 AM, Richard Quadling wrote: Oh dear. I thought the general feeling was to stick with namespaces? On 17/08/07, Johannes Schlüter [EMAIL PROTECTED] wrote: Hi, I've updated the patch to be compatible with Dmitry's latest changes: http://schlueters.de/~johannes/php/ zend_namespace_to_package_20070817.diff johannes On Fri, 2007-08-10 at 11:26 +0200, Johannes Schlüter wrote: Hi, I think we reached the consensus to rename namespaces to packages as our implementation is more package-like. Therefore I wrote the corresponding patch which tries to get rid of all namespaces and ns (well, not all ns only the namespace-related ones of course) used in the code. Additionally I changed all package-tests. Any objections? Does anybody (with the move-on-CVS-server powers) care about the history of the tests? Then please cp ZendEngine2/tests/ns_* to pkg_* there else I'll do a simple cvs rm and cvs add. The patch is at http://schlueters.de/~johannes/php/zend_namespace_to_package.diff and the tarball with the changed tests at http://schlueters.de/~johannes/php/zend_package_tests.tar.bz2 johannes -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php -- - Richard Quadling Zend Certified Engineer : http://zend.com/zce.php? c=ZEND002498r=213474731 Standing on the shoulders of some very clever giants! Ilia Alshanetsky -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] 5.2.4RC2
We also need newer libtidy snmp on the build host. Don't know if Edin has updated them already, if he hasn't, then this must be done asap, we're too close to the release.. On 17.08.2007 17:08, Ilia Alshanetsky wrote: PCRE was updated, GD tests are non-critical, but I don't believe they were merged. Keep in mind that TODO was not done by me, so its not a word of law in terms of what's required to make the 5.2.4 release. On 17-Aug-07, at 8:51 AM, Lukas Kahwe Smith wrote: Ilia Alshanetsky wrote: Hopefully Edin will have the time to upgrade the MySQL lib on the build farm, thanks letting me know. add to the todo: http://oss.backendmedia.com/PhP52 What about GD2 tests and PCRE update .. are those done? regards, Lukas Ilia Alshanetsky -- Wbr, Antony Dovgal -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] Namespace question
Hey guys, looking at the minutes meeting from the paris conf (http://php.net/~derick/meeting-notes.html), I was wondering if Constants in name spaces are allowed unless we find problems with the implementation. were implemented. I tried but putting namespace MyPackage; const NAME = 'inspace'; Then I get a parse error. (Unexpected T_CONST..) Is that normal ? Looking at the minutes notes I can not really see what of this list that has been discussed by the attendees has been implemented. Enlighten me someone please. And yes these notes were built nearly 2 years ago. Thanks for your replies. -- David Coallier, Founder Software Architect, Agora Production (http://agoraproduction.com) 51.42.06.70.18 -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] 5.2.4RC2
On 8/17/07, Antony Dovgal [EMAIL PROTECTED] wrote: We also need newer libtidy snmp on the build host. Don't know if Edin has updated them already, if he hasn't, then this must be done asap, we're too close to the release.. And Pslib. --Pierre -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Namespace question
On 8/17/07, Stanislav Malyshev [EMAIL PROTECTED] wrote: So my question is: Anyone thinking in doing const for namespaces thus calling something like What::NAME; // echo 'booo' Yep, we are thinking of allowing const in namespace (and maybe even outside, since it'd be basically the same) but we didn't arrive yet to any decision if we can implement it in a good way - there's some ambiguity which can have negative impact on performance, we'd need to see how we can deal with it. -- Stanislav Malyshev, Zend Software Architect [EMAIL PROTECTED] http://www.zend.com/ (408)253-8829 MSN: [EMAIL PROTECTED] Awesome thanks, -- David Coallier, Founder Software Architect, Agora Production (http://agoraproduction.com) 51.42.06.70.18 -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Namespace question
So my question is: Anyone thinking in doing const for namespaces thus calling something like What::NAME; // echo 'booo' Yep, we are thinking of allowing const in namespace (and maybe even outside, since it'd be basically the same) but we didn't arrive yet to any decision if we can implement it in a good way - there's some ambiguity which can have negative impact on performance, we'd need to see how we can deal with it. -- 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] PHP.net endorsed installer method
I'll copy them on it, but I wasn't sure if a round of +1/0/-1 wasn't in order thru internals first. Making the change isn't the issue, but I just want to not make a statement on behalf of all of PHP.net without someone saying it's OK ;- On 8/17/07, David Coallier [EMAIL PROTECTED] wrote: On 8/17/07, John Mertic [EMAIL PROTECTED] wrote: In an effort to help the windows installer get more widespread use, I would like to propose changing the following warning in the manual at http://www.php.net/manual/en/install.windows.php from: There are several all-in-one installers over the Internet, but none of those are endorsed by PHP.net, as we believe that the manual installation is the best choice to have your system secure and optimised. to: There are several all-in-one installers over the Internet, but none of those are endorsed by PHP.net, as we believe that using one of the official windows packages from http://www.php.net/downloads.php is the best choice to have your system secure and optimised. I might be proposing this in the wrong place, but since the verbage endorsed by PHP.net is in there I thought it would be prudent to post it to internals. -- -- John MerticExplaining a joke is like dissecting a frog: you [EMAIL PROTECTED] understand it better, but the frog dies in the process. -Mark Twain -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php Try the documentation team list: see: http://www.php.net/mailing-lists.php -- David Coallier, Founder Software Architect, Agora Production (http://agoraproduction.com) 51.42.06.70.18 -- -- John MerticExplaining a joke is like dissecting a frog: you [EMAIL PROTECTED] understand it better, but the frog dies in the process. -Mark Twain -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] 5.2.4RC2
Based on the recent posts: libmysql pslib libtidy snmp Scott Edin Kadribasic wrote: I will look into this later tonight. I have very little time on my hands so a list of libraries that need updating would be very much appreciated. Edin John Mertic wrote: Edin, I noticed that I can't download 5.2.4RC installer builds; getting a 403 - Forbidden error. Also the latest snapshot log is complaining about 'Access is denied': ---snip--- Building ExtensionsComponents.wxs Removing File yazDLL because doesn't exist Removing Feature pecl_php6activescript because of missing Component php6activescript Removing Feature ext_php_ixsfunc because of missing Component php_ixsfunc Removing Feature ext_php_java because of missing Component php6servlet Removing Feature ext_php_rar because of missing Component php_rar Removing Feature ext_php_yaz because of missing Component php_yaz Building PHPInstaller5.2.4RC3-dev.wxs Building WebServerConfig5.2.4RC3-dev.wxs 1 file(s) copied. Compiling UI Access is denied. Building UI Access is denied. Compiling Installer Access is denied. Linking Installer Access is denied. Building installer failed ---snip--- -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] PHP.net endorsed installer method
On 8/17/07, John Mertic [EMAIL PROTECTED] wrote: In an effort to help the windows installer get more widespread use, I would like to propose changing the following warning in the manual at http://www.php.net/manual/en/install.windows.php from: There are several all-in-one installers over the Internet, but none of those are endorsed by PHP.net, as we believe that the manual installation is the best choice to have your system secure and optimised. to: There are several all-in-one installers over the Internet, but none of those are endorsed by PHP.net, as we believe that using one of the official windows packages from http://www.php.net/downloads.php is the best choice to have your system secure and optimised. I might be proposing this in the wrong place, but since the verbage endorsed by PHP.net is in there I thought it would be prudent to post it to internals. -- -- John MerticExplaining a joke is like dissecting a frog: you [EMAIL PROTECTED] understand it better, but the frog dies in the process. -Mark Twain -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php Try the documentation team list: see: http://www.php.net/mailing-lists.php -- David Coallier, Founder Software Architect, Agora Production (http://agoraproduction.com) 51.42.06.70.18 -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] 5.2.4RC2
I've noticed the following links not working http://downloads.php.net/edink/php-5.2.4RC1-win32-installer.msi http://downloads.php.net/edink/php-5.2.4RC2-win32-installer.msi Not sure what I can do to help with snaps without access to the build machine. I did update the wix binaries in CVS which might have something do with it, although I have been able to build successfully locally. Thanks... On 8/17/07, Edin Kadribasic [EMAIL PROTECTED] wrote: I will look into this later tonight. I have very little time on my hands so a list of libraries that need updating would be very much appreciated. Edin John Mertic wrote: Edin, I noticed that I can't download 5.2.4RC installer builds; getting a 403 - Forbidden error. Also the latest snapshot log is complaining about 'Access is denied': ---snip--- Building ExtensionsComponents.wxs Removing File yazDLL because doesn't exist Removing Feature pecl_php6activescript because of missing Component php6activescript Removing Feature ext_php_ixsfunc because of missing Component php_ixsfunc Removing Feature ext_php_java because of missing Component php6servlet Removing Feature ext_php_rar because of missing Component php_rar Removing Feature ext_php_yaz because of missing Component php_yaz Building PHPInstaller5.2.4RC3-dev.wxs Building WebServerConfig5.2.4RC3-dev.wxs 1 file(s) copied. Compiling UI Access is denied. Building UI Access is denied. Compiling Installer Access is denied. Linking Installer Access is denied. Building installer failed ---snip--- -- -- John MerticExplaining a joke is like dissecting a frog: you [EMAIL PROTECTED] understand it better, but the frog dies in the process. -Mark Twain -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] reserved word alert
Hey David Lucas,
I brought this up a year ago on the list here:
http://marc.info/?t=11472819373r=1w=2
Essentially, the trend will continue to be that as keyword requiring
features are added, the global naming space will continue to become
smaller and less safe for older applications written for older versions
of php.
Until it becomes a goal of php-internals to add contextual awareness and
sensitivity to the compiler's tokenizer, this will always be a problem.
Here is a more amusing list of method names that will also not work:
http://marc.info/?l=php-devm=114736739115429w=2
And the general opinion summed up by Wez ;)
http://marc.info/?l=php-devm=114764099400409w=2
-ralph
David Coallier wrote:
On 8/16/07, Marcus Boerger [EMAIL PROTECTED] wrote:
Hello Lukas,
this is a no issue. Prefix your code and be done!
That means prefixing your methods as well ?
The problem is when one calls something like a method import()
You prefix your functions ? I think this is silly. Prefix the class to
make it namespace** like, but not the methods...
PEAR_ClassName {
public static function __PEAR_construct() { }
public static function PEAR_import() { }
public static function PEAR_export() { }
}
Which ends in
PEAR_ClassName::PEAR_Import();
Whereas:
PEAR_ClassName::import(); would usually be ok to do.
Prefixing the methods imho is the no go in this case.
marcus
Wednesday, August 15, 2007, 3:37:20 PM, you wrote:
Hi,
Someone in the Doctrine channel just brought up the issue of having to
look forward to ensure mid term compatibility when choosing names for
identifiers. I guess with namespaces and other things will add new
reserved words. I think we should have a prominent place on php.net with
early warning for reserved words that will be in future php releases.
regards,
Lukas
Best regards,
Marcus
--
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
[PHP-DEV] PHP.net endorsed installer method
In an effort to help the windows installer get more widespread use, I would like to propose changing the following warning in the manual at http://www.php.net/manual/en/install.windows.php from: There are several all-in-one installers over the Internet, but none of those are endorsed by PHP.net, as we believe that the manual installation is the best choice to have your system secure and optimised. to: There are several all-in-one installers over the Internet, but none of those are endorsed by PHP.net, as we believe that using one of the official windows packages from http://www.php.net/downloads.php is the best choice to have your system secure and optimised. I might be proposing this in the wrong place, but since the verbage endorsed by PHP.net is in there I thought it would be prudent to post it to internals. -- -- John MerticExplaining a joke is like dissecting a frog: you [EMAIL PROTECTED] understand it better, but the frog dies in the process. -Mark Twain -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] 5.2.4RC2
On 17.08.2007 20:26, Ilia Alshanetsky wrote: Tony, What are the reasons for needing to upgrade tidy and snmp libs at this time aside from newer is better? Security problems in both libs which are not reproducible in newer versions. -- Wbr, Antony Dovgal -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] 5.2.4RC2
I will look into this later tonight. I have very little time on my hands so a list of libraries that need updating would be very much appreciated. Edin John Mertic wrote: Edin, I noticed that I can't download 5.2.4RC installer builds; getting a 403 - Forbidden error. Also the latest snapshot log is complaining about 'Access is denied': ---snip--- Building ExtensionsComponents.wxs Removing File yazDLL because doesn't exist Removing Feature pecl_php6activescript because of missing Component php6activescript Removing Feature ext_php_ixsfunc because of missing Component php_ixsfunc Removing Feature ext_php_java because of missing Component php6servlet Removing Feature ext_php_rar because of missing Component php_rar Removing Feature ext_php_yaz because of missing Component php_yaz Building PHPInstaller5.2.4RC3-dev.wxs Building WebServerConfig5.2.4RC3-dev.wxs 1 file(s) copied. Compiling UI Access is denied. Building UI Access is denied. Compiling Installer Access is denied. Linking Installer Access is denied. Building installer failed ---snip--- -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Namespace question
const keyword is currently allowed only inside class-definitions; generic constants are specified using define() On 8/17/07, David Coallier [EMAIL PROTECTED] wrote: Hey guys, looking at the minutes meeting from the paris conf (http://php.net/~derick/meeting-notes.html), I was wondering if Constants in name spaces are allowed unless we find problems with the implementation. were implemented. I tried but putting namespace MyPackage; const NAME = 'inspace'; Then I get a parse error. (Unexpected T_CONST..) Is that normal ? Looking at the minutes notes I can not really see what of this list that has been discussed by the attendees has been implemented. Enlighten me someone please. And yes these notes were built nearly 2 years ago. Thanks for your replies. -- David Coallier, Founder Software Architect, Agora Production (http://agoraproduction.com) 51.42.06.70.18 -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php -- Alexey Zakhlestin http://blog.milkfarmsoft.com/ -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Namespace question
On 8/17/07, Alexey Zakhlestin [EMAIL PROTECTED] wrote:
const keyword is currently allowed only inside class-definitions;
generic constants are specified using define()
I know that..
Right now you can do.
--File: ns.php--
namespace What
define ('NAME', 'booo');
class Tester
{
public function __construct()
{
echo 'yeah.. no!';
}
}
--File: testns.php--
require 'ns.php';
echo NAME; // Will echo booo without importing the namespace
// And
$obj = new Tester; // This as it should do, will return an error.
// Change to that:
import What as A;
$obj = new A::Tester; // This will echo yeah...No as it should.
So my question is: Anyone thinking in doing const for namespaces thus
calling something like
What::NAME; // echo 'booo'
?
On 8/17/07, David Coallier [EMAIL PROTECTED] wrote:
Hey guys, looking at the minutes meeting from the paris conf
(http://php.net/~derick/meeting-notes.html), I was wondering if
Constants in name spaces are allowed unless we find problems with the
implementation. were implemented. I tried but putting
namespace MyPackage;
const NAME = 'inspace';
Then I get a parse error. (Unexpected T_CONST..)
Is that normal ? Looking at the minutes notes I can not really see
what of this list that has been discussed by the attendees has been
implemented.
Enlighten me someone please.
And yes these notes were built nearly 2 years ago.
Thanks for your replies.
--
David Coallier,
Founder Software Architect,
Agora Production (http://agoraproduction.com)
51.42.06.70.18
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
--
Alexey Zakhlestin
http://blog.milkfarmsoft.com/
--
David Coallier,
Founder Software Architect,
Agora Production (http://agoraproduction.com)
51.42.06.70.18
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] 5.2.4RC2
Scott MacVicar wrote: Based on the recent posts: libmysql pslib libtidy snmp Thanks Scott, much appreciated. Edin -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Renaming namespaces to packages
Again, you are trying to use a keyword based on what developer's most know. You want to release a sort of namespace implementation and frustrate users, that expect a true namespace implementation. Please stop doing this. PHP namespace implementation is as true as it gets, even in current form (which of course might be changed, extended, etc. but it doesn't make it less true). If you have any specific feature missing (except for braces which were discussed already in length so please mention them _only_ if you have something new to say about it) - this is exactly the time to say it, since we are still in prototyping stage, so please do bring it forward. But please do not just decry it because it uses slightly different syntax than some other language you know. -- 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] Nowdocs revised
True, but the result is the same. The new functions/classes can't be used (only some rare additions can be efficiently emulated in user land). Yes, but you still have option of working around it. Right now we don't have an option to work around new syntax. I hate to rain on your parade, because I think this functionality is good and would have a lot of good uses, but I'm worried about creating code that runs in one 5.x and can't be even compiled by another. There can be a lot of problems with external tools, too. -- 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] 5.2.4RC2
On 8/17/07, Edin Kadribasic [EMAIL PROTECTED] wrote: Scott MacVicar wrote: Based on the recent posts: libmysql pslib libtidy snmp Thanks Scott, much appreciated. Hi Edin! While checking the list, libpng came to my mind. I'm not sure what which version we use now, but this library also had issues in the last 2-3 months, it would be nice to use the last version. By the way, once you have updated them, can you update the zip.zip too? :) Thanks for your work! --Pierre -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] reserved word alert
Ralph Schindler wrote: Hey David Lucas, I brought this up a year ago on the list here: http://marc.info/?t=11472819373r=1w=2 Essentially, the trend will continue to be that as keyword requiring features are added, the global naming space will continue to become smaller and less safe for older applications written for older versions of php. Until it becomes a goal of php-internals to add contextual awareness and sensitivity to the compiler's tokenizer, this will always be a problem. Here is a more amusing list of method names that will also not work: http://marc.info/?l=php-devm=114736739115429w=2 And the general opinion summed up by Wez ;) http://marc.info/?l=php-devm=114764099400409w=2 Hi, Doing this with flex is non-trivial. It's a lot easier with a re2c-based lexer, but porting the flex scanner to re2c is the definition of oh-my-god-almighty complex and until someone just does it, it ain't gonna happen. The other hackish alternative is to add rules to the parser with reserved words (T_FUNCTION T_IMPORT as well as T_FUNCTION T_STRING, etc. etc.), but this slows down the parser and adds unnecessary duplication. Greg -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] 5.2.4RC2
were merged. Keep in mind that TODO was not done by me, so its not a word of law in terms of what's required to make the 5.2.4 release. Speaking of which - who's managing the todo? I have a couple of items for 5.3 one... -- 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] [Fwd: [PHP-CVS] cvs: php-src /ext/standard formatted_print.c]
Antony Dovgal wrote: Ilia? Greg? Any comments? On 14.08.2007 15:42, Antony Dovgal wrote: This patch breaks PEAR phar install on 64bit. From what I can see in the source code, it compares data in the phar with the result of sprintf(%u..), which is different on 32bit and 64bit because of this patch. Either phar should be changed to detect this situation or this patch should be reverted. Hi, My only comment is I've already been forced to change a fully working PHP_Archive 3 times because of bugfixes that broke BC in pack/unpack, and I changed it to sprintf(%u) because it was the only way to ensure that the behavior works the same way on 32-bit and 64-bit. I would appreciate it if this is the last change of this nature that I need to deal with :). As for PHP_Archive, I'll try to figure out a solution but to be honest, I'm not too keen on this, as sprintf(%u) was the only solution I found last time. Perhaps dropping unpack() and rewriting it in userspace is my only option shiver. Thanks, Greg P.S. just to be clear, this is PHP_Archive we're talking about, not phar. phar is a PHP extension that has no such problems as it does all the unpacking internally, PHP_Archive is a userspace stream wrapper that uses unpack()/sprintf(%u) -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Nowdocs revised
On 8/17/07, Stanislav Malyshev [EMAIL PROTECTED] wrote: True, but the result is the same. The new functions/classes can't be used (only some rare additions can be efficiently emulated in user land). Yes, but you still have option of working around it. Right now we don't have an option to work around new syntax. I hate to rain on your parade, because I think this functionality is good and would have a lot of good uses, but I'm worried about creating code that runs in one 5.x and can't be even compiled by another. There can be a lot of problems with external tools, too. I agree about codes not running in the same bug fixes branch. However I don't see a problem to introduce this patch in 5.3.0 (think about b introduced in 5.2.x). --Pierre -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Renaming namespaces to packages
On 17 Aug 2007, at 1146, Stanislav Malyshev wrote: Again, you are trying to use a keyword based on what developer's most know. You want to release a sort of namespace implementation and frustrate users, that expect a true namespace implementation. Please stop doing this. PHP namespace implementation is as true as it gets, even in current form (which of course might be changed, extended, etc. but it doesn't make it less true). I think you've missed his point. He's not talking about the abstract concept of namespaces. He's talking about specific language features accessed via the keyword 'namespace'. The core of the argument to rename is that using the keyword 'namespace' will confuse developers who have experience with that keyword in other languages, since PHP does not match the most common syntax (C++). This is completely separate from whether the PHP language feature is a good implementation of the abstract namespace concept. The keyword does not define the feature -- the keyword defines _expectations_ about the keyword. PHP is getting a namespaces feature -- this is excellent. Giving it the same keyword as a syntax-incompatible feature of other languages is going to cause confusion -- that's bad. Now, the keyword 'package' has similar problems, but to a much smaller degree since the syntax of the PHP language feature is similar to that of the Java feature. Still, any confusion is best avoided so 'package' should probably join 'namespace' on the pile of rejected keywords. 'prefix', as suggested in the other thread, seems to nicely describe the concept and would still describe the concept if the feature was extended out to full-on C++- or Java-style syntax. And I can't think of any languages with a confusingly similar keyword. scott. PGP.sig Description: This is a digitally signed message part
