Re: [PHP-DEV] array_key_exists BC break
On 21.11.2008, at 09:54, Stanislav Malyshev wrote: bigger release (presumably PHP 6.0) and come up with a set of interfaces for objects that allow them to more sensibly work with functions. We already have set of interfaces. They aren't just used consistently. And that's a bug. We shouldn't let BC to prevent us from fixing bugs. Especially BC with things that were never documented to work at the first place and are working in half of functions and don't work in others without any logical order. I am just worried that we do not have enough time to really think this through all the way. So in the end we might end up having to break BC once more in PHP 6.0. Also its not like we are fixing these bugs because users were submitting bug tickets about this (or have they?). 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] CVS Account Request: magicaltux
On 16.11.2008, at 11:40, Mark Karpeles wrote: As most my [PATCH] mails sent to the internals mailing list were ignored (as of today, at least), I'm requesting an access to the PHP CVS, fully aware of what this means. My contributions (ordered by priority) would include: - The WDDX extension (http://bugs.php.net/46496) My fix for WDDX would allow closing the following forever-waiting bugs: http://bugs.php.net/45037 http://bugs.php.net/45314 I also intend later (and after some discussions, if anyone has any interest in WDDX) to add a feature to WDDX to provide the ability to stream a packet (create a packet ressource while providing a stream descriptor, send the XML code for the variables when added, then close the packet with an end of packet instruction). Providing the reverse process would also have to be done at the same time, using event-based xml parsing. This would allow memory-efficient creation of large packets. Andrei is the maintainer for the WDDX extension. Could you give Mark some feedback here? 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] quick polls for 5.3
Hello All,
First up thanks for this every efficient thread!
Really makes the life for Johannes and myself a lot easier when we can
so easily get an overview of the opinions on internals.
After having discussed the results, we want to publish our
conclusions ..
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 Lukas
+1 David C.
+1 Hannes
+1 Matt Wilson
+1 Greg
+1 Derick
+1 Elizabeth
+1 Lars
+1 Stas
+1 Ilia
+1 Steph
+1 Scott
+1 Kalle
+1 David S.P.
+1 Rob
+1 Pierre
+1 Arnaud Le Blanc
+1 Larry Garfield
+0 Lester Caine
+0 Konstantin Leboev
+1 Jani
+1 Jonathan Bond-Caron
+1 George Antoniadis
+0 Felipe
+1 Moriyoshi
= keep ext/hash enabled by default
II) remove ext/mhash
+1 Lukas
+1 David
+1 Hannes
+1 Matt Wilson
+0 Greg
+1 Derick
+1 Elizabeth
+1 Lars (Probably hack ZEND_FUNCTION(extension_loaded) to return true
when mhash is passed and throw a deprecation warning. Is pretty easy
but ugly. What would our ZE guys suggest to accomplish something like
that?)
+1 Stas (Can't we make mhash stub extension with dependency on hash
so only thing you get when you load it is that extension_loaded is OK
and no BC break? Dependency would ensure the functions are there, and
we get the bets of both worlds.)
+1 Ilia
-1 Steph BC concerns. Can't we just deprecate it in 5.3 and remove in
6.0?
+1 Scott
+0 Kalle
+1 David S.P.
+1 Rob
+1 Pierre
+0 Arnaud Le Blanc
-1 Larry Garfield better to E_DEPRECATE for a version first then remove.
+0 Lester Caine
+0 Konstantin Leboev
+1 Jani
+0 Jonathan Bond-Caron
+1 George Antoniadis
+1 Felipe
+1 Moriyoshi
= remove ext/mhash (someone may propose some stub/magic solution for
extension_loaded('mhash'))
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 Lukas
+1 David
+1 Hannes
+1 Matt Wilson
+1 Greg
-1 Derick
+1 Elizabeth
+1 Lars
-0.5 Stas I'd say not yet, but don't care too much.
+1 Ilia
+1 Steph
+1 Scott
+0 Kalle
+1 David S.P.
+1 Rob
+1 Pierre
+1 Arnaud Le Blanc (and allow the --without-ereg switch)
+1 Larry Garfield
+1 Lester Caine
+1 Konstantin Leboev
+1 Jani
+1 Jonathan Bond-Caron
+1 George Antoniadis
+1 Felipe
+1 Moriyoshi
= deprecate ext/ereg and remove in PHP 6
3) resource constants (choose one)
+0 Stas
+0 Larry Garfield
+0 Konstantin Leboev
a) Should we deprecate constant resources (mostly used to emulate
STDIN and friends)
+1 Scott
+1 Arnaud Le Blanc
+1 George Antoniadis
+1 Moriyoshi
b) Should we instead just throw an E_STRICT
+1 Kalle
c) Document as is
+1 Lukas
+1 David
+1 Hannes
+1 Matt Wilson
+1 Greg
+1 Derick
+1 Elizabeth
+1 Lars
+1 Ilia
+1 Steph
+1 David S.P.
+1 Rob
+1 Pierre
+1 Lester Caine
+1 Jani
+1 Jonathan Bond-Caron
+1 Felipe
= document as is
4) keep ext/phar enabled by default in 5.3?
+1 Lukas
+1 David
-1 Hannes
-1 Matt Wilson
+1 Greg
+1 Derick
+1 Elizabeth
+1 Lars
+1 Stas
+0 Ilia
+1 Steph
+0 Scott
+1 Kalle
+1 David S.P.
+0 Rob
+0 Pierre
+1 Arnaud Le Blanc
+0 Larry Garfield
-1 Lester Caine
+0 Konstantin Leboev
-1 Jani
+1 Jonathan Bond-Caron
+1 George Antoniadis
+1 Felipe
+1 Moriyoshi
= keep ext/phar enabled
5) keep ext/sqlite3 enabled by default in 5.3?
+1 Lukas
+1 David
+0 Hannes
-1 Matt Wilson
+1 Greg
+1 Derick
+1 Elizabeth
+1 Lars
+1 Stas
+1 Ilia
+1 Steph
+1 Scott
+0 Kalle
+1 David S.P.
+1 Rob
+1 Pierre
+1 Arnaud Le Blanc
+1 Larry Garfield
-1 Lester Caine
+1 Konstantin Leboev
+1 Jani
+0 Jonathan Bond-Caron
-1 George Antoniadis
+1 Felipe
+1 Moriyoshi
= keep ext/sqlite3 enabled
6) enable mysqlnd by default in 5.3? (answer both)
I) enable mysqlnd by default
-1 Lukas
-1 David
-0 Hannes
-1 Matt Wilson
+0 Greg
-1 Derick
+0 Elizabeth
+1 Lars
+0 Stas
-1 Ilia
+1 Steph
+1 Scott
+1 Kalle
+0 David S.P.
-1 Rob
+1 Pierre
+0 Arnaud Le Blanc
+1 Larry Garfield
-1 Lester Caine Many people do not use MySQL so it should not be
enabled by default. This is even more important if it gets compiled in
by default in windows builds.
+0 Konstantin Leboev
+1 Jani
-1 Jonathan Bond-Caron would favor mysql by including client in
default installation (Clarification by Johannes: mysqlnd is a PHP-
specific replacement for the MySQL Client Library (libmysql) so adding
mysqlnd as default means including client in default installation.
By using mysqlnd there are no external dependencies left.)
+1 George Antoniadis
+1 Felipe
-1 Moriyoshi
= do not enable by default since there is not enough support to add
something (assumption when in doubt do not add)
II) also enable ext/mysql, mysqli und pdo_mysql by default since there
will be no external dependencies in this case
-1 Lukas
+1 David
-0 Hannes
-1 Matt Wilson
+0 Greg
-1 Derick
+0 Elizabeth
+1 Lars
+0 Stas
-1 Ilia
-1 Steph if it was just one
Re: [PHP-DEV] array_key_exists BC break
On 13.11.2008, at 19:19, Stanislav Malyshev wrote: Hi! Can anyone write up a summary of the situation and the options we have? Sure. A number of array functions in 5.2 accept arrays, but use HASH_OF to extract array value, which means they automatically accept objects if the object has working get_properties handler. In 5.3, such function use new API with 'a' parameter, which accepts only arrays proper. The proposal is to have some new parameter - say 'a%' - which would call HASH_OF on objects where it makes sense. The definition of makes sense is not clear yet, since, for example, sort() on some objects may make sense - if the object's get_properties returns real storage - or may not, if that handler returns the mere copy of the real data. We might use some interface as a marker - like ArrayAccess - though I'm not sure if it will work in all circumstances. So what if we for now stick with the BC fix? However maybe for PHP 6.0 we should make a real effort to figure out how objects are supposed to be handled in our PHP type juggeling world. 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] array_key_exists BC break
On 15.11.2008, at 20:17, Stanislav Malyshev wrote: Hi! So what if we for now stick with the BC fix? However maybe for PHP 6.0 we should make a real effort to figure out how objects are supposed to be handled in our PHP type juggeling world. Depends what you mean by BC fix. If you mean just rolling these functions back to using zval** and converting manually, I'm not sure it's the best idea... It'd be better for parameter parsing API to be able to handle such things. no i meant .. going along with the fix you suggested. and for those places where you said we its not clear how things should behave, we should just go by how things behaved in 5.2. 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] quick polls for 5.3
Hi, Thank you all for participating and raising any issues/concerns in a concise manner. I will tally up the votes sometime over the weekend and discuss the results with Johannes. We will then post what decisions we will take based on the votes (though in some cases we might need to hold off a decision until we have discussed the change with the person that maintains the given code). So in the mean time for all who have not voted, please do so now. regards, Lukas -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] array_key_exists BC break
Hi, Can anyone write up a summary of the situation and the options we have? Also cant we some how automate the BC break testing for this (aka scan all functions that accept an array with the old API in 5.2, pass it an ArrayObject instance and see what happens and compare that to 5.3)? regards, Lukas -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] quick polls for 5.3
On 12.11.2008, at 20:14, Lukas Kahwe Smith wrote:
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
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)
c) Document as is
+1
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
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.
-1 (unless enough people step up)
8) MFH mcrypt cleanups in HEAD. either the make sense or they dont,
so either (choose one)
b) MFH to 5.3
+1
regards,
Lukas Kahwe Smith
[EMAIL PROTECTED]
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] quick polls for 5.3
Hi,
here are a few questions that need to be answered ASAP.
If at all possible keep your votes as short as possible. I think all
of the above topics have been discussed quite a lot on the list. So I
hope voters can spare the list needless repetition. Instead if you
think that a topic needs to be discussed, put a short note in your
vote under the given topic. If a number of people also think the topic
needs more discussion, then we can open a new thread dedicated to this
topic later this week.
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
II) remove ext/mhash
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
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
4) keep ext/phar enabled by default in 5.3?
5) keep ext/sqlite3 enabled by default in 5.3?
6) enable mysqlnd by default in 5.3? (answer both)
I) enable mysqlnd by default
II) also enable ext/mysql, mysqli und pdo_mysql by default since there
will be no external dependencies in this case
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.
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
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] alpha3 or forever hold your peace
On 10.11.2008, at 16:06, Pierre Joye wrote: On Mon, Nov 10, 2008 at 3:51 PM, Kalle Sommer Nielsen [EMAIL PROTECTED] wrote: 2008/11/10 Jaroslav Hanslík [EMAIL PROTECTED]: Pierre Joye napsal(a): php_pspell.dll php_snmp.dll snmp and pspell are likely to do not be present in the next release and maybe not in the final release (windows only). The underlying libraries are not portable enough to be used on windows and the versions used before have critical issues (security or crashes). Would it be better to have these extension with some issues (current state) than not to have them at all? As from what I could understand from Pierre, then SNMP is dead on Windows and have been for a very long time (for example it doesn't even compile). I don't remember about pspell, but I think it would make more sense to maybe include something like enchant for spelling though. Enchant works but not using pspell (for the same reason than ext/pspell does not), it works with almost any other spelling system, on all platforms. But that's not the problem neither the solution as enchant is not part of the core. Should we examine if we want to make enchant part of core? I guess you are one of the maintainers, so the prime candidate to tell us if you think its ready .. pspell and netsmnp libraries are not portable and can't be built on windows. We don't feel like releasing packages with critical security issues is a good thing to do. If we do not find a solution by the time of 5.3-final, we can always provide an extra package with these packages but with a (very) strong warning about using them in production environment. I agree. 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] alpha3 or forever hold your peace
On 10.11.2008, at 12:27, Jani Taskinen wrote: 4. Output buffering rewrite MFH: http://bugs.php.net/bug.php?id=42641edit=1 If there is a significant show of hands of people that feel that the code in HEAD is so much easier to maintain, that suddenly they feel more inclined than before to actually care about bugs in output buffering and that they will take care of any BC issues that pop up, Johannes and I might reconsider our decision to not MFH OB. 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] alpha3 or forever hold your peace
On 10.11.2008, at 12:04, Jani Taskinen wrote: Lukas Kahwe Smith wrote: On 10.11.2008, at 11:41, Jani Taskinen wrote: 2. Change ext/ereg to be disabled by default (scheduled to be removed in PHP 6, iirc?) IIRC we are not yet in agreement on the removal. AFAIK its already an extension in PHP6, but I am not sure if we wanted to continue with the You don't follow the CVS a lot, do you? I do, but sometimes I miss a commit. revision 1.2.2.2 date: 2007/10/05 15:00:05; author: jani; state: Exp; lines: +56 -0 MFH:- Moved the old regex functions to own extension: ereg Ok, so its already an extension in PHP 5.3, that does not mean that we have scheduled its removal in PHP 6. Personally I am fine with removing ereg, but then again I have always refrained from using ereg. Its going to be a bit of a pain, but IIRC ereg is not going to play well in our brave new unicode world unless someone does considerable work on ereg .. 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] alpha3 or forever hold your peace
On 10.11.2008, at 11:42, Lester Caine wrote: Pierre Joye wrote: On Mon, Nov 10, 2008 at 9:22 AM, Lester Caine [EMAIL PROTECTED] wrote: Lukas Kahwe Smith wrote: There is still the problems with windows builds of PHP5.3. I've not been able to test anything on new builds since php_interbase is not being compiled. I've not checked what the other dozen or so extensions missing compared with PHP5.2.x are - which is running fine. You know why ibase is missing (see the firebird-php archive as well). And I would like to know which other dozen of extensions are missing. Pierre there are some 44 extensions in the 5.2.x snapshot and only 30 odd in the 5.3.x snapshot - I don't have time to go through every one to check their status. Is that information available somewhere? This is why I asked to check the NEWS file: http://cvs.php.net/viewvc.cgi/php-src/NEWS?view=logpathrev=PHP_5_3 That file should list all intentional changes. If something is changed which is not listed there, it either needs to be listed or fixed. Despite numerous requests as to why the PHP5.2.x code will not compile in 5.3 we seem to be no further forward. The Linux builds do seem to be OK, but my main testbed is the windows stuff. This sentence makes no sense. And we already explained hundred of times what was used in 5.2 is not usable anymore (security, reliability, can't be updated, no src, etc.). Please check the archives if you need a detailed explanation. This only seems to be a problem with windows builds? Although the other branch of this thread has brought up something that I simply was not aware of. It may well have been thoroughly discussed and documented, but if that is the current problem, then we can deal with it - if someone how knows what changes are needed can point us in the right direction ... I just talked to Pierre and he said he is in contact with people from Firebird to get this resolved. 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] alpha3 or forever hold your peace
On 10.11.2008, at 11:41, Jani Taskinen wrote: 2. Change ext/ereg to be disabled by default (scheduled to be removed in PHP 6, iirc?) IIRC we are not yet in agreement on the removal. AFAIK its already an extension in PHP6, but I am not sure if we wanted to continue with the proposal that Andrei (IIRC) made to remove it. If we are doing to remove it we should add E_DEPRECATED. 3. Remove ext/mhash (replaced by ext/hash) So what was the deal here? ext/hash automatically provides the ext/ mhash functions if the extension is not compiled in. So the main reason to keep ext/mhash is just to allow if extension mhash exists .. ? I think this is easy enough for people to fix by replacing this check with an function_exists() check. 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] alpha3 or forever hold your peace
On 10.11.2008, at 12:06, Jani Taskinen wrote: Marcus Boerger wrote: Hello Jani, Monday, November 10, 2008, 11:41:44 AM, you wrote: Lukas Kahwe Smith wrote: Hi, I just wanted to ask everybody to skim over the changes for PHP 5.3 we have in CVS (especially bigger stuff like the addition/ removal of an extension etc.). Please bring up any areas you are concerned about that we might have forgotten. However I am not interested in people bringing up a debate again on namespace syntax or resolution orders (I hope to have the final behavior in CVS ASAP). This is just an attempt to ensure 1. Change ext/phar to be disabled by default We are not disabling thois because Jani doesn't like it. Eh? It wasn't supposed to be enabled everywhere from the beginning! Only for the RC stage. Search the mailing list. It's not about me not liking it or not, it's about general usefulness. No, this is just your selective interpretation of the situation. We decided to enable it by default because if we felt its important to be enabled by default. We left ourselves the option of not enabling it by default (or even removing it) in case we find issues that make it unfit to be enabled by default (or bundled). So far it seems that Greg/Marcus/Steph have been quick to react to any issues that have popped up. Checking the pecl and php bug tracker seems to validate this. 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] question on how to solve major stream filter design flaw
On 11.10.2008, at 19:45, Gregory Beaver wrote: The first part of the bug that I encountered is best described here: http://bugs.php.net/bug.php?id=46026. However, it is a deeper problem than this, as the attempts to cache data is dangerous any time a stream filter is attached to a stream. I should also note that the patch in this bug contains feature additions that would have to wait for PHP 5.3. Can you file a bug report for the second part? Not sure really how to proceed, I guess we need someone to step up to help Wez/Sara with maintaining the streams layer. 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] sybase_connect()
On 09.11.2008, at 13:05, Timm Friebe wrote: Hi, I'd like to add a new optional parameter to sybase_connect() for PHP 5.3. If set to TRUE it will force creation of a new link (and works just like mysql_connect()'s new_link parameter). http://sitten-polizei.de/php/sybase-connect-newlink.diff seems like a good idea to have this and i guess there is no other choice but to stick it at the end of the function parameter list. regards, Lukas Kahwe Smith [EMAIL PROTECTED] -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] alpha3 or forever hold your peace
Hi, I just wanted to ask everybody to skim over the changes for PHP 5.3 we have in CVS (especially bigger stuff like the addition/removal of an extension etc.). Please bring up any areas you are concerned about that we might have forgotten. However I am not interested in people bringing up a debate again on namespace syntax or resolution orders (I hope to have the final behavior in CVS ASAP). This is just an attempt to ensure we do not forget something. regards, Lukas Kahwe Smith [EMAIL PROTECTED] PS: I know this might sound like an invitation for a flame war, it isnt. Please keep replies as technical as possible. Thanks! -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] alpha3
On 07.11.2008, at 09:30, Pierre Joye wrote: hi! On Fri, Nov 7, 2008 at 9:29 AM, Hannes Magnusson [EMAIL PROTECTED] wrote: On Thu, Nov 6, 2008 at 22:00, Lukas Kahwe Smith [EMAIL PROTECTED] wrote: Hi, This are tentatively looking like alpha3 could hit on November 18th. So everybody please try to get whatever you are working on ready to be finished and committed by no later than 13th. So that packaging can happen on a stable tree on the 17th. Is the output buffering MFH still a lost cause? I hope not, it is a must have. To quote myself on this topic: These are all convincing arguments to have done this earlier. But Johannes and I are a bit worried, that this code did not see that much testing since it was checked in to HEAD quite a while ago. And seeing that the backport is mainly cleanup and not bug fixing, we are a bit worried about the risk this backport has (not necessarily in it introducing bugs, but more about BC issues here and there). Especially since it seems that you are the only one who actively looks after output buffering .. (Johannes actually asked to have this stuff in PHP 5.3 months ago, but you were a bit MIA back then .. and nobody else showed interest). So unless you can take our worries away in terms of BC issues, I guess we would prefer to leave this patch out of PHP 5.3. Sorry about the misunderstanding and the work you put into producing this patch. 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] Case sensitivity
On 06.11.2008, at 18:46, Stan Vassilev | FM wrote: NOTE: Continuing from thread Call it: allow reserved words in a class or not?: As much as I'd love to see more case-sensitivity, I'm afraid it would break quite a lot of existing apps, according to Google Code. http://www.google.com/codesearch?q=lang%3Aphp+%3D%5Cs%2AArray -JD It's worse than I thought, really out of the question for 5.x. Though I still think it's something we should consider for 6.0 as it's something we need to fix in the long term (and 6.0 already has breaks, such as strings used in binary operations need to be changed to binary strings). I can provide a short PHP script which can automatically fix the case of internal classes and keywords like array() in most source code out there. We can test such automated porting scripts on samples collected from PEAR, Google Code and projects like Drupal, Joomla etc. to reduce side effects. NO! regards, Lukas Kahwe Smith [EMAIL PROTECTED] -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] alpha3
Hi, This are tentatively looking like alpha3 could hit on November 18th. So everybody please try to get whatever you are working on ready to be finished and committed by no later than 13th. So that packaging can happen on a stable tree on the 17th. 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] [PATCH] PHP 5.2.7rc2: a bug that I'd like to see fixed in 5.2.7
On 06.11.2008, at 06:17, Mark wrote: Hi, We got some problems with PHP with wddx functions which consider PHP's side will always be ISO-8859-1. I wrote/tested a patch to fix this issue, against PHP 5.2.7rc2. Bugreport: http://bugs.php.net/bug.php?id=46496 NB: the bug has been marked bogus. I believe this is due to the fact the bugtracker isn't able to accept unicode characters, and converted my input to HTML gibberish. The patch itself: http://ookoo.org/svn/snip/php-5.2.7rc2_wddx_utf8_resolved.patch seems like he is right .. someone willing to look at the patch and mark the bug as fixed once the patch is applied? 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] namespace separator and whining
On 05.11.2008, at 01:05, Stanislav Malyshev wrote: Hi! or in other words give the user the ability to specify when he wants the fallback to global and not doing a fallback to global per default. That way This would be quite complex thing since this way you can't be sure which class gets loaded when you say, e.g., Exception - and thus, if you write something like throw new Exception(XML did not load) and except My\XML\Parser\Exception and have catch for it but get just Exception your application would happily unroll to the top and fail. I think actually knowing what class is going to be loaded is a good idea and overriding loader behavior so it's asked for one class and loads completely different one is not a good idea. One would expect if he asks for class X he gets class X, not class Y. Well, its not like the person is getting Y when he is expecting X. Both classes have the same name after all, so there is some relation between these two classes. More importantly its the users choice to enable this in __autoload(). As all frameworks got that its the end users job to implement autoload, I would not worry soo much in this case. Just a question: How hard would it be to implement in case we do want this? 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] namespace separator and whining
On 05.11.2008, at 21:24, Stanislav Malyshev wrote: Hi! Well, its not like the person is getting Y when he is expecting X. Both classes have the same name after all, so there is some relation between They don't have the same name - two classes can't have the same name. And relation is definitely not enough - you really do not ok, they have the same non fully qualified named. want to get generic \Exception instead of \My\Very\Specific \Exception - it would probably break all your error handling. this is about overloading and flexibility. these two classes. More importantly its the users choice to enable this in __autoload(). As all frameworks got that its the end users job to implement autoload, I would not worry soo much in this case. I do not see a need for autoload to substitute different classes instead of ones that are requested. autoload has very specific function - to load classes. To override it with tricks that substitute one class for another is the runkit domain, and IMHO should stay there. It would seriously complicate matters everywhere (if you load the class, you can no longer be sure successful loading have indeed loaded you the class you asked for!) and appears completely unnecessary hack. the point was that this gives the end user the choice of when, if at all, to fallback to the global namespace. in this way the default could indeed be 1) ns 2) autoload 3) fail. just that autoload can now handle more cases in a manner the end users might deem sensible. i guess the other alternative (though actually i am not sure if its possible), that people will likely try out is to extend the base class inside the namespace on the fly. which i would consider much worse. this might or might not be a sensible compromise, but you would do us all a favor if you would stop killing off open thinking with useless metaphors about 85 year old ladies. thanks ... 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] Re: Namespace Resolution
On 04.11.2008, at 18:43, Ryan Panning wrote: Just to make my post clear, I'm in favor of this approach for non- qualified calls in a namespace. 1. global 2. autoload 3. fail A couple of us (Hannes, Stas, Derick, Matt Wilson and I) were just chatting on IRC and we all favor the following: 1) ns 2) autoload (for classes) and global (for functions/constants) 3) fail So no fallback to the global namespace for classes, but fallback for all functions/constants (regardless of internal or not) Here are some reasons why we do not want a fallback for classes: - there are far less (and will likely be) global classes compared to functions, also class names need to be typed less often than functions to begin with = its less of an issue for classes - more importantly Stas pointed out that if we don't do it without fallback, THEN we'd have problems with typehints, since then we would have to start autoloading stuff i.e. fallback would force autoloading in some cases where presently there's none (instanceof, typehint, etc.) Here are some reasons why we felt that functions/constants should fallback: - most namespace users will be using classes and not functions - people expect direct access to the vast number of php functions/ constants Here is the reason why we felt we should not limit this to internal functions only: - @Derick some people provide drop in libraries for extensions such as curl - at the same time some people might choose to implement frequently used global functions inside an extension, which would result in a change of behavior (though this is not such a big deal) Here is a reason why we would limit this to international functions only: - @Stas but note that global user-space fallback for function means run-time resolution (which may be ok, but slower - no caching resolution in bytecode cache) However given that we expect the fallback to mainly be used for situations where one wants to provide a user land fallback implementation of something that would usually be available as an extension, it seems obvious that this is not the ideal case for performance to begin with, and the sole reason is to be able to run even in the absence of the ideal situation for performance where the function would be provided via an extension. 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] namespace separator and whining
On 31.10.2008, at 19:02, Lukas Kahwe Smith wrote: Hi I have tried to collect the various opinions on resolution order into a single RFC: http://wiki.php.net/rfc/namespaceresolution Proactive damage control: I have also included some discussion on how the removable of function/constants would affect the question of namespace resolution order choices. Lets not use this to get back on to the topic of the namespace separator and instead focus on the namespace resolution for now. First lets get an RFC that documents all approaches for namespace resolution in perfect shape. Divide and conquer. Furthermore, we have all noticed that the participation on the list has increased a lot in the recent weeks. As a result I ask everybody to restrain themselves a bit more. Try to not reply on an impulse, maybe wait a few hours before posting. This way we might reduce redundant replies, also the quality of posts will hopefully be higher so less misconceptions will need to be cleared later (and misconceptions have a way to spiral into flamewars). Some people have told me that they found the RFC hard to read. Unfortunately this is not the first time that I have gotten feedback like this from an RFC/FAQ I have written. If anyone has some suggestions for improvements please let me know. I have also just added another approach to the RFC. Instead of loading classes as follows: 1) ns 2) autoload 3) global one could also do 1) ns 2) global 3) autoload this would prevent the issue with performance that Stas pointed out. it would also retain the concept that autoload is a last resort attempt (i guess some people even define classes in the fly if they cannot be found elsewhere to be able to handle errors or even download code when needed). this would obviously mean that when someone wants to intentionally overload a class, its important to either use the fully qualified name or ensure that the class definition is loaded before use (similar situation as we have with functions/constants if we do have the fallback). 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] namespace separator and whining
On 04.11.2008, at 17:15, Gregory Beaver wrote: In other words, it is perfectly all right to have a different name resolution for classes than we have for functions and constants because of this different expectation. It is dangerous to fallback for classes prior to autoload, but it is not at all dangerous for functions/constants because the expectation is different. To me the key question is do we want to let people overload global classes easily or are we mostly talking about convinience? Class names are typed quite seldom (and even in a few years down the road the bulk of PHP's features will be provided via functions), so I would not think that we really need to focus on convenience here. 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. Note that I say try internal because the only purpose behind allowing this is to make it easier to use PHP's built-in functionality. Any userspace stuff should be specifically \prefixed or imported via use. I dont think it makes sense to differentiate between internal and non internal functions. I think this is quite hard to grasp, I also do not see the real benefit. And (yes) we need import for functions. Would be nice to have .. for me the pains for functions/constants have reached the threshold now that I am reviewing the question of resolution. 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] namespace separator and whining
On 04.11.2008, at 18:59, Gregory Beaver wrote: #2 means we want to be able to access stuff like strlen() and array_map() without any monkey business. snip functions/constants: 1) ns\func or ns\const 2) internal func\const 3) FAILBOAT Right, for the most part people will want access to internal functions, but what is the benefit of not including user space functions/constants? I find this quite confusing. The resolution rules should be easy to explain and it should be easy to understand what is going to happen when reading code. Nobody knows all PHP internal functions (especially as new internal functions can be defined by enabling extensions), so expecting people to know what will or will not fallback is kind funky. So lets have a look about the disadvantages of including all functions/ constants: 1) you have to ensure the proper load order 2) .. ? 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? 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] question on how to solve major stream filter design flaw
of decompressed zlib data, and a pointer to byte 8 as the next byte for php_stream_read() This way, we would essentially have a stack of stream data. If the zlib filter were then removed, we could back up to the bzip2 filter and so on. This will allow proper read cache filling, and remove the weird ambiguities that are apparent in a filtered stream. I don't think we would need to worry about backwards compatibility here, as the most common use case would be unaffected by this change, and the use case it would fix has never actually worked. I haven't got a patch for this yet, but it would be easy to do if the logic is sound. Thanks, Greg -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php Lukas Kahwe Smith [EMAIL PROTECTED] -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] An optimization idea
Hello again,
once again top posting this this is fairly old ..
however for something that is sounding so promising I am wondering why
this hasnt been picked up ..
regards,
Lukas
On 20.10.2008, at 22:09, shire wrote:
On Oct 19, 2008, at 12:11 PM, Karoly Negyesi wrote:
Hi,
I think zend_hash_compare could get a healthy speed boost in some
cases if first it would check whether the two variables passed to it
are actually the same (because of reference counting). Sorry, my C
skills are way too rusty to write the patch which is likely to be
just
a few lines long.
A quick patch/test seems to agree with you, I'd be interested to
know if you/others are able to apply this patch and see any real-
world savings with your web application. The following was done
with a debug build of PHP so results are likely exaggerated. I'm
also using non-recursive array with 256 byte strings below, results
with numeric values are less significant of course (approx a 25%
gain)...
I'll also look into applying this to some other functions like
compare_function where it's likely to yield a larger savings in a
general application.
patch against php-5.2 CVS head
--
iff --git a/Zend/zend_hash.c b/Zend/zend_hash.c
index a1d7071..d11785f 100644
--- a/Zend/zend_hash.c
+++ b/Zend/zend_hash.c
@@ -1327,16 +1327,14 @@ ZEND_API int zend_hash_compare(HashTable
*ht1, HashTable *ht2, compare_func_t co
IS_CONSISTENT(ht1);
IS_CONSISTENT(ht2);
- HASH_PROTECT_RECURSION(ht1);
- HASH_PROTECT_RECURSION(ht2);
-
result = ht1-nNumOfElements - ht2-nNumOfElements;
- if (result!=0) {
- HASH_UNPROTECT_RECURSION(ht1);
- HASH_UNPROTECT_RECURSION(ht2);
+ if (ht1 == ht2 || result!=0) {
return result;
}
+ HASH_PROTECT_RECURSION(ht1);
+ HASH_PROTECT_RECURSION(ht2);
+
p1 = ht1-pListHead;
if (ordered) {
p2 = ht2-pListHead;
simple test script
---
?php
$arr1 = array();
for ($i=0; $i 1; $i++) {
$arr1[$i] = str_repeat('x', 256);
}
$arr2 = array();
for ($i=0; $i 1; $i++) {
$arr2[$i] = str_repeat('x', 256);
}
$arr3 = $arr1;
$count = 0;
$start = microtime(true);
for ($i = 0; $i 1000; $i++) {
if ($arr1 == $arr2) {
$count++;
}
}
$stop = microtime(true);
echo different array time: .($stop-$start).\n;
echo count: $count \n;
$count = 0;
$start = microtime(true);
for ($i = 0; $i 1000; $i++) {
if ($arr1 == $arr3) {
$count++;
}
}
$stop = microtime(true);
echo identical array time: .($stop-$start).\n;
echo count: $count \n;
---
(un-patched php build)
[EMAIL PROTECTED]:~/data/php/git/php$ ./sapi/cli/php.vanilla test.php
different array time: 4.2019698619843
count: 1000
identical array time: 2.4957029819489
count: 1000
(patched build)
[EMAIL PROTECTED]:~/data/php/git/php$ ./sapi/cli/php test.php
different array time: 4.059928894043
count: 1000
identical array time: 0.00043511390686035
count: 1000
-shire
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Lukas Kahwe Smith
[EMAIL PROTECTED]
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] array_key_exists BC break
On 28.10.2008, at 15:33, Stan Vassilev | FM wrote: I would say no for 5.3. But for 6 it would be fantastic to have all array-related operations supporting ArrayAccess interface, where possible. +1 for this. Hi, cu, Lars Just making sure but: I think the BC break should be fixed. It's breaking actual code out there. The practice of passing traversable objects to our views, mixed with real arrays, is already common (I do it too). so where do we stand here? 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] Resource constants
On 27.10.2008, at 08:26, Kalle Sommer Nielsen wrote: 2008/10/27 Lukas Kahwe Smith [EMAIL PROTECTED]: On 27.10.2008, at 06:16, Kalle Sommer Nielsen wrote: 2008/10/26 Johannes Schlüter [EMAIL PROTECTED]: On Sun, 2008-10-26 at 14:32 +0100, Kalle Sommer Nielsen wrote: So, I propose its either being a supported feature, or simply put an deprecation notice on it (5.3) and remove it HEAD. I personally vote for the last option, as I don't think resources should be constants as they do not have the constant value even though they do on some level. I recently discussed the same issue on IRC, (due to #45982) we can't get rid of resources in constants completely as we need that for STDIN, STDOU, STDERR constants. Yes I know, but still I think we should either making it a supported feature or restrict registering resources on define(). Huh, I wasnt even aware that define() supports anything but scalar values. At any rate I am very sure I never stumbled over code defining a constant with a ressource. Not a very good idea to support ressources, especially given the obvious WTF's this causes (as you rightly pointed out). So I see that an E_DEPRECATED would make sense. However I am not sure about removing this though, which would make the E_DEPRECATED a bit odd (why deprecate if we do not remove?). E_DEPRECATED if we deprecated this feature, but I would be happy with an E_STRICT if this behaviour will be kept. :) so lets mark it as E_DEPRECATED in 5.3 and remove in 6.0, given that its currently not documented (though oddly it still discourages users to not do something that is not said to work Only scalar data (boolean, integer, float and string) can be contained in constants. Do not define resource constants.) 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] mSQL - goto pecl;
On 24.10.2008, at 14:15, Felipe Pena wrote: Hi youngs, What about moving mSQL to pecl? :) Derick copied it to pecl .. and i will delete it from php-src asap. 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] Resource constants
On 04.11.2008, at 23:02, Lukas Kahwe Smith wrote: On 27.10.2008, at 08:26, Kalle Sommer Nielsen wrote: 2008/10/27 Lukas Kahwe Smith [EMAIL PROTECTED]: On 27.10.2008, at 06:16, Kalle Sommer Nielsen wrote: 2008/10/26 Johannes Schlüter [EMAIL PROTECTED]: On Sun, 2008-10-26 at 14:32 +0100, Kalle Sommer Nielsen wrote: So, I propose its either being a supported feature, or simply put an deprecation notice on it (5.3) and remove it HEAD. I personally vote for the last option, as I don't think resources should be constants as they do not have the constant value even though they do on some level. I recently discussed the same issue on IRC, (due to #45982) we can't get rid of resources in constants completely as we need that for STDIN, STDOU, STDERR constants. Yes I know, but still I think we should either making it a supported feature or restrict registering resources on define(). Huh, I wasnt even aware that define() supports anything but scalar values. At any rate I am very sure I never stumbled over code defining a constant with a ressource. Not a very good idea to support ressources, especially given the obvious WTF's this causes (as you rightly pointed out). So I see that an E_DEPRECATED would make sense. However I am not sure about removing this though, which would make the E_DEPRECATED a bit odd (why deprecate if we do not remove?). E_DEPRECATED if we deprecated this feature, but I would be happy with an E_STRICT if this behaviour will be kept. :) so lets mark it as E_DEPRECATED in 5.3 and remove in 6.0, given that its currently not documented (though oddly it still discourages users to not do something that is not said to work Only scalar data (boolean, integer, float and string) can be contained in constants. Do not define resource constants.) ok i guess i was too quick with my call .. but i stirred up some discussion. as the following google code search shows the feature is used: http://www.google.com/codesearch?hl=enlr=q=lang%3Aphp+define.*(fopen| mysql_connect)\(sbtn=Search main use seem to be: 1) emulating STDOUT and STDERR when using cgi 2) as a pseudo super global to pass around db and log file handles to me 1) seems like something we might want to provide in some other way, while 2) does not seem like something people really need constants for. so imho i still think we should deprecate it .. but other people have noted that they prefer an E_STRICT. so lets have a quick vote here: 1) leave as is 2) raise an E_DEPRECATED in PHP 5.3 and remove in PHP 6.0 3) raise an E_STRICT in PHP 5.3 Also should there be some other way to get STDOUT and STDERR defined even if we go for 2) or 3)? 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] namespace separator and whining
On 05.11.2008, at 00:12, Marcus Boerger wrote:
classes:
1) try ns::class
2) autoload ns::class
3) fail
Since we can stack autoload we could provide a c-level autoload
function
that does the default lookup.
function global_autoload($name) {
if (($p = strrpos($name, '\\')) !== false) {
$name = substr($name, $p);
if (__NAMESPACE__ == substr($name, 0, $p -1) class_exists(\\
$name)) {
use \\$name;// if we find a way to do this at C-levle
}
}
}
just to make sure i understand this correctly .. you are suggesting
here that we make it somehow possible in __autoload() to fallback to
the global namespace. so that if someone wants the fallback to global
namespace behavior for classes, he could get this by calling this
standard autoload function (or rather by using the spl autoload stack
- noting that spl may not be disabled anymore as of PHP 5.3).
more specifically you want to enable use statements inside autoload. i
presume that use statement would only be in effect for this single
name resolution? as in the use statement would not have an affect on
subsequent triggering of autoload, even when originating from the same
file?
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] [PATCH]: Fix for endless loop in PDOStatement::debugDumpParams()
On 03.11.2008, at 19:54, Scott MacVicar wrote: Jonah H. Harris wrote: While using PDOStatement::debugDumpParams, I noticed that it results in an endless loop because the hash table is not being traversed. As such, attached is a patch against php5 HEAD which adds zend_hash_move_forward_ex accordingly. Your patch was stripped, can you attach against with a .txt extension. interesting .. i wasnt aware of this method. there is a doc bug on this on pecl.php.net: http://pecl.php.net/bugs/bug.php?id=13035 once again a reminder that we really do not have a good setup yet to manage the movement of extensions between pecl and php-src. also a pitty that the GSoC for a unified bug tracker apparently did not get finished (?) 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] Re: keeping traffic on this list manageable
On 01.11.2008, at 18:17, Guilherme Blanco wrote: The idea is awesome, but it'll definately not work. Sorry. By creating an UG profile subscription will allow again everyone to subscribe a group when it's really just one person that wants to write something. So the UG idea will not work. this was the potential abuse situation i mentioned. i honestly think that most people will understand that people will not abuse this less bureaucracy approach if we feel that it will benefit PHP. if this fails, we can then decide on additional barriers, turing tests or whatever. also in response to Larry .. thats why I said we should also accept virtual UGs, so that things do not need to be linked to a geographic location. for all we care, people can be members of how ever many UGs they want to be in. again it comes down to the question of can we trust our community? of course there will be abusers, but the question is if they are sooo large in numbers that they will prevent this from working? how many UGs are we expecting anyways? lets say we get 100 UGs to register. that would be quite an impressive number, but still manageable. if we get to 500 UGs, we would probably have to rethink the approach. like by seeing if we have mainly virtual or regional UGs etc. i think we can also weed out some fake UGs by just looking at their mailing list archives (no discussions means probably no UG). so if we do end up with 500 UGs that register and that want to actively take part in the discussion on internals, then i think this approach has validates itself: 1) it means we have helped quite a lot of UGs to form 2) it means we have grown the number of people that want to participate if this means we again have to review our discussion process, i am more than happy to do so. until then i feel this process could help get this list back to a more productive communication flow. it seems to me like a lot of the screaming and even personal attacks are caused by the fear that concerns might simply get lost in the noise. if we can do something to get rid of this fear (though probably never entirely), i think we have a chance of improving the general tone and productivity of this list. 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] keeping traffic on this list manageable
On 01.11.2008, at 14:35, Mike R wrote: Behavioral change is exactly what is needed. The simplest way to achieve that is education and buy-in. A good start would be to document the desired behavior, in an isolated php-dev subscription page, in the form of a _brief_ terms of use, and have new subscribers acknowledge and agree to it. There could also be a cooling off period, where new subscribers are read- only for the first NN days - that'll let tempers and hair-triggers cool off. The core team is populated by some of the smartest people on the planet, I'm sure some other ideas can be bandied about and implemented to achieve the desired goal without resorting to moderation. We do have something along those lines: http://www.php.net/reST/php-src/README.MAILINGLIST_RULES Maybe it needs to be cut down (or just provide the key points at the top) and automatically appended to all emails (including the welcome email) .. 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] namespace separator and whining
Hi I have tried to collect the various opinions on resolution order into a single RFC: http://wiki.php.net/rfc/namespaceresolution Proactive damage control: I have also included some discussion on how the removable of function/ constants would affect the question of namespace resolution order choices. Lets not use this to get back on to the topic of the namespace separator and instead focus on the namespace resolution for now. First lets get an RFC that documents all approaches for namespace resolution in perfect shape. Divide and conquer. Furthermore, we have all noticed that the participation on the list has increased a lot in the recent weeks. As a result I ask everybody to restrain themselves a bit more. Try to not reply on an impulse, maybe wait a few hours before posting. This way we might reduce redundant replies, also the quality of posts will hopefully be higher so less misconceptions will need to be cleared later (and misconceptions have a way to spiral into flamewars). regards, Lukas Kahwe Smith [EMAIL PROTECTED] -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] keeping traffic on this list manageable
Hi, So some core developers as well as lurking end users have noted that the traffic on this list prevents them from being able to follow this list. This is obviously a huge problem since this mailinglist is supposed to be our primary discussion and decision making tool. I had a chat about this with Zoe, Stephan (of symonfy fame) and Pierre at IPC. In this discussion I got the following idea (note that I am listing the names here in order to credit them in this idea, not because they necessarily endorse it): What if we have two lists for internal discussions. One which is just as open as the current one and one that is moderated. People with commit karma for php-src (and maybe also phpdoc) get unmoderated access. However this obviously creates the issue that the community and newcomers will have a much harder time to get in contact with the core development team. As the list is moderated, it would require people to manually allow the given posts. This creates a bottleneck which would also create considerable work for those moderators. 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. This enables members of the usergroup to feed their ideas via that person directly to the list, taking load of the list moderators and ensuring that things a given UG deem important are not lost in this process. Furthermore this intermediate step would serve to throttle the traffic and make the numbers of posters (their writing style and expertise) more easily transparent to other posters (but more importantly to the readers). I am sure this will help reduce misunderstandings and more importantly result in a more friendly tone (its just natural for people to feel overwhelmed by too large a crowd). As a side bonus, we strengthen UGs around the world. This will hopefully lead to better communication channels between internals and active community members. It will certainly ease the organization of future testfests (or docfrenzy's) as we will then have contact people to talk to as well as more of an incentive for people to join their local UG. I would not want to try to come to a closed definition of what constitutes a UG. 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). People can create physical UGs as well as virtual UGs for all I care. If we notice that this liberal approach gets abused (people faking UGs to get direct access and more voting rights) we can decide on taking some protective measures. But for now lets just assume that everybody in the community understands the beauty of such a liberal approach. --- Just like in my previous email. Please all try to focus on sending high quality replies to this list. So lets all restrain ourselves and wait a bit longer than usual before replying. Maybe someone else will already make the point you want to make and in the mean time you can think things over and optimize your message. regards, Lukas Kahwe Smith [EMAIL PROTECTED] PS: I have published the above text as an RFC on the wiki .. http://wiki.php.net/rfc/managinglisttraffic -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] Re: My rounding proposal: Ok for PHP 5.3?
Hi, Scott said he could apply the patch for you. And he is sitting right in front of me .. regards, Lukas On 28.10.2008, at 18:28, Christian Seiler wrote: Hi, Sounds to me like you have done your homework and are committed to maintaining this. Codewise I will leave the decision to Johannes however. As Johannes has given his OK, I've created two patches (one for PHP 5.3 and one for HEAD): http://www.christian-seiler.de/temp/php/2008-10-28-fpu/php-float-precision-5.3.patch http://www.christian-seiler.de/temp/php/2008-10-28-fpu/php-float-precision-6.patch (Both are basically identical) I've tested them with the current PHP 5.3 branch under Linux and Windows (gcc) and with current PHP 5.3 under Windows (MSVC8, i.e. 2005) The patch does the following: * New zend_float.h which defines the following macros: ZEND_FLOAT_DECLARE() - Declare necessary helper vars ZEND_FLOAT_ENSURE()- Ensure double precision ZEND_FLOAT_RESTORE() - Restore previous precision ZEND_FLOAT_RETURN(val) - Return a double and restore prev. prec. (They are an alias to corresponding the XPFPA macros from my header file) * Added my configure checks to acinclude.m4. * Use them in zend_strtod.c and zend_operators.c in order to ensure that the precision used for calculations and string-to-float conversions is always double precision. * Added Zend/tests/float_prec_001.phpt which makes sure that both calculations and string-to-float logic use double precision. [This will also detect misbehaving platforms.] Please feel free to change any comments wrt. where this logic is from and/or whitespace formatting in the files. I'd appreciate it if you could commit this patch in the next days so I can commit my patch for round() that relies on the above. Regards, Christian Lukas Kahwe Smith [EMAIL PROTECTED] -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] alpha2 scheduled
On 28.10.2008, at 13:41, marius popa wrote: but when all the comunity screems at the namespace issue i think core developers should be more diplomatic and offer the good solution not close the eyes and wash the hands and go forward its always nice to ask for diplomacy after throwing around insults. that being said, we have been quite calm in trying to explain the reasons. but maybe if people would try out more reasonable forms of inquiry it would all go a bit smoother, it takes two to tango. at any rate, i hope that we will soon have a FAQ online that will make it even easier (easier than reading through 3 RFC's on the wiki). not sure when that will be ready. an semisolution would be an php.ini variable like NAMSPACE_SEPARATOR=:: so if you have an issue with your classes can be reset to \ or whatever with ini_set this will lead to incompatible code and deployment nightmares. 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] Resource constants
On 27.10.2008, at 06:16, Kalle Sommer Nielsen wrote: 2008/10/26 Johannes Schlüter [EMAIL PROTECTED]: On Sun, 2008-10-26 at 14:32 +0100, Kalle Sommer Nielsen wrote: So, I propose its either being a supported feature, or simply put an deprecation notice on it (5.3) and remove it HEAD. I personally vote for the last option, as I don't think resources should be constants as they do not have the constant value even though they do on some level. I recently discussed the same issue on IRC, (due to #45982) we can't get rid of resources in constants completely as we need that for STDIN, STDOU, STDERR constants. Yes I know, but still I think we should either making it a supported feature or restrict registering resources on define(). Huh, I wasnt even aware that define() supports anything but scalar values. At any rate I am very sure I never stumbled over code defining a constant with a ressource. Not a very good idea to support ressources, especially given the obvious WTF's this causes (as you rightly pointed out). So I see that an E_DEPRECATED would make sense. However I am not sure about removing this though, which would make the E_DEPRECATED a bit odd (why deprecate if we do not remove?). 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] mSQL - goto pecl;
On 24.10.2008, at 14:15, Felipe Pena wrote: Hi youngs, What about moving mSQL to pecl? :) I guess thats a go then. Derick you said you could handle the move? 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] namespace separator and whining
On 27.10.2008, at 22:27, Sean Coates wrote: You want to force users to use the full name at all times. IOW, you want to sacrifice convenience for performance. (chiming in because it seems that we're overlooking something obvious here) If it comes down to this, I'd prefer to see an E_NOTICE for the bad performance use, though I don't think it's necessary to shield users from this. There's plenty of poorly performing PHP code out there that an extra disk access isn't going to hurt. this seems like a very good idea to me. this way things default to just work (which imho is the PHP spirit), while its brain dead easy to detect misuse. 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] namespace separator and whining
On 27.10.2008, at 23:01, Stanislav Malyshev wrote: Hi! this seems like a very good idea to me. this way things default to just work (which imho is the PHP spirit), while its brain dead easy to detect misuse. They not just work - they work in a wrong way (not usable in any practical application). And E_NOTICE is a non-solution here - if we know that it's wrong enough to put a warning there, why we don't make it right? Why should we put another thing to stumble upon - why people should learn another gimmick you can write it that way, but you never should do it because it works badly. If they shouldn't write it that way - what would be the reason to allow them to do it instead of giving clear error message that makes it easy to fix? I can understand when such things are left over by BC reasons - but to explicitly design the language in a way that needs footnotes and warnings to code around bad design? just the same reason as you can use a constant without initialization. out of the box PHP does not try to be a teacher. it lets you write you code that does what you need. but it lets you grow at the same time. this is how PHP got its huge userbase. we let people grow with their needs. 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] namespace separator and whining
On 27.10.2008, at 23:27, Stanislav Malyshev wrote: this is how PHP got its huge userbase. we let people grow with their needs. And how exactly it serves the needs of people by secretly making their applications orders of magnitude slower, and then saying oh, that's because you failed to read paragraph 16.4.5.1 in the manual, you should really read that paragraph before pretending to be PHP programmer!. Good environment or does what you want it to do, or fails, explaining to you why it doesn't work - it doesn't do it half way half broken and then blames you for not reading some obscure note in the manual. That's not how I see helping. ok this might be a shock for you .. but the vast majority of our user base does not have a performance problem (thats not to say we need to waste their CPU cycles .. we all love the planet). then as we are suggesting they will not have to read a manual. in our proposal they can use all the existing books, examples on PHP, migrate their code easily to namespaces and things will just work. if they advance beyond the point of absolute n00b, they will learn to look for E_NOTICE and by that time they will know how to fix their performance issues (if they have any) without having to open a manual. in your scenario, all examples in the world will mysteriously break when they are used inside a namespace (which they might have gotten from another example or some inherited 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] namespace separator and whining
On 26.10.2008, at 19:07, Sebastian Bergmann wrote: Greg Beaver wrote: The decision is made, now I suggest everyone get busy actually trying it out. How are we supposed to try it out? There is no updated implementation yet, and I would rather discuss a specification instead. It was mentioned on IRC that internal functions have to be prefixed with \ when used in a namespaced file. Without a fallback. This is insane. We should either disallow functions and constants in namespaces which, as far as I understand the issue, got us into the trouble, or remove the feature completely. Sebastian, you have not participated in the discussion so far. Now you post a rumor you picked up on IRC into an already heated situation. You do know full well that it does not require you to point out that this would indeed be problematic (since people who are participating in this discussion are actually aware of this). So do us all the favor and stop and think a second before you post the next time. 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] namespace separator and whining
On 26.10.2008, at 21:59, Pierre Joye wrote: Hi Lukas, On Sun, Oct 26, 2008 at 11:28 AM, Lukas Kahwe Smith [EMAIL PROTECTED] wrote: Sebastian, you have not participated in the discussion so far. Now you post a rumor you picked up on IRC into an already heated situation. You do know full well that it does not require you to point out that this would indeed be problematic (since people who are participating in this discussion are actually aware of this). So do us all the favor and stop and think a second before you post the next time. 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. Admittedly the meeting was mainly scheduled to allow Greg, Dmitry/Stas and at least half a dozen (it was even more in the end) of core developers that have spend time to follow the discussions and thought processes to come together. We had the assumption that this was a sufficiently large and competent group to make a decision on something that many (including you) have said is important but where neither of the choices spell doom for PHP, while still not being easy. Now the people that were not able to attend this IRC meeting can either accept that there was a sufficient number of people to make a final decision on something that everybody (obviously also people who did not attend the meeting) had plenty of time to make their concerns heard or you can question this approach. 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). I'd to say that I do not care about which symbol is used. Right, there are plenty people in both camps. @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. As was evident from the discussions in the past weeks, a lot of people commented, most of which did not spend the necessary time to actually understand the issues at hand. Given that it did indeed make it impossible to bring this topic to a conclusion on the list. As for transparency, I see no issues. The decision process was entirely transparent, albeit the final decision meeting was not open to all. Again everybody that cares had weeks/months (actually years) to bring up his POV. In the end there were 10 people (including both RMs) that made a final decision and that are prepared to take the blame. 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] namespace separator and whining
On 26.10.2008, at 22:19, Pierre Joye wrote: To make my point more clear: I respect the decision even if I'm not completely happy about it (that's what we call a compromise). But my comment to Greg and Steph was about the danger of abusing of private discussions not about having held this meeting on IRC. ok point taken. we should indeed not get in a habit of this kind of decision making. while none of us can prevent offlist discussions, we should also all of course try to keep things onlist as much as possible. but its still fine to talk things over to get things a bit more coherent before posting to internals (in the spirit of signal to noise ratio). regards, Lukas Kahwe Smith [EMAIL PROTECTED] -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] /endnamespacediscussion
Hi all, Thx to the initiative of Scott and Steph we had an IRC discussion with several code developers. The result is that we have decided to go with backslash as new separator for namespaces. The IRC log that illustrates why we in the end decided to go with changing the separator and the final decision on backslash can be found on the wiki [1]. Greg is working on a patch, however Dmitry said he will assist even though he was actually opposed to the decision we made in the end. I very much appreciate Dmitry accepting this decision in such a professional manner. At the same time I hope that all people that have participated in this discussion accept this decision as one that was made by a sufficiently large subset of the development community. We did not take the decision lightly but we felt confident that this decision is for the best of PHP going forward. As the patch is still under development it is yet unclear how this will affect the scheduling PHP 5.3. regards, Lukas Kahwe Smith [EMAIL PROTECTED] [1] http://wiki.php.net/rfc/namespaceseparator -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] str_getcsv
On 20.10.2008, at 23:07, Ilia Alshanetsky wrote: On 20-Oct-08, at 4:46 PM, Hannes Magnusson wrote: On Mon, Oct 20, 2008 at 22:43, Steve Hanselman [EMAIL PROTECTED] wrote: Can anybody suggest a reason why this has never moved from main to php_5_2 or php_5_3? I did wonder the same months ago, but noone seemed to care, and I had no use for it myself so I never bothered merging it :) The functionality is rather handy (I think), I would +1 for its addition to the 5.3 branch. if someone commits it before alpha3 its fine by me. 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] Re: Sanity tally #2
On 17.10.2008, at 04:18, Steph Fox wrote: 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. We are not ready yet. So for now I will not force a decision just yet. Hopefully next week ... 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] Re: PHP 5.2.7RC1 Testing
On 17.10.2008, at 12:28, Lester Caine wrote: Pierre Joye wrote: From now on I will simply stop to read any post from you as long as there is uppercase words in it. It is annoying, respectless and does not make your point any better. I make no apologies for formatting text as I see fit. It would have been very useful if you had simply corrected Ilia's post at the time. I do Well Pierre is not alone and the other day I was about to write something similar. So add me to the list of people that will ignore you if you insist on this formatting. Its just a question of accepting the way people talk to each other on this list. If you absolutely need to highlight, then others have used an underscore in front and at the end of the words they wanted to emphasize, but even that is rarely used. Somehow others seem to get by with just English without having to emphasize words in their sentences. Accept this or accept that your emails will go to /dev/null. Your choice. 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
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.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
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] __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] 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] namespaces and alpha3
On 15.10.2008, at 11:35, Ron Rademaker wrote: Lester Caine wrote: What would be the advantage of wrapping legacy functions in a namespace over wrapping them into a class as static functions? THAT is probably why I am asking the question? And may well be key to my understanding why converting non OO code into OO code in PHP is so problematic. When I was coding in CC++ more heavily libraries did not need to be objects and the 'namespace' just wrapped the code OR the code was built as an object. That is what I understand by a namespace, so perhaps I do not understand why leaving out functions and constants is acceptable :( I don't think there's any difference between moving non OO functions to a class and making the static and moving those to a namespace (in a suggested syntax it would be: Bar:::foo() for a namespace and Bar::foo() already for a class). Even more, I think there are advantages for moving a legacy app to a class because it allows you to make your global variables (like things in legacy apps) class members. Of course that's only an advantage if you agree that globals are evil... So my conclusion would be that leaving out functions and constants is acceptable because there's no advantage of having those in a namespace. Classes already provide everything you would possibly want from namespaces for functions and constants. well you cannot split a class definition across several files. so if you move your functions to a class, you need to move them all to a single file. 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 and alpha3
On 10.10.2008, at 19:02, Stanislav Malyshev wrote:
It should be noted that this proposal builds on Stas previous proposal
after Zendcon
1. Allow braces for namespaces. So, the syntax for namespaces will be:
a) namespace foo;
should be first (non-comment) statement in the file, namespace
extends to the end of the file or next namespace declaration.
b) namespace foo {}
can appear anywhere on the top scope (can not be nested).
Mixing both syntaxes in one file is not possible. The semantics of
both syntaxes will be identical.
2. Simplify resolution order for classes in the namespace:
unqualified names are resolved this way:
a) check use list if the name was defined at use, follow that
resolution
b) if not, the name resolves to namespace::name
Consequence of this will be that for using internal class inside
namespace one would need to refer to it either as ::Foo or do
use ::Foo prior to its usage.
The original 3rd point from the proposal now has the following two
optional solutions (the first one being the originally proposed
approach):
I have two proposals, actually.
1. Leave functions (and constant) alone, i.e. namespace would ignore
that.
1.1 Option: if you define function inside namespace, compiler could
give an error (I don't like this option, but I mention it for the
sake of completeness).
I am -1 on this one.
2. Leave functions/constants as they are now, and add the following
syntax:
Class::Name-method()
for calling static methods (and referring to class constants), so
that there would be a way to disambiguate calls in (rare, IMHO)
situations where ambiguity may arise.
I am +0.5(*) on this one. I dont like the fact that this means that
code needs to be migrated before being unambiguous, so I preferred the
idea of having a different separator between namespaces and its
members, but this way there is at least a solution available.
(*) There is a condition under which I would be +1 for the syntax. If
in PHP6 we can make the old syntax (A::foo() and A::FOO) raise an
E_STRICT (I dont think we ever want to remove it, so E_DEPRECATED
would not be the right choice), when its being used to reference class
members instead of namespace elements. If I understand the namespace
resolution rules properly, we check namespaces first before checking
for a class with the same name. So with the E_STRICT in place,
developers could protect themselves perfectly from accidental
ambiguities (if they were to ever introduce a namespace with the same
name as a class with a constant or static method that is referenced
using the double colon) and effectively migrate to the new syntax
(which I think is nicer anyways, than the original syntax).
---
Barring any new major findings I ask everybody to cast their vote by
Thursday evening PST. Since Dmitry was not happy with his proposal we
are left with:
1) Rip them out
2) Keep as is
3) Stas proposal with functions/constants ignored
4) Stas proposal with - optionally allowed to resolve ambiguities
If we have a decision by Thursday evening we could hopefully do an
alpha3 by Thursday the following week, although I would want any
namespace to be documented before (or closely around) the release of
alpha3. Stas said that he would be willing to update the README in a
timely manner after finishing a patch, in case we go for 3) or 4). I
hope we can also find the time to transfer any changes to docbook
quickly after this.
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] Deprecate define_syslog_variables in 5.3
On 14.10.2008, at 04:04, Kalle Sommer Nielsen wrote: Hello internals I've been looking at the function define_syslog_variables(), and I'm unsure if its intentional to keep this old functionality in PHP, seeing as define_syslog_variables defines a shortcut for each of the LOG_* constants in the form of $LOG_*. Therefore I propose the function is being deprecated in 5.3 and removed in HEAD. I agree. Fixing your code is easy (just remove the call to define_syslog_variables() and the $ in front of LOG), maintains BC with older PHP releases. On the up side this function could create an insanely hard to debug problem for users, is redundant and was a very bad idea from the start (and the docs seem incorrect too). That being said I never used this function or the constants in my code. So is there anyone that does actually use it and has some objection? 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] Deprecate define_syslog_variables in 5.3
On 14.10.2008, at 15:03, Markus Fischer wrote: Hi, Lukas Kahwe Smith wrote: That being said I never used this function or the constants in my code. So is there anyone that does actually use it and has some objection? Me neither, but in such cases it's probably a good idea to take a look at code search machines, e.g. http://www.google.com/codesearch?as_q=define_syslog_variablesbtnG=Search+Codehl=enas_lang=phpas_license_restrict=ias_license=as_package=as_filename=as_case= right .. and the interesting thing there is that most of the code is using the constants even though it calls the function to define the variables beforehand. the faulty documentation is probably the cause of this. so for the most part people will just need to remove the function call. 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 and alpha3
On 14.10.2008, at 14:10, Steph Fox wrote: I'm +1 on ripping out and leaving til 6.0. I don't think there is enough time between now and the 5.3.0 code freeze to make major changes to the language syntax. Making - do double duty and adding E_STRICT messages to currently legal code really doesn't look like a good option to me, much less during a point release and even less during the final moments of a release cycle. Leaving as-is, we already know is problematic. There's no consensus to pull support for functions/constants, which would make it less problematic. Just for the record, I was suggesting to add the E_STRICT in PHP6, not in PHP 5.3. 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 and alpha3
On 14.10.2008, at 21:01, Steph Fox wrote: 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. Ok, lets slow down here for a second. 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. 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. Then we can alternatively push it to PHP 6 or drop the idea all together. 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. 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. I think they do understand the issue. That being said Greg also understands the issues well and disagrees with Stas, however I will leave it to him to decide on how to voice his concerns if at all. I am sure several other people on this list have followed the discussions close enough to be able to cast an educated vote. However if you do not understand the issues do not vote (I do of course not know who has been following the discussion or has not, so its up to each person to decide if they are in the loop enough to vote), unless you simply generally mistrust the approach taken to get to this point or the people involved. 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 and alpha3
On 14.10.2008, at 22:55, Stanislav Malyshev wrote: Hi! 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. Exactly. This is because we announced it on conferences, talked about it on lists and basically made a lot of noise about how cool it would be very soon. And people believed us and took the risk. And now you propose to teach them the lesson that trusting PHP core developers that they actually deliver is a bad idea. just to clarify .. there are solutions on the table that people have worked on hard and that are believed to solve the issues, albeit that come with some carefully chosen baggage. We are not discussing how to do things (this goes to Nathan's reply that just came in). if we remove namespaces now, after talking about it, prodding it, asking people to try it out, getting a lot of general positive vibe for this feature, coming up with a solution .. then i think we are doing our users a disservices. the proposals are not half baked omg we need to get this done quickly for alpha3 (note that alpha3 was delayed to get to this point). of course waiting longer always gives the opportunity to improve tweak etc. but given that we might as wel stop releasing software altogether if we are unwilling to take the risk of a mistake. 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. 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 and alpha3
On 14.10.2008, at 23:15, Steph Fox wrote: 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. err .. you misunderstood me .. Dmitry wasnt happy with his approach .. last I heard Greg also stopped exploring his alternative approaches. so dont hold you breath. 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] php_firebird
On 07.10.2008, at 20:18, Lester Caine wrote: What is the correct procedure to create a new driver, or rather clone the existing php_interbase so that we can build a proper Firebird version that actually uses the fbclient.dll rather than sharing the now incompatible GDS32.DLL client. Some people are starting to use Interbase in parallel with Firebird, but the driver can only access one client :( IMHO new database extensions should not be permitted unless they come on the form of PDO drivers. Thats also the vibe we send the Microsoft guys with their sqlsrv extension. So if you cannot achieve what you need within the existing extension while maintaining BC, I am afraid imho you will have to bite the bullet and all the features into the PDO driver. Thats my opinion at least. 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] Critical bugs to fix before ANY release
On 07.09.2008, at 13:33, Jani Taskinen wrote: There are some bugs that have to be fixed before any actual release can be even dreamed of: http://bugs.php.net/search.php?cmd=displaystatus=Critical Note that 2 of those even have patches attached to fix them.. There are 2 left at this point: 1) http://bugs.php.net/bug.php?id=27792 I know we have been talking about LFS since ages (just as we have been talking about expanding the storage limit for integers). But I would not consider this a bug let alone critical. Its a missing feature, that we all agree should be provided. However I do not see why this is critical for PHP 5.3 .. or am I missing something 2) http://bugs.php.net/bug.php?id=44936 Last comment was on September 8th, where Stas asked what the exact BC issue was .. I imagine the issue is that this causes issues in situation where the value is being compared to some non PHP source (like a configuration file). 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] php_firebird
On 14.10.2008, at 07:15, Lester Caine wrote: Pierre Joye wrote: effectively the extension for firebird already exists ... it just maps to the interbase function, if the fbird_*() aliases were removed and renamed copies the ibase_*() extensions functions created that then were built against the firebird client iso the interbase client you'd pretty much be there. technically the [firebird] extension would be new but is that really a deal breaker given that the complete API (fbird_*()) already exists? I do not understand this paragraph. When Ard rebuilt the php_interbase driver for PHP5 he created fbird_ aliases for all the ibase_ functions. The driver is specific to PHP5 and always has been. It was never back ported to PHP4. The PLAN was always when there was a pressing need to separate Interbase and Firebird all of us who use fbird_ would simply switch to php_firebird without any internal code changes. At present there is a 'niggle' rather than a 'pressing need' to implement the split, but given the other discussions going on, now is probably the time to sort this out as well? I have no problem with php_interbase and php_firebird being in pecl, as long as they are being compiled somewhere for those of us who do not have M$ tools but have to support customers who have yet to convert to Linux ;) Ok, I was not aware of this. It does change things a bit, but imho I would still prefer if most of this could be handled by an extension internal switch. As for the use case of using interbase and firebird in parallel. If you absolutely need this and are unwilling to do this inside a PDO driver I do acknowledge that there are a lot of features missing from the current PDO driver, the performance difference does not strike me as a valid argument though. Foremost its not like its a difference of day and night, also fetchAll() can actually increase performance compared to the current database extensions. Also its still negible compared to the time applications spend on their queries. Also its not like PDO cannot be improved (of course there are some limits in the current architecture). So for core my opinion holds, that only PDO drivers should be added, but PECL is of course another story. 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] json_encode ignores protected/private class members
On 09.10.2008, at 15:45, Dave Ingram wrote: But when using json_encode I believe the developer wants to transfer the complete object state, just like when using serialize. Serialize does see private/protected class members, while json_encode not. If you want to serialize an object, then use the appropriate function. I think that json_encode() has the correct behaviour - encoding only the publicly-visible structure of an object. They have fundamentally different aims. If you want to expose data to an external source (e.g. JavaScript) then surely it would make sense for it to be a public class member? Why would you not want your PHP code to be able to access it? Because JSON is a language agnostic serialization format. Again I agree that in the usual situation you only want public, but the other use case is also quite legit. Having to add such a hack into every class is not very useable, especially until we have traits. 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] json_encode ignores protected/private class members
On 09.10.2008, at 15:26, David Coallier wrote:
Ok, nice solution, but I still don't see why json_encode ignores
protected/private class members. I mean, why we need this feature.
Because, in theory, it shouldn't even be able to see those members?
Stefan's right. Unless you are in the local scope or inheriting the
object you shouldn't be able to see those variables. And I have yet to
see
classs Name extends json_decode($jsonValues) { }
That's the point in having access modifiers. Unless I'm mistaking
there's no bug there.
well .. i think this is at least the common use case. then again, json
is an encoding format, and i expect that i can get the same object
state by decoding. so the expectation to also get non public
properties in the json encoded string is not totally crazy.
however changing this at this point would be a huge security issue, so
if at all, it would need to be handled by an optional parameter that
defaults to false.
regards,
Lukas Kahwe Smith
[EMAIL PROTECTED]
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] namespaces and alpha3
Hi All, There was an offline exchange, which generated a lot of good ideas, but that failed to find agreement for one final proposal among the participants. I had hoped that the results would have been mailed to this list yesterday. Since I am going on yet another frisbee trip in about an hour, I am putting on the thumb screws with this post. Stas might update his proposal and Dmitry has a proposal that makes some more modifications to be able to handle functions/constants in namespaces without ambiguities. I will leave it to them to send their proposals to the list. At this point I guess we have the choice between: 1) rip them out 2) status quo 3) Stas proposal 4) Dmitrys proposal Again I hope that Stas/Dmitry will give us an insight about their proposals, though Stas proposal might or might not see any changes. In my dream world you all would come to an agreement, finish up the patches by Monday so that we could release alpha3 next Thursday. Since that is not going to happen we will see alpha3 on the 21st I guess. 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] Re: [PHP-CVS] cvs: php-src(PHP_5_3) / NEWS /ext/pgsql pgsql.c
On 02.10.2008, at 14:27, Ilia Alshanetsky wrote: No, its for security or critical fixes only. I'd say that a crash inside a key area of the code is critical... snip Hmmh.. Does this mean that 5.2 is dead and all the unreleased 5.2 NEWS entries should be moved to 5_3? Just to give perspective: PHP 5.3 alpha3 is expected for mid October. Which means the beta phase will last until early November at best. As a result there will only be a 5.3 release towards the end of November at the earliest. If we cannot hit a mid December release, I guess we should not release over Xmas, which would put us at an early January release of 5.3 in a worst case situation. Given that, are we sure we do not want to push out a 5.2.7 release which contains some general bug fixes sometime in October/November? 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] Re: [PHP-CVS] cvs: php-src(PHP_5_3) / NEWS /ext/pgsql pgsql.c
On 03.10.2008, at 16:02, Jani Taskinen wrote: PHP 5.2.7 is long overdue already. Propably due to the RM being AWOL for quite long time. There are several fixes in 5.2.7 that should be out there yesterday. If the current RM is not interested in releases anymore, I can take over. I guess one task that will likely be necessary is to ensure that all NEWS entries are in the proper location. I fear some stuff is now in the 5.3 NEWS file that would then need to be in the 5.2 NEWS file in case we do release 5.2.7. But I guess you (Jani) and Hannes are tracking (and slapping) those cases quite diligently. 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] Platform maintainers overview?
On 29.09.2008, at 17:05, Lukas Kahwe Smith wrote: Hi, Christian poked me offlist about the rounding patch. While talking about that patch with Johannes I began to wonder if we have any interest in maintaining a page on the wiki (or a README in php-src) with contact information for each OS/CPU/Webserver combination. I guess for Apache on Linux x86 we have all of internals. For windows and IIS we have the windows team (presumably on all CPU variations?). FreeBSD is covered by Yahoo. I guess Sun will eventually cover Sparc. So that leaves other web servers, OS's and CPU's to ..? Just FYI, David did some initial work on creating a wiki page: http://wiki.php.net/platforms I guess I will move this to a different location (probably http://wiki.php.net/internals/platforms) , but I invite everyone to fill in the blanks or correct any guesses David made. 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] true namespaces, yet another point of view
On 29.09.2008, at 00:21, Gregory Beaver wrote: Lukas Kahwe Smith wrote: On 24.09.2008, at 01:17, Guilherme Blanco wrote: For those that do not understand very well the explanation of jvlad... He's suggesting to change the class struct to be an scope struct, and have a property that tells if it's a namespace or a class, and reuse the implementation of class which already works very well. The nested support is achieved afai understand through the Adjacency List algorithm... can you confirm this to me? or just leave the organization of things to classes (with long class names with a nice prefix to prevent collissions) and leave it to class_alias() (and equivalent features for functions .. also with the option of a compile time aliasing) to handle the aliasing. this removes the need for namespaces and use statements, while making it possible to make class/function names short (that are long for organizational and collision prevention reasons). Hi, This approach doesn't work because aliasing with class_alias() does not allow name conflicts: Well my point was .. Library code uses long names, glue code can alias. Of course sometimes the lines between what is library and glue code are hard to draw. Anyways, I guess we are close to a good solution for namespaces in 5.3 .. 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] alpha3
Hi, Ok before we all go crazy with the NS separator debate, some reading (which also links to a few interesting posts/sites): http://marc.info/?l=php-internalsm=113313170231815w=2 http://marc.info/?l=php-internalsm=113345477123705w=2 http://marc.info/?l=php-internalsm=117742643931293w=2 I have also emailed Jessie to see if we can somehow resurrect the content on http://www.phpnamespaces.org/ I invite anyone that seriously wants to have that debate again to scavenge through all of that, write a page on the wiki first. regards, Lukas -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] Platform maintainers overview?
Hi, Christian poked me offlist about the rounding patch. While talking about that patch with Johannes I began to wonder if we have any interest in maintaining a page on the wiki (or a README in php-src) with contact information for each OS/CPU/Webserver combination. I guess for Apache on Linux x86 we have all of internals. For windows and IIS we have the windows team (presumably on all CPU variations?). FreeBSD is covered by Yahoo. I guess Sun will eventually cover Sparc. So that leaves other web servers, OS's and CPU's to ..? 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] solving the namespace conflict issues betweenfunction/staticmethod class constant/ns constant
On 30.09.2008, at 05:36, Daniel Convissor wrote: Hi Greg: On Sun, Sep 28, 2008 at 09:58:25PM -0500, Gregory Beaver wrote: The second highest vote was :::, but there was strong objection to this as well from some. Sounds like you have the tally or know where it is (or you have an excellent memory). Do you have a URI for it, please? I linked to one tally (not sure if its the final one) in my recent email: http://marc.info/?l=php-internalsm=113313170231815w=2 The problem, I still believe, is that we are focused on having the same:::stupid:::operator:::between:::everything. ... In truth, it will be a lot easier to debug code if this is a different separator, as the boundary between namespace and element will be crystal clear. For instance: ... my::framework..someFunction()-aProperty-someMethod(); Good points. And thanks for the patch. (Perhaps we can harness the vast amounts of energy inside Greg to resolve our oil dependence?) Regardless of whether we use the same separator between namespaces and the elements or if we just use a different separator between namespaces and the elements, some separator needs to change. This is a dangerous comment. Again to make it clear, with a single separator, whatever it may we, we will still have ambiguity. Only with two different separators as Greg describes can we really solve this problem. But yes, we I presume what you mean to say is that if we want to improve the situation we have to find a second separator. 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] [Fwd: [PATCH] Backport of HEADs output API]
On 26.09.2008, at 12:04, Michael Wallner wrote: Lukas Kahwe Smith wrote: well the question is does it fix some real world bugs? this late in the game i would not want to include these changes if they just add features .. Huh? :) The question to me is, why did you ask me to do it, when you're not sure what it's about? Not to be anally at all... ;) I guess we cleared up the misunderstanding on IRC. The greatest plus to me are: - getting rid of monolithic php_end_ob_buffer() - getting rid of output handler specific code in SAPI.c - being able to hook from the running output handler to change it's behavior - being able to clearly configure conflicts and reverse conflicts between output handlers These are all convincing arguments to have done this earlier. But Johannes and I are a bit worried, that this code did not see that much testing since it was checked in to HEAD quite a while ago. And seeing that the backport is mainly cleanup and not bug fixing, we are a bit worried about the risk this backport has (not necessarily in it introducing bugs, but more about BC issues here and there). Especially since it seems that you are the only one who actively looks after output buffering .. (Johannes actually asked to have this stuff in PHP 5.3 months ago, but you were a bit MIA back then .. and nobody else showed interest). So unless you can take our worries away in terms of BC issues, I guess we would prefer to leave this patch out of PHP 5.3. Sorry about the misunderstanding and the work you put into producing this patch. regards, Lukas Kahwe Smith [EMAIL PROTECTED] -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] alpha3
Hi, We are not yet ready to schedule alpha3, but I am hoping we can do it in the first half of October. This is just a heads up to tell everybody that yes there will be an alpha3 and a general timeframe. This is not an invitation to go crazy and start committing features at all. If you have something that you think is very low risk, unquestionably useful, with ready tests and patches, then feel free to approach me and Johannes. Otherwise just help us to get 5.3.0 out the door, so that you can add whatever niceties into 5.3.1 :) 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] [Fwd: [PATCH] Backport of HEADs output API]
On 26.09.2008, at 21:59, Pierre Joye wrote: On Fri, Sep 26, 2008 at 9:38 PM, Lukas Kahwe Smith [EMAIL PROTECTED] wrote: So unless you can take our worries away in terms of BC issues, I guess we would prefer to leave this patch out of PHP 5.3. I strongly disagree, for two reasons: 1. We are going to release an alpha3, that's the perfect time for such change Perfect might be overstating things. Lets say it makes it possible to even consider it. 2. The OB code is messy right now, Mike's work cleaned it up and makes it more maintainable. 5.3 is going to be here for a long time, let make our work easier. Well but messy just means its even harder to ensure BC. Like I said in my mail, we would have loved to have seen this earlier (when Johannes originally asked for this). The fact that nobody stepped up back then is also telling us RM's that there is a definitive risk that if there are issues, we might end up with a similar situation as back then. Without having evaluated the code in the last detail, it seems that OB stuff is not small or self contained by any stretch of the definition. Given that this patch fixes no existing bugs, we have decided that its too risky to do right before what we hope will be the final alpha3 in one of the most feature rich minor releases in PHP history. We do not want to risk delay this release for something that might be messy, but has/does work more or less reliably for people. 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] [Fwd: [PATCH] Backport of HEADs output API]
On 26.09.2008, at 22:01, Jani Taskinen wrote: Lukas Kahwe Smith wrote: On 26.09.2008, at 12:04, Michael Wallner wrote: Lukas Kahwe Smith wrote: well the question is does it fix some real world bugs? this late in the game i would not want to include these changes if they just add features .. Huh? :) The question to me is, why did you ask me to do it, when you're not sure what it's about? Not to be anally at all... ;) I guess we cleared up the misunderstanding on IRC. The greatest plus to me are: - getting rid of monolithic php_end_ob_buffer() - getting rid of output handler specific code in SAPI.c - being able to hook from the running output handler to change it's behavior - being able to clearly configure conflicts and reverse conflicts between output handlers These are all convincing arguments to have done this earlier. But Johannes and I are a bit worried, that this code did not see that much testing since it was checked in to HEAD quite a while ago. And seeing that the backport is mainly cleanup and not bug fixing, we are a bit worried about the risk this backport has (not necessarily in it introducing bugs, but more about BC issues here and there). Especially since it seems that you are the only one who actively looks after output buffering .. (Johannes actually asked to have this stuff in PHP 5.3 months ago, but you were a bit MIA back then .. and nobody else showed interest). So unless you can take our worries away in terms of BC issues, I guess we would prefer to leave this patch out of PHP 5.3. Sorry about the misunderstanding and the work you put into producing this patch. The patch fixes several output buffer bugs. Those alone are enough to allow this getting in PHP_5_3 and really get TESTED too. if it does fix bugs .. that changes things of course .. but i asked Mike specifically about this .. and he did not mention this .. so does it fix bugs or not? 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] [Fwd: [PATCH] Backport of HEADs output API]
On 26.09.2008, at 22:06, Hannes Magnusson wrote: On Fri, Sep 26, 2008 at 21:38, Lukas Kahwe Smith [EMAIL PROTECTED] wrote: and I are a bit worried, that this code did not see that much testing since it was checked in to HEAD quite a while ago. And seeing that the backport is That sentence worries me a bit. Are you advocating developing new features in 5.x branches rather then HEAD? Not at all. I am not sure how you even read that into what I said. That code has been in HEAD for months, I so no reason not to merge it. We are in alpha phase for a reason just like this. All I said was that the fact that it has been in HEAD is no proof that there are no BC issues or even new bugs in it. Again Johannes asked for this to be merged long long long ago and nobody reacted. Now we are at alpha2, hoping to release the last alpha soon. We have plenty of other big stuff that really wants to make it out of the door. BTW: we have a similar situation for mcrypt. We have cleanups (though Derick does not define them as such) in HEAD, which have not been merged to 5.3. I dont like this at all, since either cleanups make sense or they dont. However the larger the cleanups, the messier the old code, the trickier it is to get BC just right and the less I think it makes sense to add such cleanups now. 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] [Fwd: [PATCH] Backport of HEADs output API]
On 18.09.2008, at 21:02, Michael Wallner wrote: In case the original with patches attached doesn't get through: http://dev.iworks.at/PATCHES/php53-backport_output.txt http://dev.iworks.at/PATCHES/pecl-backport_output.txt well the question is does it fix some real world bugs? this late in the game i would not want to include these changes if they just add features .. 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] true namespaces, yet another point of view
On 24.09.2008, at 01:17, Guilherme Blanco wrote: For those that do not understand very well the explanation of jvlad... He's suggesting to change the class struct to be an scope struct, and have a property that tells if it's a namespace or a class, and reuse the implementation of class which already works very well. The nested support is achieved afai understand through the Adjacency List algorithm... can you confirm this to me? or just leave the organization of things to classes (with long class names with a nice prefix to prevent collissions) and leave it to class_alias() (and equivalent features for functions .. also with the option of a compile time aliasing) to handle the aliasing. this removes the need for namespaces and use statements, while making it possible to make class/function names short (that are long for organizational and collision prevention reasons). 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] namespace issues
On 23.09.2008, at 05:39, Larry Garfield wrote: Most of the functionality could be easily achieved using static class methods. As someone who uses both functions and classes with equal comfort, I have to say GAH, NO NO NO! to that statement. Classes as pseudo- namespaces are fundamentally wrong. Conceptually they're entirely different things. I have to shut people down every time they try to suggest that in Drupal. It's not just a conceptual issue, either. For a very practical example, consider that a namespaces can be split across any number of files. A class must be all in one file. That means if you want to group functions together, they MUST all be in one single monolithic file. That makes them, sorry, useless for anything even remotely interesting. No, namespaces for functions can most certainly *not* be emulated with either variable functions or static methods. Dropping namespace support for functions makes namespaces mostly useless for anyone who is not 100% OOP. There's no reason to make functions second-class citizens (no pun intended). sure point taken on the monolithic files, when sticking different functions into classes just for the sake of them then becoming namespaceable. but how would allowing functions in namespaces solve this issue? 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] namespace issues
On 23.09.2008, at 09:47, Dmitry Stogov wrote:
Stanislav Malyshev wrote:
Hi!
On the ZendCon, we (Marcus, Elizabeth, Andi and myself) had a talk
about
what we'd like to do with namespaces, and we arrived at the following
conclusions, which we propose to implement in 5.3:
1. Allow braces for namespaces. So, the syntax for namespaces will
be:
a) namespace foo;
should be first (non-comment) statement in the file, namespace
extends
to the end of the file or next namespace declaration.
b) namespace foo {}
can appear anywhere on the top scope (can not be nested).
Mixing both syntaxes in one file is not possible. The semantics of
both
syntaxes will be identical.
2. Simplify resolution order for classes in the namespace:
unqualified
names are resolved this way:
a) check use list if the name was defined at use, follow that
resolution
b) if not, the name resolves to namespace::name
Consequence of this will be that for using internal class inside
namespace one would need to refer to it either as ::Foo or do
use ::Foo
prior to its usage.
3. Functions will not be allowed inside namespaces. We arrived to
conclusion that they are much more trouble than they're worth, and
summarily we would be better off without them. Most of the
functionality
could be easily achieved using static class methods, and the rest
may be
emulated with variable function names, etc.
Comments?
Great, lets castrate the language to make it consistent. :(
1. I am fine with (1), except for unspecified scope of use statement
inside namespace with bracket. I assume it should affect only current
declaration and not the following namespace declarations (even with
the
same name).
2. This is acceptable only if we accept (3) otherwise we will need to
write ::strlen() and so on.
3. In case we remove functions we also need to remove constants as
they
have exactly the same ambiguity problems. It's unclear for me what the
following code will define after all (global function or just emit a
parse error?)
?php
namespace foo {
function bar() {
}
}
?
Right, Stas, did you also discuss removal of constants? Seems logical
as the really the same arguments apply.
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] Adding pecl/http to core
On 23.09.2008, at 14:02, Lars Strojny wrote: Hi Michael, Am Montag, den 22.09.2008, 20:17 +0200 schrieb Michael Wallner: [...] I wonder what the general opinion is on adding pecl/http to the main PHP distribution? Many people have poked me in the past, so I guessed it's time to ask me and you that question once for all. I would like to see pecl_http in just not in 5.3. I think we are too far in the release process to do the required work to add it. And API review would be required (I didn't looked at it closely but is), general code review and so on. Of course I do not speak for our release managers, but I would say yes, but. I have not talked to Johannes about this, but unless there is a major major major outcry from the internals folks to add it, its too late for 5.3. That being said, there is some overlap in features with existing functionality. Maybe if we schedule this for PHP 6, then we might want to mark a few things as deprecated in PHP 5.3. 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] Re: Subversion migration
On 23.09.2008, at 15:08, zoe wrote: David Soria Parra wrote: As far as I know the actual conversion is done, but a lot of the CVSROOT/ scripts are not yet rewritten to fit the subversion hook system. Also Marcus proposed and I guess it was somehow accepted, that the new scripts are done in Python and not in Perl. Is there a list of what needs to be written? I have some spare time and could help, although I confess I'd prefer to write in PHP. i would agree that PHP should be the preferred language unless we could spare a lot of work with using something existing and adapting it .. but even then the goal should be to eat as much of our own dogfood for this .. seems like there is nothing that would be so heavy (or long running) to make PHP totally unfit for this. 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] Subversion migration
On 23.09.2008, at 16:05, Pierre Joye wrote: hi! For your information, there is a dedicated list: http://news.php.net/svn.migration and a dedicated IRC channel: #php.svn (EFNet) i have added this information to the wiki page: http://wiki.php.net/vcs/cvstosvnmigration 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] solving the namespace conflict issues between function/staticmethod class constant/ns constant
On 22.09.2008, at 16:37, Dmitry Stogov wrote: Returning to the original debate, if you really believe this conflict is not an issue, then why was the first user note published last December a note about this conflict? http://us3.php.net/manual/en/language.namespaces.php#80035 I could add nothing. The problem exists, but proposed solution make language even worse. Having A::B-foo() and -foo() or ::foo() and A::B-C::foo() is much more inconsistent from my point of view. It would be better to change static class separator from :: to -, but it's a BC break Again, not speaking as an RM, I personally feel we really do have to solve this ambiguity problem. I do not agree that this only affects namespace abusers. That being said we have to stay realistic. What Greg proposes is realistic imho. Its essentially reusing an existing OO syntax. The same is what we have today with the double colon. While I agree that it would not be my natural choice, it seems it solves our real problem of the frequently mentioned ambiguity problem. So from that perspetive its a step forward from the current syntax. I know we are getting dangerously close (or are we already back in it?) to the namespace separator discussion. I remember back then a lot of people were saying lets get the implementation done first and then worry about the syntax. I guess we are more or less at this point now. 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] Re: ini-parsing, double quotes, windows in 5.3
On 06.09.2008, at 11:42, Jordi Boggiano wrote: On Sat, Sep 6, 2008 at 2:15 AM, Scott MacVicar [EMAIL PROTECTED] wrote: Stanislav Malyshev wrote: No, the main argument is that it would break people's configs, and for no good reason at all (nobody really needs \n's in their paths). This code is used in parse_ini_file() where it is possible that escapes would be used legitimately, it's not all about paths. This means that not only php.ini will fail - although that is indeed easy to notice - but also any application using ini files might break in a much less obvious manner, right ? It's something that might need to be taken into account. Seems to me like we should consider delaying this fix to 6.0. I agree with Pierre that its probably not a good idea to introduce special handling here and there. As for the error handling, Pierre mentioned that Jani did some tweaks there too. Could someone explain to me what kind of error handling is out into place? If we throw a nice error message for all cases where someone is using \t, \n etc incorrectly inside a php.ini, I think it will not be such a big deal at upgrade time. But still it seems like something we might want to hold off until 6.0, considering that the bug that was fixed did not affect that many users (just a guess). 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] Making ereg extension optional ?
On 12.09.2008, at 19:16, Pierre Joye wrote: hi, On Fri, Sep 12, 2008 at 6:21 PM, Arnaud Le Blanc [EMAIL PROTECTED] wrote: Hi, PHP now builds and works without ereg, is it planed to make it optional ? It is planed to drop it so I suppose optional can be a first step. I remember something about adding a BC layer using pcre, I'm not sure if it is done yet. However I would not do it in 5.x. I think Andrei was pondering doing such a BC layer for PHP6, but I dont think this has been done yet. I think there were still discussions about if its feasible at all. This also means that there were discussions about if to even drop it, but I think we agreed on dropping it in the end, so I guess using ereg should throw an E_DEPRECATED in 5.3? I am not sure if we should make it optional in 5.3 though. 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] Making ereg extension optional ?
On 12.09.2008, at 19:16, Pierre Joye wrote: hi, On Fri, Sep 12, 2008 at 6:21 PM, Arnaud Le Blanc [EMAIL PROTECTED] wrote: Hi, PHP now builds and works without ereg, is it planed to make it optional ? It is planed to drop it so I suppose optional can be a first step. I remember something about adding a BC layer using pcre, I'm not sure if it is done yet. However I would not do it in 5.x. I think Andrei was pondering doing such a BC layer for PHP6, but I dont think this has been done yet. I think there were still discussions about if its feasible at all. This also means that there were discussions about if to even drop it, but I think we agreed on dropping it in the end, so I guess using ereg should throw an E_DEPRECATED in 5.3? I am not sure if we should make it optional in 5.3 though. 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] [PATCH] allow T_INLINE_HTML before T_NAMESPACE
On 12.09.2008, at 23:35, Greg Beaver wrote: Marcus Boerger wrote: Hello Greg, please don't OK. Nice working with you Marcus, this is high class stuff. I'm glad to see the work I'm doing is taken so seriously. Greg, as you can see several people think its better to ensure that namespace/use statements are always at the top. This is all Marcus was expressing in his german straight to the point kind of way. That being said, its awesome that you are making sure that when we are discussing namespaces, that we can talk about what behavior we want, without having to wonder if its doable or not. This is very much appreciated! 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] Re: towards a 5.3 release
On 10.09.2008, at 03:22, Stanislav Malyshev wrote: I disagree. The idea is that I get control over how I manage to global namespace. As such its sensible that I want to use mysql in my code instead of DB::mysql. You may use it. You just won't get wildcard imports, because that doesn't work conceptually. Also when it comes to resolution, inclusion order should not matter, period. if it does we have a serious flaw in our design. if we cannot We already have this serious flaw in our design. If we use new Foo(), and it's definition not included, it resolves differently (namely, to fatal error) than if we had included the definition. Also, with inheritance, if you include or define inherited classes in wrong order - i.e. child before parent - you may get problem too. You'd say this can be changed by autoloading, moving classes around, etc. - but behavior you complain about can be changed easily too, you just insist there would be no possible case, however hard you try to make a mistake, to get different resolution. All the issues you note will give you a nice error message and do not run the risk of silent misbehavior. make a performant solution in this case, we better have nothing. that I don't see how it's better to have nothing at all than a solution that works in 99% of cases - unless you try on purpose to write code that doesn't work. I also find it very strange that you and other people are so insistent on having no namespace solution at all. How that would help you? How that would make PHP better? As stated above, the key is that in 1% of the cases you could end up running totally different code than expected. This means it will be hard to debug and worse opens up an entirely new class of security issues. if some core developers have extensive experience with namespaces in Java and packages in other languages, these people have done more with this construct in PHP than many of us have. Also while I do not know all You seem to suppose neither me nor people I talked with didn't try to do things with namespaces in PHP. This is not correct. I did not say that. I said: they have all used the namespace implementation in PHP 5.3 _more_ extensively than probably all core developers notice the more and the probably .. that they are solid developers. So I think you are brushing their expectations off too lightly here. By brushing too lightly you mean spending three days in discussion, explaining repeatedly point by point each decision and each tiny point of each argument, in full detail, right? You are not discussing most points. For the most part you are saying these people are using (or trying to use) namespaces wrong. The fact that people expect that they can call a function from a namespace in a way that looks different from a static method call however is imho clearly something that needs to be addressed. One way I don't see why they have to insist on that. I think it's just misconception, making artificial differences where they do not exist. Because its important to quickly locate logic, because there is a huge difference in a function and a static method. Actually I find it quite irritating that you can even argue that its irrelevant if something a function or a static method call. This to me means you have left sound reasoning and are just being defensive. I am not convinced that you have demonstrated the mentioned used cases are really so clearly the wrong way that they should not be supported. What could convince you that something is a wrong way, theoretically? I showed that it has hight WTF factor, can lead to potential bugs, and does not add anything to functionality. So far strongest argument for them I got is I don't want :: in names. For me, don't want :: in names versus buggy unmaintainable code is clearly wrong way. But some think otherwise, that's their right. No, people asked to be able to: - shorten class/function calls - be able to differentiate calls to namespaced functions vs. static method calls This has nothing to do with people not liking double colons. I think that PHP is not an OO language and as such there is no reason to Namespaces is an OO feature, however. It is only natural that if you don't want to touch OO, you get no namespaces. PHP has tons of features that make sense only if you use OO, that's one more of them. I disagree. There is nothing OO only about namespaces conceptually. 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] Re: 5.3 Backwards Compatibility
On 10.09.2008, at 09:13, Lester Caine wrote: Lukas Kahwe Smith wrote: Hi, So let me get this straight, you are complaining that all the new features and changes in the 5.3.0 alpha releases are not perfectly documented yet? PLEASE re-read the original post. If my comments and QUESTIONS are taken as complaints then OK. That is not what was intended. I am pretty sure I read that you complained that information is scattered or unavailable. If I misunderstood you I am sorry. The 'complaint' that I have is that the changes being introduced DO seem to be bringing in problems which when corrected for 5.3 then cause other problems for previous versions of PHP. As an example, the bitweaver framework currently runs out of the box on PHP4 and PHP5. RUNNING it on PHP5.3 gives various warnings and errors that handling for 5.3 then messes up previous versions although WHEN migration is documented there may be options provided that solve those problems? ( And PEAR comes into this equation since potentially we may have to take care of pre and post 5.3 situations? ) Hanging fixes through the code with 'version selects' has not been necessary much up to now but 5.3 seems to be heading that way? We are currently working through the bitweaver 2.1 testing, on 5.2.6 and below so have not yet had time to do any more than checking the code runs on 5.3. The list of things to be looked at on 5.3 was growing so has had to be shelved until the next bitweaver release is out. One has to allocate time productively and BW is currently paying the mortgage for me! Obviously the goal is to minimize BC issues as much as possible. Actually there has to be really sound reason to break BC. So whenever you discover a BC issue that is not noted on the scratchpad please make us aware of this by opening a bug report or by sending a mail to this list. regards, Lukas Kahwe Smith [EMAIL PROTECTED] -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
