Re: [PHP-DEV] namespaces sanity: addition to RFC explaining why Stas's proposal doesn't work
On Thu, Oct 16, 2008 at 05:23, Gregory Beaver [EMAIL PROTECTED] wrote: Hi again, I was asked to explain why I hadn't included ClassName-Method(); in the list of ideas that solve the ambiguity problem. I added a brief section Can we please start small and then incrementally add more features? Lets start with classes only in namespaces in 5.3. -Hannes -- 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
On Thu, Oct 16, 2008 at 12:35 AM, Greg Beaver [EMAIL PROTECTED] wrote: Hi, http://wiki.php.net/rfc/namespaceissues solution #3: +1 change of resolving order: +1 -- Alexey Zakhlestin http://blog.milkfarmsoft.com/ -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] namespaces sanity: addition to RFC explaining why Stas's proposal doesn't work
Hannes Magnusson wrote: I was asked to explain why I hadn't included ClassName-Method(); in the list of ideas that solve the ambiguity problem. I added a brief section 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! While I think it would be NICE to see a different separator, ':::' seems to annoy people, and using something else may cause problems for people with 'non-standard' keyboards who have trouble with some characters already? So 'USE' ? I'm I understanding things right on this one that one would 'define' the namespace in one sort of header file, and then add the use namespace to those files that build on the basic definition? I'm looking in particular here at a library like ADOdb, where 'adodb.inc.php' has a number of global functions which are then used by the various drivers. So 'adodb.inc.php' would define 'ADOdb' as a namespace and each driver would 'use namespace ADOdb' This seems a good example to work with and is the reason that simply dropping functions rang alarm bells with me. In fact it was the Date stuff from ADOdb that caused so much trouble with 'Date' in earlier releases so it seems appropriate to investigate how namespace would work with it? There are obviously other ways the problem could be solved, but a simply wrapper is the right approach initially? Or am I barking up the wrong tree? -- Lester Caine - G8HFL - Contact - http://lsces.co.uk/lsces/wiki/?page=contact L.S.Caine Electronic Services - http://lsces.co.uk EnquirySolve - http://enquirysolve.com/ Model Engineers Digital Workshop - http://medw.co.uk// Firebird - http://www.firebirdsql.org/index.php -- 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
On Thu, Oct 16, 2008 at 08:54, Lester Caine [EMAIL PROTECTED] wrote: Hannes Magnusson wrote: I was asked to explain why I hadn't included ClassName-Method(); in the list of ideas that solve the ambiguity problem. I added a brief section 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. -Hannes -- 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.
Solution #1 is imho the best one to disambiguate everything, but the
readability problem is not to be overlooked. To keep this short, just
read the following rewrite of the lines for the problem code:
foo.php
?php
namespace one..step;
function two(){}
namespace one;
class step {
static function two(){}
}
?
main.php
?php
include 'foo.php';
one..step::two(); // clearly namespace one, static method on class step
one..step..two(); // clearly namespace one..step, function two
?
Addressing the cons for the ::: separator:
1. all existing namespace code must still be rewritten, sorry about
that.
2. this..example..with::slight..error..is..much..easier..to::see();
Two sequential dots currently produce a syntax error, so the
implementation doesn't have to worry about ambiguity or bc-issues.
Disclaimer: I have not written any namespaced php code yet (so I'm not
worried about con #1 ;-)).
Ciao, Marc.
--
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
On Wed, 15 Oct 2008, Greg Beaver wrote: 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? In short: I'm for option #1 - and I would have to disagree with con 1 there -- we shouldn't give a damn about what people did with unreleased code. As for the internal classes resolving, I am not too keen on slowing down internal classes access. Obviously, this is only going to be ab issue if you use namespaces though. The bad thing I find about it is that this resolving is done during runtime -- but I suppose that'd happen anyway because of autoload(). A bit on the reasoning against option #2: Option #2 introduces a new concept yet again. Namespaces are already a new concept, and trying to make it even more confusing wouldn't serve anybody. regards, Derick -- HEAD before 5_3!: http://tinyurl.com/6d2esb http://derickrethans.nl | http://ezcomponents.org | http://xdebug.org -- 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
Thank you, Greg, for your efforts. My vote: +1 for 3) +1 for the change in __autolod() On Wed, Oct 15, 2008 at 11:35 PM, Greg Beaver [EMAIL PROTECTED]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 -- Vesselin Kenashkov developer at www.webstudiobulgaria.com
Re: [PHP-DEV] my last attempt at sanity with namespaces
Hello Greg, Am Mittwoch, den 15.10.2008, 15:35 -0500 schrieb Greg Beaver: [...] 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? Thanks for your efforts to fixing the remaining small issues with the current implementation. We wrote 50.000 LOC against 5.3 since half a year and I have to say the problems are minimal in the real world. But I understand the issues, especially the way how classnames are resolved are hard to guess. So +1 for your resolving proposal. The usage issue is not that easy for as I have a conflict of interests here: the lazy me votes for option 2 (no change for my code, ugly for those who use functions, which we don't do anyway), the one who weights whats best for PHP weights for option 3. So, the heck, let's do option 3, replacing use Foo::Bar with use namespace Foo::Bar is not that hard. Thanks for your solution! Lars -- Jabber: [EMAIL PROTECTED] Weblog: http://usrportage.de signature.asc Description: Dies ist ein digital signierter Nachrichtenteil
Re: [PHP-DEV] my last attempt at sanity with namespaces
Greg Beaver schreef: 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? well quite (although removal seems to me better than releasing without tackling the technical issues [those you documented in your latest RFC] ... but that's just me). so far as my +1 - I give my vote to Greg's preferred solution(s) (Greg get to vote with a +2 :-) ... I don't say this lightly, I've been convinced on-list and off- by detailed arguments and stacks of example code that Greg really has thought this through more than anyone else and what he offers is better than anything anybody else has brought to the table (regarding the issues highlighted in his last RFC) rgds, Jochem Greg -- 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
2008/10/15 Greg Beaver [EMAIL PROTECTED]:
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
With regard to accessing internal classes within a namespace, would
using the namespace separator be enough?
namespace blah;
function __autoload($class)
{
include $class . '.php';
}
$a = new Exception('hi'); // Internal
$b = new :::Execption('lo'); // Namespaced
It seems that it is up to me as the userland develop to explicitly
identify namespaces vs classes (I like :::), so I would have though
I'd need to deal with this when I want to call my namespaced class vs
a built in class.
Autoload would only get called if the correctly identified namespaced
class wasn't already present. If I said use the built in class, then
so be it.
OOI, would __autoload get blah:::Exception or just Exception ? If
the latter, how would I differentiate?
--
-
Richard Quadling
Zend Certified Engineer : http://zend.com/zce.php?c=ZEND002498r=213474731
Standing on the shoulders of some very clever giants!
--
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] namespaces and alpha3
Hi! 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. And people can't start using it if it's not only not released but there are developers rooting for it to be removed. There is a way to make both: have people use them, and not commit to BC or changes in 5.4 or a future release. Introduce E_EXPERIMENTAL as part of E_ALL. Make it the counterpart of E_STRICT. E_STRICT is reserved for deprecated features, and E_EXPERIMENTAL would complete this idea by letting us push experimental features such as namespaces (and any other extensions marked as EXPERIMENTAL in the manual) and have people play with them, so the core devs can get the feedback they need and improve or remove the feature in a future release. Have namespace related features throw E_EXPERIMENTAL warnings to people so they are aware this feature may not be present in a future release, or present but in another form. Regards, Stan Vassilev -- 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
I vote for option 3. http://wiki.php.net/rfc/namespaceissues Seems like the best fit all around. Steph Fox wrote: 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] namespaces sanity: addition to RFC explaining why Stas's proposal doesn't work
The thread where your vote has to go is: [PHP-DEV] my last attempt at sanity with namespaces started also by Gregory. On Thu, Oct 16, 2008 at 5:30 PM, Justin Carlson [EMAIL PROTECTED]wrote: I vote for option 3. http://wiki.php.net/rfc/namespaceissues Seems like the best fit all around. Steph Fox wrote: 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 -- Vesselin Kenashkov developer at www.webstudiobulgaria.com
Re: [PHP-DEV] my last attempt at sanity with namespaces
+1 for option 3, http://wiki.php.net/rfc/namespaceissues Really don't want to see option 2. Richard Quadling wrote: 2008/10/15 Greg Beaver [EMAIL PROTECTED]: 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
[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
[PHP-DEV] Re: my last attempt at sanity with namespaces
+1 for option 3 too (http://wiki.php.net/rfc/namespaceissues) - Chris -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] Re: my last attempt at sanity with namespaces
Hi Greg, everyone. Greg Beaver wrote: 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? Oh, yeah, absolutely! Conflict between namespaced functions and static class methods I would prefer #1, but am equally happy with #3. Note: Rewriting what we currently have to make it work with changes in namespaces would be something we happily attack as soon as we know the direction. Resolving access to internal classes Great. And the autoload-for-internal classes issue would be no issue if (like we currently do) one explicitly refers to them like ::Exception anyway. Regards, Karsten PS: We are still in Berlin at a TYPO3 core developer meeting, and I am happy to see this issue (almost) resolved. The same is true for the others here. Long live PHP! -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] Re: 'Sanity' tally to date
Steph Fox wrote:
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
you can add me down for a +1 on the solution to Issue B as well
- makes logical sense
--
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
Hi! Gregory Beaver wrote: Hi again, I was asked to explain why I hadn't included ClassName-Method(); in the list of ideas that solve the ambiguity problem. I added a brief section to the RFC that does so: http://wiki.php.net/rfc/namespaceissues#why_stas_s_proposed_solution_doesn_t_work What you wrote is incorrect - it does not require changing syntax everywhere, but only in very rare cases where actual ambiguity exists. Actual ambiguity would exist only when different people without any communication between them or common design plan work on one namespace (which should never happen, but we know our users, so we give them some help even if they don't follow good practices). There's absolutely no need to rewrite any existing code. -- 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
[PHP-DEV] Re: my last attempt at sanity with namespaces
On 10/15/08 4:35 PM, Greg Beaver wrote: 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? +1 for #3 -- Ben Ramsey http://benramsey.com/ -- 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
Hi! 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! So? We rewrote pretty much every other part of PHP - engine, object model, filesystem, etc. - and nobody died. Suddently with this particular feature there's tremendous fear of commitment. But we aren't going anywhere by sitting and talking about what if. We get anywhere only by releasing features and seeing what they do. -- 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] my last attempt at sanity with namespaces
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 +1 on #3 -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Re: 'Sanity' tally to date
In my opinion namespaces should be in 6 not 5.3 but ignoring that:
+1 for Issue 1 option 1
+1 for Issue 2
2008/10/16 Nathan Rixham [EMAIL PROTECTED]
Steph Fox wrote:
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
you can add me down for a +1 on the solution to Issue B as well
- makes logical sense
--
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
If I understand correctly I vote. +1 for Issue 1 option 1 +1 for Issue 2 On Wed, Oct 15, 2008 at 9:35 PM, Greg Beaver [EMAIL PROTECTED] 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] my last attempt at sanity with namespaces
Hi! http://wiki.php.net/rfc/namespaceissues My opinion for the proposals: A. I'm ok with use namespace, but it is inferior to the - proposal. While it allows explicit disambiguation, it does not allow to call both in the same file. I'm not sure it's too much of a problem but B. There's a huge problem with this proposal which you seem consistently to ignore despite all my attempts to explain it. Failed autoload on each call is BAD. Very bad. It is not cacheable, it leads to multiple disk accesses and it is absolutely undetectable to the PHP user without the use of special tools. So making all existing code contain this performance bomb unless you rewrite it is very bad. It's better to have this code fail and provide simple script to fix it in automatic fashion. The fix you propose - writing use's - is not enough because as you noted later inertia would make users not to use this code and thus have huge performance hit - which most of them even wouldn't know where it came from. I talked to many OO developers and most of them were OK with using :: on internal classes when using namespaces. -- 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] 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
Re: [PHP-DEV] Re: my last attempt at sanity with namespaces
Hi! +1 and of course make the resolution as greg mentioned on the rfc in the resolving access part (actually that was in stas's original original post and I didn't realize we were still arguing over it ;) NO, it wasn't in my proposal - my proposal was entirely different. My proposal does not include autoload performance bomb. -- 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] 'Sanity' tally to date
On 16 Oct 2008, at 16:14, Steph Fox wrote: Please can those people who didn't already express a clear and relevant opinion, express it now? Issue A: #1. Issue B: Yes. -- 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 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. -- 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] my last attempt at sanity with namespaces
On 16.10.2008, at 17:37, Stanislav Malyshev wrote: B. There's a huge problem with this proposal which you seem consistently to ignore despite all my attempts to explain it. Failed autoload on each call is BAD. Very bad. It is not cacheable, it leads to multiple disk accesses and it is absolutely undetectable to the PHP user without the use of special tools. So making all existing code contain this performance bomb unless you rewrite it is very bad. It's better to have this code fail and provide simple script to fix it in automatic fashion. The fix you propose - writing use's - is not enough because as you noted later inertia would make users not to use this code and thus have huge performance hit - which most of them even wouldn't know where it came from. first up i am a bit irritated by the use of the term internal class, i guess you both mean to say class in the global namespaces? I talked to many OO developers and most of them were OK with using :: on internal classes when using namespaces. second, we are not talking an issue where prepending with a double colon solves the issue, since example was about a case where i want to autoload a file that defines a class in the current namespace and not fall back to the global namespace. however your performance concerns are quite valid. imho the thing is, that the person who is developing a namespace that is autoloadable knows this (or should know this), as a result its his obligation to either trigger the autoload via a use statement or by prepending the current namespace name to the class name. imho the main use for namespaced code will be libraries and not application level code (with the exception that some people have mentioned that they might want to stick their templates in namespaces), so i think this burden is legit, since most of us spend their time writing application level code and not library code (sorry full time ezc/zf developers). so imho the solution is none of the above. the solution is that however wants to make his namespaced code to be autoloadable must make sure he explicitly triggeres the autoloading. regards, Lukas Kahwe Smith [EMAIL PROTECTED] -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] 'Sanity' tally to date
On 16 October 2008, at 16:14:34, Steph Fox wrote: Janusz Lewandowski #4 Yes My alternative choice for A is #3. -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] 'Sanity' tally to date
On 16.10.2008, at 16:14, Steph Fox wrote:
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'.
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. 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).
regards,
Lukas Kahwe Smith
[EMAIL PROTECTED]
--
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
Lukas Kahwe Smith wrote: On 16.10.2008, at 17:37, Stanislav Malyshev wrote: B. There's a huge problem with this proposal which you seem consistently to ignore despite all my attempts to explain it. Failed autoload on each call is BAD. Very bad. It is not cacheable, it leads to multiple disk accesses and it is absolutely undetectable to the PHP user without the use of special tools. So making all existing code contain this performance bomb unless you rewrite it is very bad. It's better to have this code fail and provide simple script to fix it in automatic fashion. The fix you propose - writing use's - is not enough because as you noted later inertia would make users not to use this code and thus have huge performance hit - which most of them even wouldn't know where it came from. first up i am a bit irritated by the use of the term internal class, i guess you both mean to say class in the global namespaces? no, we are talking about classes built into PHP such as Exception or ArrayObject, not userspace classes without namespace. Greg -- 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
On 16.10.2008, at 18:59, Greg Beaver wrote: Lukas Kahwe Smith wrote: On 16.10.2008, at 17:37, Stanislav Malyshev wrote: B. There's a huge problem with this proposal which you seem consistently to ignore despite all my attempts to explain it. Failed autoload on each call is BAD. Very bad. It is not cacheable, it leads to multiple disk accesses and it is absolutely undetectable to the PHP user without the use of special tools. So making all existing code contain this performance bomb unless you rewrite it is very bad. It's better to have this code fail and provide simple script to fix it in automatic fashion. The fix you propose - writing use's - is not enough because as you noted later inertia would make users not to use this code and thus have huge performance hit - which most of them even wouldn't know where it came from. first up i am a bit irritated by the use of the term internal class, i guess you both mean to say class in the global namespaces? no, we are talking about classes built into PHP such as Exception or ArrayObject, not userspace classes without namespace. why are they different? also since they apparently are different, how does this all work when its not about an internal class, but a global useland class? as in what if in your example it would not be the Exception class, but a class called FooBar, which is defined in the global namespace in some userland code? regards, Lukas Kahwe Smith [EMAIL PROTECTED] -- 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'sproposal doesn't work
Stanislav Malyshev wrote: Hi! 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! So? We rewrote pretty much every other part of PHP - engine, object model, filesystem, etc. - and nobody died. Suddently with this particular feature there's tremendous fear of commitment. But we aren't going anywhere by sitting and talking about what if. We get anywhere only by releasing features and seeing what they do. My point is that for this code: ?php Classname::Method(); ? The proposal does not solve the name conflict. If no one rewrites their code to use Classname-Method(), then no one will be protected from the ambiguity. I am thinking of the case where a user adds a new feature to their existing code that uses a 3rd-party library with namespaced functions that accidentally conflict with the user's classes without their knowledge. As third-party libraries become easier to distribute (which both phar and pyrus plan to do), this will become more of an issue. Our experience with other changes forced upon existing code has shown that user inertia is high, and we can't expect to fix things simply by asking the users to rewrite their code unless PHP tells them to with E_STRICT or other warnings. Should I add this to the explanation or is it clear enough? Greg -- 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! first up i am a bit irritated by the use of the term internal class, i guess you both mean to say class in the global namespaces? I can't tell what Greg meant for him, but for me the problem exists regardless of the class being internal or not. imho the thing is, that the person who is developing a namespace that is autoloadable knows this (or should know this), as a result its his obligation to either trigger the autoload via a use statement or by prepending the current namespace name to the class name. Namespaces aren't autoloadable, classes are. But what I see happening is that people would start converting excisting code, and since they are human they will inevitable forget or miss class here and there. And it would work, and pass all tests, and look fine and dandy on the outside - but under the water it would contain the performance bomb of non-cacheable exhaustive autoload search. It is a big disservice for our users to put them into this situation where you need to be an expert to even notice where the problem is - especially that we *already* know the problem exists and we *know* how to fix it. Why not just fix it? imho the main use for namespaced code will be libraries and not application level code (with the exception that some people have mentioned that they might want to stick their templates in namespaces), so i think this burden is legit, since most of us spend their time writing application level code and not library code (sorry full time ezc/zf developers). That doesn't matter - applications would contain private libraries as part of the function, which would contain namespaces. Look at big application like Magento - there's definitely potential for huge use of namespaces inside the application. Namespaces aren't by no means limited to off-the-shelf libraries - I see much use of them precisely in the custom code in big projects. But the more important issue here is that we KNOW there's a problem. Why should we look for reasons to diminish its importance when we have a fix for it, which most of the target audience would accept? so imho the solution is none of the above. the solution is that however wants to make his namespaced code to be autoloadable must make sure he explicitly triggeres the autoloading. There's no such thing as autoloadable or not autoloadable code in PHP now. So I'm afraid I miss what you trying to tell - do you say we should stay with what we have now? Or do something else? -- 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] my last attempt at sanity with namespaces
Lukas Kahwe Smith wrote:
On 16.10.2008, at 18:59, Greg Beaver wrote:
Lukas Kahwe Smith wrote:
On 16.10.2008, at 17:37, Stanislav Malyshev wrote:
B. There's a huge problem with this proposal which you seem
consistently to ignore despite all my attempts to explain it. Failed
autoload on each call is BAD. Very bad. It is not cacheable, it leads
to multiple disk accesses and it is absolutely undetectable to the
PHP user without the use of special tools. So making all existing
code contain this performance bomb unless you rewrite it is very bad.
It's better to have this code fail and provide simple script to fix
it in automatic fashion. The fix you propose - writing use's - is not
enough because as you noted later inertia would make users not to use
this code and thus have huge performance hit - which most of them
even wouldn't know where it came from.
first up i am a bit irritated by the use of the term internal class,
i guess you both mean to say class in the global namespaces?
no, we are talking about classes built into PHP such as Exception or
ArrayObject, not userspace classes without namespace.
why are they different?
also since they apparently are different, how does this all work when
its not about an internal class, but a global useland class? as in
what if in your example it would not be the Exception class, but a
class called FooBar, which is defined in the global namespace in some
userland code?
That's a great question, and I didn't realize it was a confusion, so
I'll try to answer it clearly.
The purpose behind resolution rules in namespaces is to make it easiest
to access
1) stuff with the same namespace prefix
2) internal functions, constants, and classes built into PHP
So, there is no chance for conflict with this code:
foo.php:
?php
function __autoload($class){include $class . '.php';}
class Foobar{}
?
?php
namespace bar;
include 'foo.php';
$a = new Foobar; // this tries to autoload bar::Foobar if internal class
Foobar does not exist
?
To force resolution to userspace Foobar, all you need add is:
?php
use ::Foobar;
?
Greg
--
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
Stanislav Malyshev wrote: Namespaces aren't autoloadable, classes are. But what I see happening is that people would start converting excisting code, and since they are human they will inevitable forget or miss class here and there. And it would work, and pass all tests, and look fine and dandy on the outside - but under the water it would contain the performance bomb of non-cacheable exhaustive autoload search. It is a big disservice for our users to put them into this situation where you need to be an expert to even notice where the problem is - especially that we *already* know the problem exists and we *know* how to fix it. Why not just fix it? Hi Stas, Was your proposal to do this for name resolution: ?php namespace blah; $a = new Exception; 1) if for blah::Exception exists, use it 2) try to autoload blah::Exception 3) fail instead of having the internal resolution? I would support this, and am sorry if I mischaracterized your proposal in solution to issue #2. I really thought I was proposing the thing you all worked out at ZendCon, it was a simple misunderstanding on my part. Greg -- 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
great work - just one little note that may/may not help.. 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.. I honestly think that if the option was rewritten as let's say: one::step:two() one:step::two() (or indeed any other double-char operator) then it would make a lot more sense, visually, logically and perhaps be the winner here.. Regards and thanks for the massive amount of patience :-) -- 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
Since this got cut without am answer I'll repeat it since *I* would still like to know the answer! Lester Caine wrote: So 'USE' ? I'm I understanding things right on this one that one would 'define' the namespace in one sort of header file, and then add the use namespace to those files that build on the basic definition? I'm looking in particular here at a library like ADOdb, where 'adodb.inc.php' has a number of global functions which are then used by the various drivers. So 'adodb.inc.php' would define 'ADOdb' as a namespace and each driver would 'use namespace ADOdb' This seems a good example to work with and is the reason that simply dropping functions rang alarm bells with me. In fact it was the Date stuff from ADOdb that caused so much trouble with 'Date' in earlier releases so it seems appropriate to investigate how namespace would work with it? There are obviously other ways the problem could be solved, but a simply wrapper is the right approach initially? Or am I barking up the wrong tree? If #3 is intended to work this way then it gets my vote. Trying to apply namespace something substantial and understanding where the code needs to be changed to work seems more logical than some of the academic examples. -- Lester Caine - G8HFL - Contact - http://lsces.co.uk/lsces/wiki/?page=contact L.S.Caine Electronic Services - http://lsces.co.uk EnquirySolve - http://enquirysolve.com/ Model Engineers Digital Workshop - http://medw.co.uk// Firebird - http://www.firebirdsql.org/index.php -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] Re: my last attempt at sanity with namespaces
Hello all, Sorry to post here being an outsider. I didn't post because I know nothing about the internals, really. However after some incomplete thought I have a not very thorough suggestion about the ambiguity issue mentioned in the RFC wiki. I would like to ask if this is possible. Let me quote the challenge here: quote // is this class one::step or namespace one::step? one::step::two(); /quote Is is possible that the engine first looks for classes, then namespaces? So one::step::two(); should always result in: Namespace: one Class: step Static Method: two Now the ambiguity is resolved. If we want to really mean namespace one::step and function two(), one must explicitly write the following: (one::step)::two(); Yes, parenthesis, just like when we want to write (1 + 2) * 3. So my question is: can parenthesis play a part in namespace resolving? There can be problem, e.g. I don't know if the engine can distinguish it from typecasting without many efforts. But anyway I hope this doesn't sound too stupid :). T 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] namespaces sanity: addition to RFC explaining why Stas'sproposal doesn't work
Hi! My point is that for this code: ?php Classname::Method(); ? The proposal does not solve the name conflict. If no one rewrites their Right, it does not. So doesn't yours - you need to modify the code in both cases. code to use Classname-Method(), then no one will be protected from the ambiguity. I am thinking of the case where a user adds a new feature to If nobody changes existing code then there's no ambiguity by definition. If the code is changed, then of course one needs to change it in the right way, there's no way around that - you always can think of some wrong code that works, well, wrong. their existing code that uses a 3rd-party library with namespaced functions that accidentally conflict with the user's classes without If you use 3rd party library that has same namespace as yours somebody had screwed up here - either you used namespace that doesn't belong to you or they used namespace that doesn't belong to them. In both cases the fix is un-screw-up the naming. their knowledge. As third-party libraries become easier to distribute (which both phar and pyrus plan to do), this will become more of an issue. Nobody should put their classes in PEAR namespace unless they are part of PEAR library, thus this scenario - when somebody outside of PEAR has conflict with PEAR functions/classes - is imaginary. -- 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] my last attempt at sanity with namespaces
Hi! Was your proposal to do this for name resolution: ?php namespace blah; $a = new Exception; 1) if for blah::Exception exists, use it 2) try to autoload blah::Exception 3) fail Yes. -- 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] 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
[PHP-DEV] Re: my last attempt at sanity with namespaces
Edmund Tam wrote: (one::step)::two(); Yes, parenthesis, just like when we want to write (1 + 2) * 3. So my question is: can parenthesis play a part in namespace resolving? see this is the problem and where the solution should be (imo) mynamespace::anotherspace::somespace makes sense class::method() makes sense it's when you join the two together that the ambiguity comes in so the solution should be some way of visually and technically defining where a namespace-path ends only solutions are: parenthesis around the namespace-path: (mynamespace::anotherspace::somespace)class::method() or a separator at the end of the namespace-path (greg's option 2) mynamespace::anotherspace::somespace:::class::method() [:::] mynamespace::anotherspace::somespace:class::method() [:] mynamespace::anotherspace::somespace class::method() [ (space)] mynamespace::anotherspace::somespace..class::method() [..] anything clear and unambiguous visually! -- 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
Steph Fox wrote: 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. agreed; one last little push can't hurt too much though can it? (beats backtracking to ns vs packages or something ridiculous like that weg) -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] __getStatic
On 10.10.2008, at 22:58, Stanislav Malyshev wrote: Hi! I've updated the patch and added some tests with it. http://sitten-polizei.de/php/getstatic.diff Looked at the patch. There's some things I noticed there: 1. _getstatic-common.fn_flags |= ~ZEND_ACC_ALLOW_STATIC; What was the idea here? Maybe ~ is not intended? 2. Do we really need ZEND_ASSIGN_CLASS opcode, can't we reuse ASSIGN_OBJ with flag, as we do for fetches? 3. In zend_std_set_static_property, I'm not sure we need to do zend_update_class_constants there. We won't be using any values from it. 4. In zend_std_set_static_property, why you create new property_info two times when property does not exist? 5. In zend_std_set_static_property, old value of the property is not destroyed. Also, I'm not sure separation is handled there correctly - previous value may be shared between variables, and just replacing it would affect all shared variables. You may see how property handler does assignments. Alternatively, in the absence of the setter, you may just use the existing assignment handler, just fetching the zval** as before and passing it to zend_assign_to_variable. This would probably be better - less stuff to do. 6. What would happen with foo::$bar += 1? I don't see assign-ops handled anywhere in the patch. 7. Does zend_std_get_static_property handle the case of return by- ref like property one does? hmm .. i also emailed Timm a few weeks ago and got no reaction. the question now is .. does someone else care enough to work through the issues Stas has noted to get things in shape to be committed? regards, Lukas Kahwe Smith [EMAIL PROTECTED] -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] type hint semantics; disagreement between phpt and manual
On 07.10.2008, at 21:59, Nathan Nobbe wrote:
hi all,
we are encountering an error in our code due to type hint
semantics. php is
allowing NULL values through a type hint for a class, however, if i
read the
manual, NULL, should only be allowed, if and only if, null is given
as the
default value for the formal parameter that is type-hinted.
PHP 5 introduces Type Hinting. Functions are now able to force
parameters
to be objects (by specifying the name of the class in the function
prototype) or arrays (since PHP 5.1). However, if
NULLhttp://ch2.php.net/manual/en/language.types.null.phpis used as
the default parameter value, it will be allowed as an argument
for any later call.
now, i have checked our code; there is no NULL default value, and
there are
no parents which mark a default value of NULL. so why would they be
creeping through then.. ?
well, i glanced at the phpt test, and its quite clear the tests are
allowing
NULL,
Zend/tests/errmsg_013.phpt:errmsg: default value for parameters with
array
type hint can only be an array or NULL
Zend/tests/errmsg_013.phpt:Fatal error: Default value for parameters
with
array type hint can only be an array or NULL in %s on line %d
looking at the function prototype in this test, NULL is not
specefied as the
default value, so i dont think NULL should be allowed here anyway..
--TEST--
errmsg: default value for parameters with array type hint can only
be an
array or NULL
--FILE--
?php
class test {
function foo(array $a = s) {
}
}
echo Done\n;
?
--EXPECTF--
Fatal error: Default value for parameters with array type hint can
only be
an array or NULL in %s on line %d
this taken from 5.2.6.RC3 source. it seems to me, either the source
or the
manual is wrong, but which one is it ?? personally, i would prefer
it be
the former in this case ;)
FWIW, we are currently running php5.2.2 on centos5, but im pretty
sure an
upgrade to 5.2.6 will not change the semantics, since the phpt tests
were
the same in both the 5.2.2 5.2.6 source.
please file a bug report with a reproduceble test case that
illustrates the conflicting behavior with the manual.
regards,
Lukas Kahwe Smith
[EMAIL PROTECTED]
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] 'Sanity' tally to date
2008/10/16 Steph Fox [EMAIL PROTECTED]: 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. Hi, As far as I'm concerned, my preference goes to: 2. use a different separator between namespace name and element [with a plea for not using :::] Yes, please change the resolution order to 1. if blah::Exception exists, use it 2. try to autoload blah::Exception 3. if internal class Exception exists, use it With that said, while I truly appreciate my opinion being taken under consideration, I also hope that decisions won't be made or pushed based on poll numbers alone (even though I don't remember any such occurence in the list's past) and that greater weight will be given to those who are already using namespaces in big, open, projects, such as the Typo3 guys. It would be bad if an anonymous crowd speculating on issues they have yet to encounter could overweight the bunch of guys who have actually been using namespaces for month. I mean, if an anonymous crowd can get a MTV award to Rick Astley, they can get anything voted as namespace operator! :) Anyway, thanks for the tally, it gives a better overview of people's opinions. JD -- 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
I have been watching the namespace conversations for months and I can not get my head around this fixation on a new separator. Other languages get by without separate resolution syntax, why not solve these ambiguities through rules of precedence like everyone else? Throw possible ambiguity warnings if we don't mind looking ahead for the performance hit and give users the ability to alias their namespaces with AS when conflicts do occur they can be easily fixed. using BadNamedLib as BetterNamedLib; using BadNamedLib; Resolve using :: as a separator, have some simple rules and document them, first namespace's loaded classes takes precedence over the last. Constansts are more important then classes, or vice versa. Document the determined precedence. Giving users a tool to alias namespaces solves a lot of the namespace resolution issues. Just my thoughts, -Chris
Re: [PHP-DEV] json_encode ignores protected/private class members
Hi, So I guess the conclusion is: Create a feature request ticket, take the information from this thread and put it into the ticket .. and ideally write a patch yourself or motivate someone else .. regards, Lukas -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] __getStatic
Hi! hmm .. i also emailed Timm a few weeks ago and got no reaction. the question now is .. does someone else care enough to work through the issues Stas has noted to get things in shape to be committed? Well, this thing is trickier that it appears initially. It can be done, of course, but it requires serious attention to the details (e.g. cases like +=, doing refcounts/separation correctly on assignment, etc.). This patch is definitely not ready, so I'd wait with it unless we get really good one very-very soon. -- 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
[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] namespaces sanity: addition to RFC explaining why Stas'sproposal doesn't work
Stanislav Malyshev wrote: Hi! My point is that for this code: ?php Classname::Method(); ? The proposal does not solve the name conflict. If no one rewrites their Right, it does not. So doesn't yours - you need to modify the code in both cases. the solution I proposed emits an E_WARNING on the conflict. Greg -- 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'sproposal doesn't work
Hi! ?php Classname::Method(); ? The proposal does not solve the name conflict. If no one rewrites their Right, it does not. So doesn't yours - you need to modify the code in both cases. the solution I proposed emits an E_WARNING on the conflict. You proposed a number of solutions, apparently. That's why I asked to restrict the number of variants - even people who watch the discussion can't be sure what we are talking about now. Do you propose to _always_ throw E_WARNING even if there was no actual conflict? Then I am against it - in 99.9% of the code this warning would be useless and would only annoy people. If you propose to throw warning only if actual conflict exists - the question stays how do you know it exists. -- 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] my last attempt at sanity with namespaces
Stanislav Malyshev wrote: Hi! http://wiki.php.net/rfc/namespaceissues My opinion for the proposals: A. I'm ok with use namespace, but it is inferior to the - proposal. While it allows explicit disambiguation, it does not allow to call both in the same file. I'm not sure it's too much of a problem but Hi, It does not allow calling both with the same import name, but it does allow: ?php namespace blah; include 'thing1.php'; include 'thing2.php'; use class ::foo; use namespace ::foo as another; foo::blah(); // static method another::blah(); // namespace function ? Greg -- 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
Chris Stockton wrote: I have been watching the namespace conversations for months and I can not get my head around this fixation on a new separator. Other languages get by without separate resolution syntax, why not solve these ambiguities through rules of precedence like everyone else? Throw possible ambiguity warnings if we don't mind looking ahead for the performance hit and give users the ability to alias their namespaces with AS when conflicts do occur they can be easily fixed. using BadNamedLib as BetterNamedLib; using BadNamedLib; Resolve using :: as a separator, have some simple rules and document them, first namespace's loaded classes takes precedence over the last. Constansts are more important then classes, or vice versa. Document the determined precedence. Giving users a tool to alias namespaces solves a lot of the namespace resolution issues. Hi Chris, This is actually option #3 on the list of solutions at http://wiki.php.net/rfc/namespaceissues Steph: can you catalog this as a vote for it? Greg -- 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! It does not allow calling both with the same import name, but it does allow: ?php namespace blah; include 'thing1.php'; include 'thing2.php'; use class ::foo; use namespace ::foo as another; foo::blah(); // static method another::blah(); // namespace function ? 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. -- 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] my last attempt at sanity with namespaces
I have a question about 3. Where in a script can you use the use
statement? Could it be used inside conditionals? For example,
if ($testing) {
use class testing::PDO;
} else {
use class ::PDO;
}
If that's the case, could we have a word from an opcode cache guru
about how nice it would play with them?
Also, could you please give us a couple of examples of code that would
trigger the E_WARNING mentionned in case of ambiguity and how that
ambiguity would be resolved? Thanks in advance.
JD
--
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!
if ($testing) {
use class testing::PDO;
} else {
use class ::PDO;
}
No, I don't think this would work since use is compile-time statement.
--
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] my last attempt at sanity with namespaces
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? 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. Though I don't object to #3 at all either, so indifferent! 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. Scott -- 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
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
Stanislav Malyshev wrote:
Hi!
if ($testing) {
use class testing::PDO;
} else {
use class ::PDO;
}
No, I don't think this would work since use is compile-time statement.
use is also a top_statement, which means it cannot be inside {} at all.
Greg
--
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
On 17 Oct 2008, at 01:19, Steph Fox wrote: 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? #1 and then #3. 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. Scott -- 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
Hi! 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. 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. 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. 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. -- 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] 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
Hi! 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'. 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? 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 -- 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] my last attempt at sanity with namespaces
Steph Fox wrote: #1 and then #3. Thanks :) - Steph that is so wrong, you know 3 was better - you're not in my club :'( -- 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
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
Steph Fox wrote: 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 twas directed at scott; an i typo'd n meant 3, and was misplaced humour - tis 2am here and I really shouldn't be on any lists or anywhere of even vague importance - apologies! -- 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! Why do you assume all third-party software is going to be ZF? Or that Are you familiar with the concept of example? 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? Useful lib would have its own namespace and you would have your own. -- 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] 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
[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
Stanislav Malyshev wrote: Hi! 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. 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. 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. 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. Hi Stas, This is not what is proposed. The E_WARNING is *only* on a name conflict. Please re-read or try the patch: http://pear.php.net/~greg/resolve_conflict.patch.txt Greg -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] Re: Sanity tally #2
Steph Fox wrote: 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 just wondering if there are any cut of dates for the tally dates / rounds etc? -- 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] Vote from a Mere User
I'm just a mere user but here's how I would vote: Issue 1: Choice #4 (with an alternate choice for #3). My eye sight is bad enough without having to distinguish between :: and :::. Issue 2: Vote yes for Greg. It just makes sense to me. -Tim Timothy Boronczyk, ZCE [EMAIL PROTECTED]
Re: [PHP-DEV] Vote from a Mere User
I'm another mere user, but here are my votes Issue 1: Choice #3 Issue 2: Agree with Greg. Josh Heidenreich ZCE -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Sanity tally #2
On Thu, Oct 16, 2008 at 3:33 PM, Steph Fox [EMAIL PROTECTED] wrote: 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. Sorry for coming late to the party. Among other things, I've *finally* been swapping my subscription address from my @gmail.com to my @php.net address before Derick finally loses it and attacks me in a dark parking lot. ;-P I'm strongly enough pro-three that I'd vote #3 twice, so feel free to put me down for three points on #3. Sounds like a campaign slogan: Go Three For Three. As to the second issue, because I don't have an firm, absolute opinion on one side or the other of the issue as it stands now, I'll take the route you and Hannes have both chosen and abstain. -- /Daniel P. Brown More full-root dedicated server packages: Intel 2.4GHz/60GB/512MB/2TB $49.99/mo. Intel 3.06GHz/80GB/1GB/2TB $59.99/mo. Intel 2.4GHz/320/GB/1GB/3TB $74.99/mo. Dedicated servers, VPS, and hosting from $2.50/mo. -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Vote from a Mere User
A mere user here too with some php namespace experience (with current implementation). Issue 1: Choice #4, with a fallback on choice #3 Issue 2: This should be a php.ini option, typically it's going to cause a lot of (useless) calls to __autoload() for some existing code while migrating to a namespace-oriented code. This is also going to break things for some people who use require() in __autoload(). Mark Le vendredi 17 octobre 2008 à 13:18 +1030, Josh a écrit : I'm another mere user, but here are my votes Issue 1: Choice #3 Issue 2: Agree with Greg. Josh Heidenreich ZCE -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Vote from a Mere User
I am a mere user you can consider as well. I usually just read internals. I wanted to add input into the namespace issue. Using a difference of ::: or :: for separators is really confusing. I could slip up in programing by missing a single : and then have to go back to debug and it would be very easy to miss this. I don't think option 1 and 2 would work here unless we used a different separator. At this time I do not have a suggestion for a separator. My eye sight isn't all that perfect, in fact typing them in this message, I had to double check I typed them correctly. Although this solves it, this isn't very user friendly. Option 3 sounds nice, but since reading a previous internals note, you can use these in a if/else statement. Which I would prefer almost for those weird cases where you need to only include a class if it was for something specific such as a database, operating system or php version compatibility. The issue I see with number 4 is lets say I have a forum and a cms. If I wanted to bridge those two and they had this conflict, I wouldn't be able to bridge these two very easily now. Conflicting code while working with apis and other open source/free scripts is my only concern with this. That said, I think option 3 would work the best here with option 1 as another choice if we used a different separator that was more unique. Jeremy On Oct 16, 2008, at 9:31 PM, Mark wrote: A mere user here too with some php namespace experience (with current implementation). Issue 1: Choice #4, with a fallback on choice #3 Issue 2: This should be a php.ini option, typically it's going to cause a lot of (useless) calls to __autoload() for some existing code while migrating to a namespace-oriented code. This is also going to break things for some people who use require() in __autoload(). Mark Le vendredi 17 octobre 2008 à 13:18 +1030, Josh a écrit : I'm another mere user, but here are my votes Issue 1: Choice #3 Issue 2: Agree with Greg. Josh Heidenreich ZCE -- 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
