Re: [PHP-DEV] phar update
Hi Kalle, and in 124 tests fails for in HEAD, instead of writing an insanely long list here, I have zipped both the test log and diffs for 5.3 and HEAD which can be downloaded here: Yeah, that's normal - most of Phar doesn't work yet in HEAD. Thanks! - Steph -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Vote: allow_call_time_pass_reference value in production INI
That's a good point we need to make sure that main.c INI values match those of the production INI file. There are A LOT of installs that operate without an INI file. I'd say it's usually ini-dist that matches the main.c value... but the issue in this case is that ini-recommended (which is generally taken as 'ini-production' by the community at large) throws warnings that are not thrown by default, which seems pretty weird to me. - Steph -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Vote: allow_call_time_pass_reference value in production INI
allow_call_time_pass_reference = Off (Issue Warnings) Eric Lee Stewart +1 Switching it off by default in ini-dist and main.c would be good too! http://wiki.php.net/rfc/calltimebyref - Steph -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] 5.3 todos
It doesn't matter that the XML file is long. Each section is broken up into a separate page in the manual. I'm talking about the UPGRADE file in the source, which is plain text. Have you ever tried to read it? - Steph -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] 5.3 todos
BUT perhaps some of the more complex explanations should have their own document. If it 'requires more explanation than we want to provide in the documentation' that does seem to suggest that a development perhaps DOES need better doumentation? In the manual, really. But - quite. - Steph -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] 5.3 todos
Hi Dan, Because the guide is in the manual. The manual is the difinitive source on how to use PHP. The guide was only added directly into the manual quite recently. This is exactly what I'm trying to say; its purpose has shifted since it became part of the manual and it's lost whatever usefulness it had in the src as a result. Sure, the guide be better structured. But it should contain everything. It's nothing to do with structure. "Everything" makes for a very long file, full stop. - Steph -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] 5.3 todos
So in summary, I feel the key point for this document is: - a single document that lists all changes - contains pointers that enables someone to look up more details in the documentation - enables people who get new "strange" error messages to find pointers towards the documentation - some lengthier migration related explanations that go beyond what we want to provide in the documentation Right. That isn't what ever happened before 5.2. Up til then it was simply somewhere you could look to get an overview of changes *that would affect existing code*. Hence the name of the file. See, I _knew_ we were looking at completely different things..! How's about a short, sane version in the src and an extended bells-and-whistles version for the manual? With a link provided in the src version to the extended version. - Steph -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] 5.3 todos
Then I guess I need to read the archives. I can't imagine why a system admin would give a damn about new language features, object model, reference changes, pdo, new error levels or how to check if a class inherits another class. They'd need to know that there had been major changes in the language and they couldn't just upgrade willy-nilly without warning the affected developers about changes that could break existing code, which the file addresses. They'd need to know too that (for example) 8 core extensions are no longer in the core, and that some new ones are. They might need to know about error reporting level changes, depending on the setup. They'd need to know about new core .ini directives and those affecting new extensions in the core. They'd probably want to know about streams changes (any). Maybe listing every single new constant is a bit excessive, but we do at the very very very least need to link to the page that lists them then. That's not a problem. Lead me to your docs :) - Steph -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] 5.3 todos
An upgrade is not only about problems, it is also about solutions. You need a problem before providing a solution. Really. A kind of tutorial on how to use all the changes in a given release in your applications. It often helps to clean codes, remove work 'round, etc. An upgrade guide is often the document many will read, and not the NEWS file, which is not that useful in the current format. They won't read it if it's too darn long :) Please go back to the original discussion about the purpose of this guide. It was aimed primarily at sysadmins. If we turn it into a prettier version of NEWS or release notes, all it means is we still need an upgrade file for sysadmins. So in response to Hannes' earlier question, yes I think these should be two separate documents - one for end users in the manual, one for sysadmins in the src. And no I don't mind writing both, I just want to be very clear about their purpose. - Steph -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] 5.3 todos
IMHO listing new functions is useful - there could be a name collision with a function in users code (I know it is improbable, because the functions are named extname_funcname, but still possible) Improbable indeed. The nearest we ever came to that was with the Date class (because PEAR already had a Date class - nobody else complained, mind.) Maybe it would be best to list any new core PHP functions and mention prefixes used by any new extensions. The 5.2 guide lists 'new optional parameters' too. I honestly don't see how the existence of a new optional parameter can possibly impact existing code; ergo, it has no place in an upgrade guide. - Steph -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] 5.3 todos
But this was actually an add-on after I put the initial 5.1 upgrading guide together. A 200-line document became a 500-line document overnight, and voila - nobody reads the thing. Actually I'm wrong - that was 5.2. The 5.1 upgrade guide appears to be as-was. So again, why are we listing new extensions, functions and class constants? - Steph -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] 5.3 todos
Hi Hannes, Think about the online manual. In 2 years from now people should still be able to read the upgrading guide and it should still make sense without needing to hunt down random release announcements or outdated NEWS files. The upgrade which gets committed to php-src will be taken, word by word, and ported to Docbook and made available at http://php.net/migration53 (just like /migration52 and /migration51..). But this was actually an add-on after I put the initial 5.1 upgrading guide together. A 200-line document became a 500-line document overnight, and voila - nobody reads the thing. Is this entirely necessary? (I can see a case for listing new classes in the global namespace.) Unless you want duplicated work, one file to php-src and one for the docs, yes. I'd like to know why you can't just take release info from the release notes for the manual. Duplicating the release notes seems a bit pointless. - Steph -- 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] 5.3 todos
Hi Lukas, all, 'Scuse top-posting, no >>> history marks here. It's not actually 'open' so much as 'under way' - the file's in place and has content, it just needs some thought applying to it. In the last two upgrading guides, we've repeated much of what is already in the NEWS file or in the release notes. This makes me wonder what the point is of having an upgrading guide...? The initial idea was to have some way to tell users in general (and sysadmins in particular) which existing code might break in the new PHP version, and how to work around those issues. It should be a relatively short file if we stick with this, but what we actually have (now and for the last two releases) is 500-plus lines of text that includes lists of all the new functions and constants in the PHP global namespace. Is this entirely necessary? (I can see a case for listing new classes in the global namespace.) For the same reason, I don't really see how it's relevant to mention new core extensions (unless as replacements for previously existing core extensions), new functions, stuff that is newly supported in Windows or new features in PHP syntax (exception: reserved keywords). We should focus on things that are deprecating, missing or else behave differently in some way IMHO. Comments welcome, - Steph - Original Message - From: "Lukas Kahwe Smith" To: "PHP Internals List" Sent: Wednesday, February 11, 2009 5:07 PM Subject: [PHP-DEV] 5.3 todos Hi, It seems aside from some smaller commits, the last minute closure change has gone through without issues. Our todo list however doesnt have that many checked off items: http://wiki.php.net/todo/php53#next_release_beta2rc1 To me the biggest issue is the UPGRADING README. So please approach Steph if you want to help. The following items remain open: - write UPGRADING README file (Steph) - add more tests for fileinfo (Felix/Derick) - make all extensions use php implementation of getenv (Pierre) - reorganize the bundled php.ini files to production/development recommendations (Eric/Nathan) - re-enable phar for big endian systems (Scott) The following remain open and it does not seem someone is actively working in it: - Fix static build of extension when static is the default and –enable- snapshot-build is used - Improve the build script to ease the parsing of the output and QA - ob_flush() should fail to flush unerasable buffers - tokenizer misses last single-line comment - ob_start(): inconsistent behaviour with undefined callbacks - pcntl_signal needs declare(ticks) which is deprecated since 5.3 - opendir() fails on Windows directories with parent directory unaccessible - Bus error during build of phar.php - PDO: persistent connection leak - memory leak in the re2c - fix memleak in zend_object_handlers.c - PHP_5_3 missed merge from PHP_5_2 for write_func callback Other issues recently raised on the list - reflection/arginfo overlap issue - Throwing E_DEPRECATED on startup - casting doubles to ints I have send out an email to several larger OSS projects that are on the primary-qa-te...@lists.php.net mailinglist. BTW: please subscribe any key projects you know that are not yet on this list: http://pooteeweet.org/blog/1439 Again, I will be offline 99% of the time starting this Saturday until March 5th. I hope that while I am gone we will have another release that covers the above mentioned issues and ideally that would be RC1 (unless bigger issues are uncovered that require larger changes). Until then please let me know if you are taking over any of the above items so that I can update the wiki. Speaking of wiki, Pierre also has admin rights on the wiki and of course root access to the box. regards, Lukas Kahwe Smith m...@pooteeweet.org -- 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] [RFC lite] implement import of functions in namespace
Having ascertained that Lukas did not shoot himself on seeing this... This is a "testing of the waters" RFC. If there is interest, it will be followed with a patch. It should be noted that the patch for this has been available through the various vortexes of namespace syntax for over a year now, and it is an extremely simple patch. [RFC] Implement importing of functions to complement importing of classes and namespaces. Sounds like a darn good idea to me. - Steph -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] beta1
Hi Lukas, I am also waiting on some word on the upgrading guide, Steph??? Yes, I'm on it. - Steph -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] PHP 5.3.0beta1
One of the big items on the todo list is turning the scratch pad into an actual upgrading guide. Would be great if someone could take the lead on this (and others helping out too of course). I promised this a loong time ago, no problem with it now either. - Steph -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Undefined constants producing E_NOTICE
Hi Kuba, For the moment some unexpected behaviour caused by use of undefined constant may be hard to fix with low error reporting level. So don't use a low error reporting level. Moreover, treating an undefined constant as a string does not make sense. I know that PHP is intended to be a flexible language, but for me it's a bit thick. Just how is PHP supposed to know that some random string is intended to be anything else? - Steph -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] 2008 is 1s longer than normal.
No: http://derickrethans.nl/php_lags_23_seconds.php Hm, Wikipedia's apparently less than open there - [12:36] so how come PHP's different? [12:36] olson has information on it, but it's never used - Steph -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] 2008 is 1s longer than normal.
Hi Richard, In looking at http://en.wikipedia.org/wiki/Leap_second, there have been quite a few leap seconds - 34 since Jan 1st 1972. I make it 23, according to the info on that page... So, if PHP isn't making any changes does this mean PHP time is 34 seconds behind UTC? No. This would be a red herring anyway Richard, the Olson tz database used by PHP is used by several other projects too - including the GNU C library. http://en.wikipedia.org/wiki/Zoneinfo - Steph -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] About dropping magic_quotes in 5.3
"If not now, when?" Later? Would you mind reading the thread first please? :) The subject's a tad misleading at this stage. - Steph -- 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] About dropping magic_quotes in 5.3 (was: Re: [PHP-DEV] Re: PHP 5.2.7 + magic_quotes_gpc broken)
6.0 iirc its already off by default in that branch. Ilia, it doesn't *exist* in that branch! - Steph -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] About dropping magic_quotes in 5.3 (was: Re: [PHP-DEV] Re: PHP 5.2.7 + magic_quotes_gpc broken)
As much as I hate the feature, I am not certain that is a good idea in a minor release. "If not now, when?" - Steph -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] About dropping magic_quotes in 5.3 (was: Re: [PHP-DEV] Re: PHP 5.2.7 + magic_quotes_gpc broken)
Hi Pierre, A fatal error could be more effective. And the message can make the reason behind the error very clear. It's a very big jump from 'enabled by default' to 'fatal error'. It will break a lot of legacy code with no prior warning. By the way and for the record here, they (magic quotes, register global and safe mode) are already removed in php6. All the more reason to disable them all by default and have them throw E_DEPRECATED in 5.3. - Steph Cheers, -- Pierre http://blog.thepimp.net | http://www.libgd.org -- 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] About dropping magic_quotes in 5.3 (was: Re: [PHP-DEV] Re: PHP 5.2.7 + magic_quotes_gpc broken)
Hi Scott, Agreed, going from on by default to removed just feels odd. I'd disable it by default in 5.3 and lets start throwing a strict error if the configuration enables it. Why do we have E_DEPRECATED if we're not going to use it? - Steph -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] quick polls for 5.3
Hi Lukas,
1) ext/mhash in 5.3. ext/hash has all the functions, so the entire BC
break will be that "if (extension_loaded('mhash'))" will need fixing if
mhash is removed (answer both)
I) enable ext/hash by default
+1
II) remove ext/mhash
-1, BC concerns. Can't we just deprecate it in 5.3 and remove in 6.0?
2) deprecate ereg*. ext/ereg is an extension as of PHP 5.3. Since ext/
ereg is more or less redundant with ext/preg and is likely to not get
much unicode love for PHP 6, the question is if we should mark it with a
E_DEPRECATED in PHP 5.3
+1
3) resource constants (choose one)
a) Should we deprecate constant resources (mostly used to emulate STDIN
and friends)
b) Should we instead just throw an E_STRICT
c) Document as is
C
4) keep ext/phar enabled by default in 5.3?
+1
5) keep ext/sqlite3 enabled by default in 5.3?
+1
6) enable mysqlnd by default in 5.3? (answer both)
I) enable mysqlnd by default
+1
II) also enable ext/mysql, mysqli und pdo_mysql by default since there
will be no external dependencies in this case
-1... if it was just one extension OK, but three is too many
7) should Output buffering rewrite MFH? this one comes with some baggage,
we need enough people to actually have a look at how things are in HEAD
and make it clear that they will be available for bug fixing and BC
issues resolving. the risk here is obviously that any BC issues will be
hard to isolate for end users.
+0.5.. I'd really like to see it in 5.3 because it was supposed to fix
several OB issues, but it's probably too late in the cycle now
8) MFH mcrypt cleanups in HEAD. either the make sense or they dont, so
either (choose one)
a) revert in HEAD
b) MFH to 5.3
0 (not enough insight to vote on this)
Thanks,
- Steph
regards,
Lukas Kahwe Smith
[EMAIL PROTECTED]
--
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] [PATCH] bracketed namespace declarations
Hey Greg, Remember, the patch I'm proposing would only be necessary for people using un-namespaced code combined with namespaced code (already a bad idea) *and* scattering "use" statements throughout the global code. If it's 'already a bad idea', why support it? Also, the *only* supported use case behind allowing multiple namespaces per file is to allow people to mash pre-existing separate PHP files together, and have them still compile. Requiring brackets is designed to make it more readable, and the "use" restriction furthers that goal. This part makes sense. - Steph -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Call it: allow reserved words in a class or not?
Dan, PHP may be a hybrid language, but the fact is you're implementing object oriented functionality, and as such should be implementing it in a way that follows de-facto standards in object oriented language design. I should be able to overload your internal array object, and yes, arraysshould be objects. I'm really confused as to why you'd want to overload something that doesn't exist. Can't we just deal with reality here? Several million PHP scripts written over the last decade will still able to run without change under PHP 5.3. Several PHP developers are not OO programmers and some - maybe even most - never will be. Don't you think that suddenly turning arrays into objects might cause just the teeniest bit of a problem here? Javascript would be a prime example of a non-standard object oriented approach, and yet that still manages to support the basics in a way that make sense. Great, so drop PHP and go use Javascript. Oh wait - you can't. Because *it wasn't designed do the same job*. - Steph -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Call it: allow reserved words in a class or not?
In .NET, I can stick an Array class into my own namespace, extending the System.Array type if I want to and use it in my code without issue. Why can I not do that here? Is it simply that you're so worried about backwards compatibility that you feel that you can't make the necessary changes to the language to implement something fully? .NET is an object oriented language. It has something called System.Array. PHP is a hybrid language. It does not and hopefully never will have something called System.Array. It's like the difference between English and Esperanto... and you're telling us 'cough' should rhyme with 'cow' because that's how Esperanto would have it. But English is so much easier to learn, if more difficult to master, that it's become the lingua franca for the 'net. - Steph Dan On Thu, Nov 6, 2008 at 11:43 AM, Ben Davies <[EMAIL PROTECTED]> wrote: > Isn't the ability to do that one of the biggest reasons for having > namespaces? To avoid having to fill your class names with junk. > The examples are namespaced appropriately, they tell the developer that > it's > a Helper for Arrays in the MyFramework framework. I shouldn't need to > suffix > the class name with 'Helper' to reconfirm that, just because the PHP > engine > doesn't like it. "This thread really should be re-titled to "allow reserved words as a classname or not". Then perhaps the only logical response to the question would be so obvious that there would be no thread... oo-er..." I think you might be deliberately missing Dan's point here: array is a reserved word because it is not namespaced. If the PHP native function array() was namespaced to PHPCore\array() then Dan could create a class or function called array under his own namespace. This is exactly what namespacing affords us. array() is only a reserved word because it is not a directly accessable native datatype. If array() was an object Array, this wouldn't be a problem. This namespaces issues highlights the very fundamental issues with PHP, and glib, childish responses like yours only serve to score points. Grow up and join the conversation. Ben Davies | Lead Developer | Stickyeyes 6th Floor, West One, Wellington Street, Leeds, LS1 1BA Email: [EMAIL PROTECTED] 0113 391 2929 | | Fax 0113 391 2939 This e-mail may contain information that is privileged, confidential or otherwise protected from disclosure. It must not be used by, or its contents copied or disclosed to persons other than the intended recipient. Any liability (in negligence or otherwise) arising from any third party acting, or refraining from acting, on any information contained in this e-mail is excluded. The views expressed may not be official company policy, but instead, the personal views of the originator. If you have received this e-mail in error please notify the sender and delete the e-mail. -Original Message- From: Steph Fox [mailto:[EMAIL PROTECTED] Sent: 06 November 2008 11:01 To: Dan; troels knak-nielsen Cc: Larry Garfield; internals@lists.php.net; [EMAIL PROTECTED] Subject: Re: [PHP-DEV] Call it: allow reserved words in a class or not? > Isn't the ability to do that one of the biggest reasons for having > namespaces? To avoid having to fill your class names with junk. > The examples are namespaced appropriately, they tell the developer that > it's > a Helper for Arrays in the MyFramework framework. I shouldn't need to > suffix > the class name with 'Helper' to reconfirm that, just because the PHP > engine > doesn't like it. This thread really should be re-titled to "allow reserved words as a classname or not". Then perhaps the only logical response to the question would be so obvious that there would be no thread... oo-er... - Steph -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Call it: allow reserved words in a class or not?
This namespaces issues highlights the very fundamental issues with PHP, and glib, childish responses like yours only serve to score points. === The 'very fundamental issue' here is that you're expecting namespaces to allow things that are not legal in non-namespaced PHP code. The entire thrust of the internals discussion preceding this has been that preserving similar resolution rules in namespaced PHP code to those that already exist, will avoid potential confusion. And don't tell me to 'grow up' or I'll set my grandchildren on you ;) - Steph -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Call it: allow reserved words in a class or not?
Isn't the ability to do that one of the biggest reasons for having namespaces? To avoid having to fill your class names with junk. The examples are namespaced appropriately, they tell the developer that it's a Helper for Arrays in the MyFramework framework. I shouldn't need to suffix the class name with 'Helper' to reconfirm that, just because the PHP engine doesn't like it. This thread really should be re-titled to "allow reserved words as a classname or not". Then perhaps the only logical response to the question would be so obvious that there would be no thread... oo-er... - Steph -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] namespace separator and whining
As you pointed out, there is no autoload for functions, so people are accustomed to ensuring that all functions are loaded before usage. Am I missing something? Yes - you're missing the possibility of overriding, AKA naming collisions between internal and userspace funcs/consts. - Steph -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] namespace separator and whining
Hi Greg, By doing the resolution I've suggested (and Stas, incidentally, was the first to suggest this): classes: 1) ns\class 2) autoload ns\class 3) FAILBOAT functions/constants: 1) ns\func or ns\const 2) internal func\const 3) FAILBOAT We get the best of #1 and the best of #2, and it makes coding easier in the long run. Stefan just convinced me of this in a *much* shorter post :) +1 - Steph Greg -- 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] namespace separator and whining
Hi Stefan, Dev writes a script, uses autoload, overrides global class. > Distributed to user, that has ns.lookup=On as you propose, user borks > his > install, lacks the file containing the class, gets the global class -> > obscure error messages because of nonexisting methods in places > unrelated > to > the place where the actual error happened. Not really a good idea, IMO. This is what happens now, right. So what's different? With the proposed change -- failing at "step 3", it doesn't. It fails at the time that you try to create the instance, saying the class was not found, which is actually the case. For clarity... Current behaviour: 1) check for namespaced\classname 2) check for internal classname 3) try to autoload namespaced\classname 4) fail Proposed (Stas, Greg): 1) check for namespaced\classname 2) try to autoload namespaced\classname 3) fail What I'm suggesting is a configurable switch between that proposed order and: 1) check for namespaced\classname 2) try to autoload namespaced\classname 3) check for internal classname 4) fail > Failing there is the best option. It's not like you have to prefix > every > single occurence, you just have to say at the top of the file "When I > say > Exception, I mean \Exception". The point is that your dev would have done exactly that, so whether your user has the setting on or off is immaterial. - Steph No, the dev didn't mean \Exception, he meant *his* exception, the one that he has in the current namespace, and any way your setting would not have resulted in any error, because for the dev, autoload worked. I see your point. OK, thanks. - Steph -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] namespace separator and whining
Hi Stefan, Dev writes a script, uses autoload, overrides global class. Distributed to user, that has ns.lookup=On as you propose, user borks his install, lacks the file containing the class, gets the global class -> obscure error messages because of nonexisting methods in places unrelated to the place where the actual error happened. Not really a good idea, IMO. This is what happens now, right. So what's different? Failing there is the best option. It's not like you have to prefix every single occurence, you just have to say at the top of the file "When I say Exception, I mean \Exception". The point is that your dev would have done exactly that, so whether your user has the setting on or off is immaterial. - Steph -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] namespace separator and whining
IT will break the code from everybody who doesn'T expect such a flag exists and the average application user won't know and jsut see errors which "randomly" occur. Erm, how is that going to happen? This is basically a tighter setting that can *optionally* be used and should *always* be used in development. It would be documented loud and clear in the PHP manual, where people go to find out about new/different-from-Java language elements. There's a *possible* slowdown and *possible* conflicts if you never use it, but the people most likely to never use it are those least likely to be loading lots of third-party OO code in the first place. No ini settings for basic behavior. Ah well we might as well throw out E_STRICT too! - Steph -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] namespace separator and whining
What am I missing? That INI is the worst we could do. Because it prevents from writing portable code. This particular INI doesn't prevent anyone writing portable code. It simply gives the option of a 'tighter' development mode. - Steph -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] namespace separator and whining
Hi Greg, all, For this reason, the only resolution that we should be considering is: classes: 1) try ns::class 2) autoload ns::class 3) fail functions/constants: 1) try ns::function/ns::const 2) try internal function/const 3) fail. I see this as giving priority to library authors rather than the average PHP user. So here's another option - and if I mention the word INI, will y'all promise to read to the end before you shout at me? We could have an INI_SYSTEM switch. ns.lookup=Off means you _have_ to prefix because otherwise resolution will fail with a fatal error, but ns.lookup=On means that anything not prefixed and not local goes through the full lookup, i.e. it does what is currently done outside a namespace context. You'd switch ns.lookup off during development and on in production, and the default would be on. Prefixed elements would be found at the first try regardless of the setting, but would fail after a single check for a global value if the element is not found when the setting's off. Non-prefixed code would fail when the setting's off, but would otherwise get by except in cases of ambiguity (easily remedied with a '\'). It would, however, run slower and be more prone to conflict, particularly in complex sites or applications. We make it very, very clear in the docs that prefixing is best practice, but at the same time we allow John Doe to import a couple of namespaced libraries without putting him through prefix hell. What am I missing? - Steph -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Re: [PHP-CVS] cvs: php-src /win32/build template.rc
How you got both files is beyond me - winres.h is not present in either the 2003 sdk or the 6.1 sdk (used with VC6 and VC9 respectively) - our current instructions for building involve renaming header files in the sdk which is a very silly thing. Nah, it'll be a legacy thing. I've only ever installed one compiler :) I bet it was overwritten with the final upgrade. - Steph -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] keeping traffic on this list manageable
Hi Lukas, Here I come to the key part of my idea. We would allow every PHP usergroup to also appoint one person that gets unmoderated access to the list. Great idea! Lets just create an interface were people can register their UG and manage the email address for the contact person (and maybe a few other things like their website etc). We have this already on php.net, no? But for now lets just assume that everybody in the community understands the beauty of such a liberal approach. There should be a similar scheme for teams that develop major PHP applications IMHO. Those developers are key. - Steph -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Re: Class visibility in namespaces
But the longer you wait, the more you're likely to run into implementation problems. I think what you meant to say was, 'the longer you wait, the more likely you foresee the implementation problems'. I don't know how many users you have. I'm not going to pretend I know how many users PHP has either. I do know though that if we get it badly wrong, it will cause a lot of people a lot of problems It doesn't matter what other languages do, because other languages don't have it 100% right either. If any of them did, why would there be more than one language for the Web? - Steph -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Re: Class visibility in namespaces
Hi Franck, we agreed long ago on a very easy scheme, there shall only be is-a and public classes. Do you really think it makes the scheme "easier" to allow for public classes only? Well, yes, actually. Class visibility is a common OO concept, that improves the encapsulation of the code, and which, I'm afraid of it, will be requested again in the future, like typed return values and typed properties Why be afraid of it? At least class visibility is something it's possible to add at a later stage, should a genuine need for it ever become apparent. A recurrent scheme, on internals, is to underestimate the PHP developer's skills and needs. Can I sell you a Google toolbar? :-) I promise you it'll be cheap! Not only is this behaviour a bit upsetting for those who want to use PHP seriously, but in the long run, this may lead to insufficient specifications, or arguable conception choices. When PHP5 was designed, it was probably thought that a specific resolution operator would make it "easier" for a "PHP developer" to distinguish between static and non-static calls... and so "::" was introduced, in spite of the fact that "::" is for long a namespace separator in various languages. "::" was introduced in PHP 3, not 5. Those 'various languages' you refer to barely existed at the time. And no namespaces were added to the language by that time, because it was probably considered that a "PHP developer" would never need such a thing... even though namespaces have existed for long in many OO languages. The first version of the Zend Engine with namespace support was rolled as a special edition of PHP 4.3.0 and released on php.net for public testing in 2002. This was originally scheduled for full release in PHP 5.0. (PHP is not, by the way, 'an OO language' in the sense you use the term.) It certainly wasn't withdrawn for the reasons you suggest. - Steph -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] alpha2 scheduled
Hi Marius, yes is true that i like to have strong opinions and yes i could be wrong in most of them but when all the comunity screems at the namespace issue "All the community" is not screaming at the namespace issue. "A minority of the community" is, but most of that minority would scream whatever we did. an semisolution would be an php.ini variable like NAMSPACE_SEPARATOR="::" :-) Now go away and think really hard about what you wrote there, and you'll maybe understand that smiley. - Steph -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] alpha2 scheduled
Hi Marius, Don't know i never saw something so ugly since c++ templates syntax I find it funny that php is designed by committee and no one listen to the community === You have written to this list a few times before. Here's a brief summary of your posts: 1) We should be moving to git not svn 2) We should drop $ for variables because it makes PHP 'bloated' 3) Mingw compilation (which we don't support) fails 4) If we want your help supporting firebird under Windows we should build it and send you a report 5) We're on slashdot (for \) === And the team continues even if is an bad decision (they call it technical one) if you see it from the point of view of syntax elegance it's not so pretty even c++ looks better . === I'm not even going to comment on that. - Steph -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] RE:
This is not what I meant, but there's obviously neither use nor interest in further discussing this topic as decision was already taken. I only wish people would not start rewriting history as other opinions or options didn't even exist so soon. I'm fine with making the choice, what I'm not fine with is presenting the thing as there was never any other options at all. We had plenty of options, maybe too many, we tried to choose the best, time will tell if we succeeded. Memory hole is not necessary for that. My apologies. I was talking about what we were left with by the time we reached the point of needing a meeting. There were of course several attempts (recent and not so recent) to retain :: because this is what *everyone* would have preferred to do. I certainly didn't intend to leave the impression that this hadn't been investigated fully, or that there weren't several proposals of ways to get around the known problems. - Steph -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] RE:
These aren't the only ways. OK. 4) Claim that there is no real problem in addressing ambiguous situations. - Steph -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] RE:
Hi Thomas, Actually I've been following namespaces for a fair while, but the issue of :: being a problem wasn't really raised until a few weeks ago. So while I'm aware of namespaces being under discussion for a fair while, yesterday was the first I'd heard about a decision being made for the backslash being used as a namespace separator. Sounds like I'm not the only one. OK, sorry if that seemed unfair. I should've aimed it at certain others really ;) You're correct, the :: issues were only fully understood when Greg took the time to investigate the options thoroughly. So you didn't miss a lot. Namespace *separator* discussions were long-winded and involved every Tom Dick and Harry turning up on internals@ with increasingly bizarre ideas, every time the subject arose over the last few years. That was when the real discussion of separator options took place. Lukas simply summarized the issues around the available options in his table during the irc discussion last Saturday, but the fact is he couldn't have really known the criteria - or the available symbols - without having those lengthy public discussions behind him. We couldn't have known his criteria and symbol set were correct without that history either; we'd have been stuck on 'why not :' forever. Hope it all works out, either way. As do we all :) - Steph -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] RE:
Hi Thomas, Anyway, my point is that there may be other options. Such as putting off a long-sought feature until it can be implemented properly. OK, since you obviously didn't do any background reading before posting to this list, let me direct you to the history behind this decision once again: http://wiki.php.net/rfc/namespaceseparator. Let me also point out that this only covers the last few weeks; the namespace discussions on this very list, in-depth and otherwise, date back some 5 years. If you read everything linked from that RFC, you will discover that there are two ways to implement namespace support in PHP 'properly'. 1) We can offer support for classes only and throw a fatal error when a function is encountered in namespaced code 2) We can use a namespace separator other than :: There is of course always option 3... 3) We can drop the whole idea of namespace support because whatever is done will appear 'wrong' to /. readers Every other option leads to ambiguity in namespace syntax. That's not because we need more time to think things over so it can be 'implemented properly', it's just straight fact. - Steph -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Re: namespace separator and whining
Hi lover, (sorry, couldn't resist) The correct syntax is: Note that static class elements are accessed using T_DOUBLE_COLON (::), and that the namespace separator \ is used to join namespace and element name. OK... thanks for the clarification. That does actually make perfect sense to me, I just read :: as a method call in Robert's example rather than as a new class. Guess I should sleep before typing 'as I understand it' again :) - Steph -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Re: namespace separator and whining
Hi Rob, Wouldn't it be: Yes, as I understand it. - Steph -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] namespace separator and whining
Yes, it does not mean that I was able to actually attend the meeting. Because... oh wait. It wasn't important to you. OK OK I'm not going to push this publicly. Just pointing out that most of us keep irc logs. Preaching by example. I didn't want to push this publicly, Pierre. Remember that. - Steph -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] namespace separator and whining
Hi, I'm not sure what's the hell is going on with you and Step, OK, Pierre. You got us. Greg and I have been secret lovers for the last 5 years and we've been planning to take over php.net the whole of that time. but if we can't answer to any of your mails without being accused of personal attacks, then it is going to be painful. You made a personal attack in a very public space. There have been a _lot_ of technical discussions off-list, including most of the recent Windows-related changes, but you pick on Greg and myself particularly - why, pray? - Steph -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] namespace separator and whining
Hi Pierre, Excuse me but while the idea to have an online meeting was great, sending a mail to ask to attend an online meeting 24 hours before and on a Friday was not a wised choice. I would have participated too if it was during this week or the next weekend. You were actually online throughout it, and were notified that it was happening at the start. In fact you were the first person to blog the outcome of the meeting. I do agree with Sebastian about not allowing functions and constants (from a principle point of view, as I barely see any example out there of NS and procedural code). Apart from PEAR? I'd to say that I do not care about which symbol is used. @Greg and Steph: Private discussions are bad. Or are you trying to say that this list can't be used as a discussion platform (even heated)? If we like to have a developer only list, let do it, but keep things in the public area, that's the only way to keep our decision process transparent for everyone. @Pierre: we didn't have a 'private discussion'. That this irc meeting was going to take place was noted on internals@ over a week ago following my 'consultation excercise', which incidentally practically all the core devs complained about due to the noise it generated. Only one internals dev requested to be notified of the details when the information was made public. Only one internals dev has complained that he wasn't invited, from which it would seem that the rest really didn't want to go through it all again, for one reason or another. It should also be noted that more were invited than actually attended, yourself included. The need for a dev-only discussion will I think become apparent if you look at the detailed investigative reports Greg gave. - Steph -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] namespace separator and whining
And I must agree with Sebastian: How do you test something that isn't even implemented yet? :D You apply the 'rough draft' patch against PHP_5_3 :D http://pear.php.net/~greg/backslash.sep.patch.txt As referenced in the original rfc for the backslash approach cited at http://wiki.php.net/rfc/namespaceseparator. - Steph -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Namespace issues
Hi, Guys, this is like junior school in here. Yep. Let me put some things in perspective: No, let me. Greg worked his butt off the entire weekend looking for the flaws in *all* the options available to us, including a couple of new ones that never even reached the list before he rejected them on technical grounds. Thanks to his efforts, we already have a pretty good picture of the strengths and weaknesses of each approach - and as should be obvious to all by now, there is no perfect solution. Whatever we chose, it's a compromise. What we're hearing here about European keyboard layouts is useful info because it gives some idea of how popular/unpopular the backslash would be as a solution and why, but it shouldn't carry as much weight as the accessibility argument against the triple colon. One is liveable, if not optimal, whereas the other is plainly not liveable for some. We've already heard two workarounds for the backslash issues, but there are none at all for ::: + imperfect eyesight. Clarity and simplicity are the two chief requisites. We're all fully aware of that, from Engine developer to n00b, so there's really no point in discussing it to death on-list at this stage. - Steph -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Namespace issues
I wasn't planning to open the ns separator discussion again. In fact I think
we'd all much rather avoid it completely...
As info, in a Spanish keyboard it's the same, Alt Gr+{the key to the left
of the 1}.
... but thanks for that part of your input (and same to Ólafur).
- Steph
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Namespace issues
The "german keyboard" issue isn't really one. {}[] are in the same "class"
of
characters (alt-Gr + number-row). So, as a programmer, you either have to
live with that anyway because there's no avoiding {}[], or you switch to
the
us layout while programming (which quite a few people do).
Also useful to know :)
- Steph
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Namespace issues
Well, on German keyboards, it's accessible but only by using ALTGR+?, which is not really a comfortable combination. Useful to know, thanks Philipp. Any more localized keyboard issues we should know about? Anyone? - Steph -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Namespace issues
Hi Lester, And there are no problems with those on foreign keyboards? If there are, those foreign keyboards are unable to offer either escaped chars or MS paths... which seems highly unlikely. But do I still understand that there is an alternative method that was not part of this last round of voting? And needs to be reviewed in light of the current 'consensus' ? It was linked from Greg's proposals too: http://wiki.php.net/rfc/namespaceref. Basically (assuming that we're saying we want ns support for functions/constants) Stas avoids the need for a second ns separator by using the syntax Name->Member for static access. The 'avoid the need for second ns separator' part of Stas' proposal has widespread support according to the poll, it's just a case of figuring a way to manage this without introducing ambiguity into the code. Both Stas' proposal and Greg's option #3 are flawed in that way (either to humans or to the Engine), so the search is on to find a solution that isn't ambivalent to either - always assuming it's possible. - Steph -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Namespace issues
Greg was so kind to give me part of his awesome upcoming Pyrus code. He actually has it running with both ':::' and '\' as namespace separators. So I thought I'd help out a tiny tiny bit by giving you all the choice of having a look at actual working code: http://php.net/~helly/triplecolon.html http://php.net/~helly/triplecolon-colored.html http://php.net/~helly/backslash-colored.html http://php.net/~helly/backslash.html I did say off-list that Nathan would be an immediate fan... (Nathan actually proposed this off-list during the survey, not knowing that the idea had been rejected 4 years or so back.) Revisiting this.. isn't a crime. It's the one ns separator we have available in PHP that won't mess up for people with bad eyesight, for one. Among developers, that's quite a big deal. The big question is whether we need a namespace separator at all. As far as I'm aware, this is still under investigation (and this time it's for real). - Steph marcus shift+;(x3) vs \ -- 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] Re: Sanity tally #2
Josh, please... What I'm wondering is how many of those "many" voted for or against a proposition for the wrong reason. For instance, how many users understood that 2 is not about the use of triple colon? If someone disregarded 2 because of the triple colon then it was a mistake, as the triple colon was only an example. Some wrote '#2 with a different separator'. Others focused on the separator itself and either voted for or against it. The fact is that this would also happen in RL once the thing's out there - some happy, some not, some actually finding the thing unusable. Specifically in the case of :::, those with less than 20-20 vision genuinely couldn't use it - and that is something we didn't really know before the poll. So that's shifted the boundaries a little in what will or will not be an acceptable solution. And I'm not saying it would change the result of that poll, if a poll on which separator to use had been conducted perhaps the triple colon would have won--it has had good numbers in the past. In fact it came second back in the day, so it was genuinely a contender. In the end, what I'm wondering is how reliable people are when asked about their opinion. Usually not much, but you know that already. I do, but I think you have to look beyond that to 'why' the opinion rather than 'what' the opinion. Even the rush of 'because everyone else is...' at the end was interesting that way. It implies that any sensible solution would be accepted by the majority. With that said, I'd enjoy having less noise on the list as much as anyone else. Amen to that. - Steph -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Re: Sanity tally #2
That wouldn't be the right thread to discuss the merits of a solution, anyway. This thread is about the tally, and I'm trying to interpret it. I did actually keep tabs on this. Yes the choice of separator played a part for many. However there were just as many who were happy with it - and the same would have applied whatever separator was used. However, the public part of this debate is over now. The Big 3 are very aware of the tally and are very capable of drawing their own conclusions from it. Everyone else on internals@ never wants to read 'the N word' ever again. I strongly suggest we all drop it and let them debate amongst themselves in peace for a while ;) - Steph -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Re: my last attempt at sanity with namespaces
I'm just a mere user, but if we go for other namespace separator (be it ::: or :> or anything else), then I'd rather see it used both between namespace and class/function/constant name *and* between namespace parts. OK, so maybe I should explain one little thing about the significance of those results: we don't need a namespace separator. 74% of those voters either actively requested or said they could live with Greg's option #3. Now, the philosophy that separates that option from Greg's other proposals is that it doesn't try to avoid conflict; it accepts that there will be ambiguity, and then tries to deal with it. This is also the approach Stas' proposals take. No more namespace separator arguments, ever. It was worth it :) - Steph -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] Final 'sanity tally' for Greg's proposals (only)
OK, this is what we have. Please don't send any more votes on this now :) NameIssue AIssue B == Greg#2 (alt #3, #1)Yes Guilherme #3 Yes Kalle #4 Yes Tony Bibbs #3 Yes Jaroslav Hanslik#1 (alt #3)Yes Nathan Rixham* #2 (DS, alt #1 DS, #4) Yes Liz #1 (alt #3)Yes Andrei #2 (alt #3, #1)Yes Janusz Lewandowski* #4 (alt #3)Yes Steph #3 (alt #2)Abstained Josh Davies #2 (DS)Yes Lester* #3 Yes Alexey #3 Yes Marc Boeren #1 (DS)N/A Derick #1 No Vesselin Kenashkov #3 Yes Lars* #3 (alt #1)N/A Karsten Damberkalns #1 (alt #3)Yes Jochem Maas #2 (alt #3, #1)Yes Richard Quadling#1 (alt #2)No Justin Carlson #3 N/A James Dempster #1 Yes Christian Schneider #3 N/A Ben Ramsey #3 N/A Ron Rademaker #3 N/A Luke Richards #1 Yes Stas#3 No Geoffrey Sneddon#1 Yes Scott #1 (alt #3)N/A Michael Fischer*#2 (alt #3)Yes Timothy Boronczyk #4 (alt #3)Yes Josh Heidenreich#3 Yes Daniel P Brown #3 Abstained Mark Karpeles #4 (alt #3)N/A Jeremy Darwood #3 (alt #1 DS) N/A Arvids Godjuks* #3 (alt #2)Yes Benjamin Schulz #3 N/A Chuck Burgess #2 (alt #3)Yes Marcel Esser* #1 N/A Ryan Panning#2 (DS)Yes Nate Abele #3 Yes Ken Guest #2 N/A Chris Stockton #3 N/A Mikael Forsberg #3 N/A Nate Tallman#3 N/A Erik Schulz*#3 Yes Stephane Lambert#1 N/A Catalin Alexandru* #3 N/A Mike Willbanks #3 Abstained Aaron Wormus#3 (alt #1)N/A name* = corrected/altered/clarified initial vote DS= 'with different separator' Issue A: #1 - 19 (3 with different separator) #2 - 12 (3 with different separator) #3 - 37 #4 - 5 Issue A weighted (first choice gets 2 points, rest 1): #1 - 24 + 7 = 31 #2 - 18 + 3 = 21 #3 - 50 + 12 = 62 #4 - 8 + 1 = 9 = 100/2 = 50 people Issue B: Yes - 26 No - 3 (see Richard and Stas' arguments) Abs - 3 N/A - 18 = 50 people -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] Fw: my last attempt at sanity with namespaces
... and this poll is now closed. Thanks Aaron! - Steph - Original Message - From: "Aaron Wormus" <[EMAIL PROTECTED]> Newsgroups: php.internals To: "Greg Beaver" <[EMAIL PROTECTED]> Sent: Friday, October 17, 2008 6:12 PM Subject: Re: my last attempt at sanity with namespaces From the peanut gallery: +1 #3 for disambiguity Speed is my top priority, so if #3 causes issues I would have no problem with #1. Aaron Greg Beaver wrote: Hi, http://wiki.php.net/rfc/namespaceissues Read it and discuss. Let's be clear people: the technical problems in namespaces are limited and solvable. The problems in the political environment surrounding them may not be. Wouldn't politics be a stupid-ass reason to remove namespaces? Greg -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Re: Sanity tally #2
Hi Stas, So far, my proposals hardly got any hearing at all, fair or otherwise - they were totally ignored on the vote - never even mentioned except for the note in Greg's wiki (which, despite being incorrect, was never fixed or changed), and it looks like at least some of the persons were under impression they vote for something I had proposed and in fact voted for something completely different. Don't worry, I'll work out some way to rectify that if needed (hopefully without flooding internals@ again). All we're really getting out of this straw poll is a broader picture of the elements that PHP users would or would not like to see. - Steph (4 votes to go) -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] following http://wiki.php.net/rfc/namespaceissues
My vote is option 1 please. "use ::: as separator between namespace name and element" That's #2 :) Please clarify. Also - please (briefly) explain why. - Steph -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Re: Sanity tally #2
Seems everyone is going for #3 ... I'm with the crowd. +1 on #3. OK, this isn't a good reason. Please try to treat this poll with some seriousness. The voting patterns became skewed from here on, so the poll's still 5 votes away from completion because I can't sanely use wildcard votes. Would anyone still planning to vote please include a *brief* explanation of why they're making the choices they're making? Thanks, - Steph -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Re: Sanity tally #2
Hi Daniel, There are about six total concurrent threads on this right now. Would it make sense to create an OFFICIAL voting thread and *only* count new votes posted to that thread from now until the fifty-vote mark? Otherwise it seems that it introduces more confusion into an already loaded issue. Difficult, because some of the voters aren't usually subscribed to this list. But I hear what you're saying. Another time we need a straw poll across all the bases, it might be better to stick it on a site somewhere. This time, we only need 6 more votes and the poll will close anyway, so just bear with me a little longer :) - Steph -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] Fw: namespaceissues
Another one who can't get through... - Original Message - From: "Ken Guest" <[EMAIL PROTECTED]> To: <[EMAIL PROTECTED]> Sent: Friday, October 17, 2008 3:37 PM Subject: Fwd: namespaceissues -- Forwarded message -- From: Ken Guest <[EMAIL PROTECTED]> Date: Fri, Oct 17, 2008 at 3:26 PM Subject: namespaceissues To: [EMAIL PROTECTED] I'm inclined to vote (if I'm eligible) for option 2. k. -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Re: Sanity tally #2
Hi Lukas, We are not ready yet. So for now I will not force a decision just yet. Hopefully next week ... I'm going to stop this tally at 50 responses. That should be enough to show us where people generally are coming from. - Steph -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Re: Sanity tally #2
just wondering if there are any cut of dates for the tally dates / rounds etc? When this tally started out, I'd been told that there had to be a cut-and-dried answer by tonight or forget it. Then it was pointed out to me that Stas' proposal wasn't getting a fair hearing. Then it turned out that #3 (which is in the lead) is conceptually quite close to Stas' proposal anyway and the devil is in the details. So really the remit's changed 3 times in the last 15 hours, because now (my) chief hope is to get a public mandate for #3 on this round and have Stas, Greg and Dmitry come together to work on polishing it without further ado. But #1 might still win, and if that happens we'd need to put it to the vote against Stas' original proposal because they're very different concepts. So basically - I'm winging it. Hope that suffices :) - Steph -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] Re: Sanity tally
Hi Michael, Forwarding to internals@ and counting you in. I tried to mail the list, but it never seemed to go through. I'm just a user, but a serious one, with frameworks to maintain. I've already done a branch of an app framework to the current namespaces implementation comfortably. FWIW, and that may be very little coming from me, I'd like to raise my hand for Problem (1) solution #2, fallback to #3 E_WARNING on "you said Foo when I don't know if you meant namespace or class Foo" is good and fine. Problem (2) Proposed solution fine by me. Preference #3 - pick one of them, any of them, they're all improvements over the current state. Many thanks to all the internals folks for working on this one. Michael Fischer [EMAIL PROTECTED] - Steph -- Democracy is not average people selecting average leaders. It is average people with the wisdom to select the best prepared. - David Brooks -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] my last attempt at sanity with namespaces
Useful lib would have its own namespace and you would have your own. The assumption to date has been that most userspace code wouldn't use namespaces. Libraries and plugins would be more likely to use them. Ie the chance of a ns/class collision isn't likely to be so much under the control of the application developer as your example posits. - Steph -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] my last attempt at sanity with namespaces
that is so wrong, you know 3 was better - you're not in my club :'( Sorry to disappoint, but I'm collecting votes here, not making them up as I go along. - Steph -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] my last attempt at sanity with namespaces
Why would you do that? I.e. suppose there's library having namespace Zend::Controller::Action::Plugin - why would your name your class Zend::Controller::Action::Plugin and not Steph::Controller::Action::Plugin? Why do you assume all third-party software is going to be ZF? Or that code is going to be written around third-party software in the first place, rather than some useful lib that doesn't even exist yet might be slotted into an app 3 or 10 years from now? As it is now, every call to class::method() not accompanied with use should produce E_WARNING. ? That's certainly not how I read it. That's what is says: If the "use" statement is missing, an E_WARNING should also be thrown to alert the user to the ambiguity I assume that's only if there is ambiguity, but I'm not in a position to test the patch right now so can't say authoritatively (@Greg: speak!) but Stas - conceptually you aren't a million miles apart in the first place, so if you're finding that in your tests maybe helping figure a way through would be more productive. Greg complains that your version gives no warnings, you complain that Greg's version gives too many... please, guys, can you work together? - Steph -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] my last attempt at sanity with namespaces
Hi Stas, If you have two distinct sets of code, why you use same namespace for both of them? Namespaces are specifically designed so you could have different sets of code in different places. I was unclear there, sorry. I was thinking of the situation where 'I use a class that happens to have the same name as the namespace in a third-party lib I need to use in my application'. nb Stas - I asked the same question about warnings, Greg updated his proposal since then to answer it. As it is now, every call to class::method() not accompanied with use should produce E_WARNING. ? That's certainly not how I read it. I do not think it is an acceptable situation - this would make code migration a nightmare, since even if you never use functions and never even have any chance for a conflict, you still have to insert hundreds of imports into your code, just to shut up the warnings. I don't think it is a good idea. Feature that you do not need, can not disable and have to work around is called "bug". Can we double-check this? - Steph -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] my last attempt at sanity with namespaces
#1 and then #3. Thanks :) - Steph -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] my last attempt at sanity with namespaces
Heya Scott, I'd much rather see ::: used and don't care too much about those with code already written, we never guarantee BC on unreleased versions. Well, that narrows it down to #1 or #2. Though I don't object to #3 at all either, so indifferent! OK, so we have #1, #2 or #3 now from you. What should I put down as your primary vote? Regarding internal class resolving, it seems logical but will slow down resolution within namespaces. But I doubt this is much of an issue as it doesn't affect those not using namespaces. This appears to have been resolved between the two (and everybody else) now. Greg and Stas actually want the same thing here, they just misunderstood one another. (@Greg, @Stas: correct me if I'm wrong.) - Steph -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] my last attempt at sanity with namespaces
Hey Stas, It's basically the same that my proposal does, only you have to work twice as hard (two use's) and remember which name you assigned to what - and you still would have to rewrite the code to use another:: - so you have to both add use's _and_ rewrite the actual call code. And you'd have to do it even if names in class foo have nothing to do with names in namespace foo. Yes, but most times when there is conflict it will be between two sets of code. So importing someone else's namespace explicitly and giving it a new name is a good call IMHO. Greg, you have questions outstanding on-list (mostly from Stas). Please respond to them? nb Stas - I asked the same question about warnings, Greg updated his proposal since then to answer it. - Steph -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] my last attempt at sanity with namespaces
Greg... Hi Chris, This is actually option #3 on the list of solutions at http://wiki.php.net/rfc/namespaceissues I know. Steph: can you catalog this as a vote for it? Not without Chris even looking at the options. - Steph -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] Sanity tally #2
I was hoping to have at least 30 respondees at this stage, but actually have 29 (and that includes Hannes' abstention). However, to keep y'all up to date, here's where we're up to with Greg's proposals. Option #3 is in the lead, but that lead is still pretty fragile; there are only 3 full votes between #3 and option #1. 'Liveability' - ie whether people could live with an alternative option - is therefore becoming more important now. #4 appears to be out of the running completely, and #2 is a long way behind. If option #3 (or #1) gains a clear lead, we could get it down to two proposals (Stas' versus Greg's) rather than three in the final round. - Steph NameIssue AIssue B == Greg#2 (alt #3, #1)Yes Guilherme #3 Yes Kalle #4 Yes Tony Bibbs #3 Yes Jaroslav Hanslik#1 (alt #3)Yes Nathan Rixham* #2 (DS, alt #1 DS, #4) Yes Liz #1 or #3 Yes Andrei #2 (alt #3, #1)Yes Janusz Lewandowski* #4 (alt #3)Yes Steph #3 (alt #2)Abstained Josh Davies #2 (DS)Yes Hannes Abstained Abstained Lester #3 N/A Alexey #3 Yes Marc Boeren #1 (DS)N/A Derick #1 No Vesselin Kenashkov #3 Yes Lars* #3 (alt #1)N/A Karsten Damberkalns #1 (alt #3)Yes Jochem Maas #2 (alt #3, #1)Yes Richard Quadling#1 (alt #2)No Justin Carlson #3 N/A James Dempster #1 Yes Christian Schneider #3 N/A Ben Ramsey #3 N/A Ron Rademaker #3 N/A Luke Richards #1 Yes Stas#3 No Geoffry Sneddon #1 Yes name* = corrected/altered/clarified initial vote DS= 'with different separator' Issue A: #1 - 14 (2 with different separator) #2 - 8 (2 with different separator) #3 - 19 #4 - 3 Abs- 1 Issue A weighted (first choice gets 2 points, rest 1): #1 - 18 + 5 = 23 #2 - 10 + 3 = 13 #3 - 24 + 7 = 31 #4 - 4 + 1 = 5 Abs - 2 + 0 = 2 = 58/2 = 29 people Issue B: Yes - 17 No - 3 (see Richard and Stas' arguments) Abs - 2 N/A - 7 = 29 people -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] my last attempt at sanity with namespaces
after much more thought I think you're option #2 is actually best however the choice of ":::" separator in the example really confuses things and makes at an instant turn off.. This concept was originally presented using the ".." separator, and has been presented with others since. The separator isn't the issue with option #2 so much as that it's not a familar approach from other languages, and it's not particularly intuitive either. I like #2 too, but it's become apparent from the voting pattern that people really don't get it. We had a long discussion on the list about this exact option using the ':::' separator earlier in the week where many agreed to it in theory, but didn't actually recognise the exact same proposal when they saw it on the wiki. I think that pretty much disqualifies it as a solution for ns resolution in PHP, sadly. If people on this list aren't able to fully grasp the concept, it doesn't have a hope in user space. - Steph -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] 'Sanity' tally to date
i guess i should note that Steph's tally only includes votes on Greg's proposal. Stas proposal is obviously also still up for vote. Yes, we're going to have to go head-to-head at some stage very soon. Getting it down from 5 proposals to 2 would make that a bit more possible though. In that sense "doesnt work" is maybe a bit too harshly said in the appendix of Greg's proposal, though it does obviously point out an issue. Overall no proposal comes without some caveat (or this all would be easy). Is there no way to add Stas' on-list response to that accusation into the wiki? - Steph -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] my last attempt at sanity with namespaces
Hi Stas, I think it would be better if we had limited number of variants. We have many people here with all kinds of opinions, but the thing is we need to choose ONE way and no more. So I'd propose to cut some options, otherwise I suspect some people would be discouraged by too many options, or we get equal distribution between many of them and will get nowhere. Actually we're down to 2 options at this stage: #1 or #3. Mostly it's PHP users rather than devs doing the voting, but it's become obvious that options #2 and #4 are very unpopular with them - and that simplicity is a major element here. - Steph -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] 'Sanity' tally to date
Please can those people who didn't already express a clear and relevant
opinion, express it now? We don't have long to play with this if there's to
be namespace support in 5.3.
At present it looks like a two-horse race between #1 full disambiguation
(:::) and #3 explicit disambiguation ('use namespace').
Method of tally: anything that would be acceptable to the voter gets a
point. (A weighted version is also offered here.)
D/S means 'with different separator'.
NameIssue AIssue B
==
Greg#2 (alt #3, #1)Yes
Guilherme #3 Yes
Kalle #4 Yes
Tony Bibbs #3 Yes
Jaroslav Hanslik#1 (alt #3)Yes
Nathan Rixham #4 (D/S) N/A
Liz #1 or #3 Yes
Andrei- 'agreed with Gregs approach' N/A
Janusz Lewandowski #4 Yes
Steph #3 (alt #2)Abstained
Josh Davies - '#1 and #2 are functionally the same' N/A
Hannes- put in a plea for classes only in 5.3 N/A
Lester- WROTE SOMETHING LOUD N/A
Alexey #3 Yes
Marc Boeren #1 (D/S) N/A
Derick #1 No
Vesselin Kenashkov #3 Yes
Lars#3 (alt #2)N/A
Karsten Damberkalns #1 (alt #3)Yes
Jochem Maas #2 (alt #3, #1)Yes
Richard Quadling#1 (alt #2)No
Issue A:
#1 - 8 (1 with different separator)
#2 - 5
#3 - 11
#4 - 3 (1 with different separator)
Issue A weighted (first choice gets 2 points, rest 1):
#1 - 12 + 2 = 14
#2 - 4 + 3 = 7
#3 - 12 + 5 = 17
#4 - 6 + 0 = 6
Issue B:
Yes - 11
No - 2 (see Richard's rationale tho')
Abs - 1
N/A - 7
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] namespaces sanity: addition to RFC explaining why Stas's proposal doesn't work
Hannes, Lester... Can we please start small and then incrementally add more features? Lets start with classes only in namespaces in 5.3. The problem with that statement is that if it is used to ignore the other problems, then at some point it may be necessary to re-write all the new namespace code simply to allow additional features to be added! tough luck. If it needs total rewrite in the future then it needs total rewrite now to support the additional features anyway. That was my argument for the entire first half of this week. If either of you had looked at Greg's latest idea, you'd know that it removes that problem entirely. Please go and look at his proposals at http://wiki.php.net/rfc/namespaceissues, and then vote? Thanks, - Steph -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] my last attempt at sanity with namespaces
Hi, http://wiki.php.net/rfc/namespaceissues Read it and discuss. Let's be clear people: the technical problems in namespaces are limited and solvable. The problems in the political environment surrounding them may not be. Wouldn't politics be a stupid-ass reason to remove namespaces? It sure would :) "Conflict between namespaced functions and static class methods" #3 is sheer brilliance IMHO. No BC issues for Karsten and friends, nice clear warnings on conflict and an easy way to fix them (I saw the draft patch), no performance hit any place that should matter, and above all - nobody else even thought of approaching the problem from that end in all this time, so kudos to you! Since I've been championing #2 for the last several weeks I obviously wouldn't object to that solution either, but I think #3 has far more elegance. "Resolving access to internal classes" I'll abstain on this one because I don't feel qualified to weigh the issues (ie I neither use nor write third-party dev tools). Thanks Greg! - Steph -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] namespaces and alpha3
Hi Elizabeth, This can be solved in three ways. 1. Greg's "leaf" solution foo::bar->baz(); - namespace foo::bar, function baz foo->bar::baz(); - namespace foo, static method bar::baz Personally I don't like this, get confusing even if we pick some weird operator like :> 2. Don't allow functions or constants in namespaces Simplest solution but appears to piss off all the people who have never actually used the current implementation or hate OO on principle Nope, it's more the case that if we don't allow it we have to either say 'never' or set up an environment whereby functions and constants could be supported at a later date if need be. 3. Steph's idea - Change the separator (I vote ':::' - easy to do, similar to what we have already) foo:::bar:::baz(); - namespace foo:::bar function baz foo:::bar::baz(); - namespace foo, static method bar::baz I like this too, minus the headache of arguing over the namespace separator (again) - in a perfect world this would be a single colon, but the ternary issues (people write stupid code, so we have to cater to them) strikes again. Actually that wasn't what I meant. I meant take Greg's "leaf" solution (huh?) without the ambiguous -> part for namespace elements, and yes I'd prefer : for this too but that's dead in the water. So: foo:::bar->baz(); - namespace foo, namespace element bar->baz(); foo:::bar::baz(); - namespace foo, namespace element bar::baz(); foo:::baz(); - namespace foo, namespace element baz(); foo::bar::baz:::bat->fez(); - nested namespaces foo, bar, baz, namespace element bat->fez(); ::baz(); - global element called within namespaced code Those last two work out fine because :: is a scoping operator, not class-specific (which point it took me a while to get my head around). I think Greg's T_NS_MEMBER was the best idea ever for dealing with this sanely, he just did it so quietly we didn't notice: http://marc.info/?l=php-internals&m=122265715319308&w=2, and read all the way to the end. Taking ns elements and scope as different principles means we never get the 'dots before the eyes' issue that caused ::: to be turned down in the first place. Derick won't like ::baz() though. - Steph -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] namespaces and alpha3
anyways, given the current state most people voted to remove namespaces from PHP 5.3. i assume that all people that casted these votes were (and still are) confident that they actually know what they voted on. maybe some of the people involved in finding the current proposals will try to document the issues and the solution (and the issues in these solutions) onces more in the hopes of changing the minds of some of the people that have voted. i personally have spend enough time on namespaces for now that i will not involve myself in that any further for now. I think we should wait and see what Greg et al come up with. If they're close to a solution they believe will be acceptable to all, we're voting too soon. - Steph -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] namespaces and alpha3
Hi Josh, I'd like to point out that those people started working with namespaces *before* the idea of dropping them (or postponing them to PHP 6) appeared on the list. I doubt those people would have done the same if they had been told that namespaces may very well not be available until PHP 6. Surely everyone can see the very public ongoing discussions on internals@ over the course of this and last year? Namespace support in 5.3 received quite a lot of coverage this year through blogs, articles and presentations, that's why some people started implementing them or prepared to migrate their codebase. Now if they're told it's postponed indefinitely (until PHP 6 gets a tentative schedule) they'll feel burned and they'll think twice before investing any time in testing new features in future releases. There's a very big difference between 'testing' and 'preparing to migrate a codebase'. I think that's what Stas meant, people would not take the risk to implement such extensive changes without the assurance that namespace will be available. Those who already did were pretty sure that 5.3 would have namespaces. And of course those same people don't mind a bit if the implementation has changed 8 times in the last 6 months, because they understand that they're testing a moving target. No? - Steph -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] namespaces and alpha3
Stas... And people believed us and took the risk. Which you just said they wouldn't do. And now you propose to teach them the lesson that trusting PHP core developers that they actually deliver is a bad idea. It seems a sounder policy than teaching them they can't trust that what is actually delivered will be robust! - Steph -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] namespaces and alpha3
Hi Andi, I don't think postponing this to another big release is going to do anyone any good. You will not see magical revelations because it's postponed by another year. No, but we might see a broader agreement, and that would give more of a basis for user confidence in moving to namespace usage. Greg, Stas, Dmitry all three have deep understanding of the issues. In fact, I think we are closer to agreeing on a solution than it appears. I believe Dmitry is OK with Stas proposed solution + I think with a few more days of discussions with Greg we can nail something most feel OK with. I sincerely hope so. Please note that the really important/urgent reasons for why namespaces are needed are resolved. Many of the discussions are around edge cases some of which are not that likely to affect developers on a daily basis. Stas' syntax suggestion for dealing with ambiguous situations will likely almost never be needed. So let's not make an elephant out of it. Was that pun intentional? :) People who will actually start using this will find it beneficial (and I am sure pick-up will be faster in the OO realm than people here have noted). That would rather depend on whether people like the implementation, methinks. Btw, we are still in alpha. Historically a lot of these kind of issues have been resolved towards the end of the alpha cycle. That is OK. The beta/RC cycles are exactly intended to expose serious shortcomings in design with much broader community review. I can assure you two things though: a) namespaces are needed by many. b) We will never make everyone happy. I concur. Just let's not get trapped into one solution while under pressure at alpha stage, and then be stuck with it forever if it turns out to be less than optimal. - Steph -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] namespaces and alpha3
Namespaces are for big projects. Staring big project using namespaces when it's not even clear they'll be in 5.3 is an insane risk, nobody would do it. Only 8 hours ago, one Jean-Phillipe Serafin wrote: "Many people have starting working on top level application using namespaces, so there will a very bad buzz over the php community if namespaces are ripped out..." and there were further objections on the grounds that namespace support has been 'announced' on php.net. I agree with you that it's an insane risk, but that doesn't mean nobody does it. - Steph -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] namespaces and alpha3
Broad-scale testing with the ability to alter the implementation should problems become apparent. What you are talking about? Who'll be doing this broad-scale testing, when? Users. And I think Lukas' approach is good - use alpha as a testing ground. - Steph -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] namespaces and alpha3
If you can name something that could further our progress here and that can be done after 5.3 but can't be done right now - name it. Broad-scale testing with the ability to alter the implementation should problems become apparent. Otherwise I see absolutely no reason in postponing the decision. -- 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] namespaces and alpha3
Hi Lukas, We have 4 options. We know how things are without namespaces, we know how things are with the current implementation. This essentially leaves 2 choices that are untested for now. True, true. Both of these approaches have some uncleanness to them. If functions and constants get pushed to the global namespace while classes end up in the current namespace on include it can lead to some surprises. At the same time offering an ambiguous syntax to solve ambiguity when it occurs is also not beautiful. If we try out one of them in alpha3 and are unhappy I would not want an alpha4 to try out yet another one. But we will have the alpha3 either way at this point. So we could say lets try out the one that most people prefer for alpha3. If it sucks, we kick it out and move on. Good thinking - but we'll still see the same arguments even if most of us think it sucks. Then we can alternatively push it to PHP 6 or drop the idea all together. Dropping the idea altogether's unlikely to be an option now. I know that Dmitry and Greg were both thinking over alternative approaches, which did not yet come to a conclusion. Most of that revolves around other separators between or around namespaces. So we can keep cooking that. Yeah... I never had a response to ::: so I guess that one's been dumped out of hand somewhere off-list, but darn I hate -> reuse with a passion! Namespaces have turned out to be insanely complex. However it seems to me like most people that are voting are doing this on the basis that they feel that the problem itself is not yet understood by Stas/ Dmitry. Far from it. It's more that Stas/Dmitry (and Greg) have invested a lot of time and thought into the implementation and all three understandably want to see their work 'out there', whereas I'm far from alone in thinking it's just not ready to be 'out there' at this stage. - Steph -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] namespaces and alpha3
What would happen if we give the namespace implementation a chance to mature is that it can be delivered as a fully-fledged language element rather than a partially-fledged and potentially flawed one. What do you mean by "chance to mature"? Only chance for it to mature is people actually starting using it and not another week of discussing separators on internals. OK, bad choice of terminology. I really mean "a chance for the likelier problems to be ironed out". And people can't start using it if it's not only not released but there are developers rooting for it to be removed. Suddenly nobody uses CVS? I think if we were to ask explicitly for namespace testers on php.net once there's a full implementation we're all reasonably happy with, we'd find them. - Steph -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] namespaces and alpha3
I can name two: 1. Most (not all, I know, but most) of the use cases for namespaces are in the OO realm, and most of the problems they are to serve come from that realm too. So at least initially most of the active users, which wait for it impatiently, are OO users, and classes are the thing the care the most about. 2. Everything becomes so much simpler with only classes. Classes and functions have very different usage patterns in PHP, so if we try to serve them both we inevitably encounter some "inconsistencies" in how they are served, because of the different usage patterns, which may be a problem for some purists. I personally don't care too much for "inconsistencies" if they serve the user - i.e. allow to do useful things easier - but I know there are other approaches. FWIW, I agree with everything Stas says here. Please note that doesn't mean we _must_ drop them - I am just presenting the argument for it, I am aware of the existence of the arguments against too. The problem is we can't know whether restricting *future* evolution in namespace support is going to turn out to be a good idea. - Steph -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] namespaces and alpha3
Stas, We are in alpha indeed, and still looking at proposals, and still without consensus. The last thing I'd want is to see namespace support pushed under the carpet, but I'd rather see it at this stage of development as part of the PHP 6 development cycle (as originally Why? What would happen then that can't happen now? What would happen if we give the namespace implementation a chance to mature is that it can be delivered as a fully-fledged language element rather than a partially-fledged and potentially flawed one. in its final form. To me at least, that means namespace support is starting to look less and less feasible for 5.3 unless we can agree to never extend namespace support beyond classes. Which we don't. We could agree on anything, if we only actually worked on agreeing, instead of working on it not happening. I am really surprised why you put so much effort into trying to undo the much needed feature. Not trying to undo it, just trying to prevent a horrible mistake being made under pressure. If I were trying to undo it, I'd be against namespace support in PHP 6 rather than suggesting its development belongs there! - Steph -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] namespaces and alpha3
Hi, Nobody talks about "without testing", we are in alpha. But I'm talking about working on it, not pushing it under the carpet and hoping it somehow gets better there. I am working on it, so do other people, but chanting "let's remove it" is not working. If anything is "negative", this is. We are in alpha indeed, and still looking at proposals, and still without consensus. The last thing I'd want is to see namespace support pushed under the carpet, but I'd rather see it at this stage of development as part of the PHP 6 development cycle (as originally planned) than in the 5.3 development cycle (where it probably doesn't belong anyway). It's become clear that there can't simply be a 'class-only' version in 5.3 without planning for potential extension of that in 6.0, and in fact that's the sticking point. We're trying to second-guess forward compatibility for something that doesn't yet exist in its final form. To me at least, that means namespace support is starting to look less and less feasible for 5.3 unless we can agree to never extend namespace support beyond classes. Which we don't. - Steph -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
