Re: [PHP-DEV] PHP 5.3 Windows builds, pdo_sqlite
Using the non-VC9 nts build (and after erasing sqlite files so they get created from scratch) I can have PDO sqlite create a table, and add records, but not delete records (SQLSTATE[HY000]: General error: 1 SQL logic error or missing database). Reverting to 5.2.x works again. We use a cache layer that can switch between APC, memcached, and sqlite depending on what we are trying to cache. Locally though, APC is not available for these PHP builds, and i don't have memcached running, so I have to use sqlite. Which is not working. So I'm zero for three and can't test much else. When is alpha 3? On Wed, Sep 10, 2008 at 7:33 AM, Daniel Henning [EMAIL PROTECTED] wrote: Hi lists, there is a Problem with pdo_sqlite in PHP 5.3. (downloaded half an hour ago from snaps) I've sent a report here : http://pecl.php.net/bugs/bug.php?id=14098 Anyway php_pdo_sqlite_external doesn't have this problem but isn't available in 5.3 windows-builds anymore. Is it possible to activate this extension by default since it is the same source like normal pdo_sqlite? kind regards, Daniel -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] namespace issues
Arvids Godjuks wrote: 2008/9/22 Stanislav Malyshev [EMAIL PROTECTED] Hi! 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? -- Stanislav Malyshev, Zend Software Architect [EMAIL PROTECTED] http://www.zend.com/ (408)253-8829 MSN: [EMAIL PROTECTED] -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php That means, that if I have a tiny, 70-100 line script and I use a package in a namespace with some global functionality - it should be 100% OOP? Sorry, but that's OOP for the sake of OOP. It's like writing Hello world! using patterns (here is an example: http://www.phppatterns.com/docs/design/hello_world_in_patterns) -1 on this. my god that's basically a PHP version of the Java Hello World weg -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] Namespace Question - Simple
Hi All, Can anybody answer the following question for me please. Why not follow (exactly) Java's strong static package/namespace system rather than a home grown dynamic namespace system? It works, it's common, logical, robust, a working model to follow, and ties in well with the PHP on Java movement. Regards, Nathan -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Re: Adding pecl/http to core
Jani Taskinen wrote: So pecl/http is actually ext/curl with OO API? Not really. libcurl is not HTTP only, pecl/http utilizes libcurl for it's HTTP request functionality. pecl/http also provides much improved HTTP response and zlib functionality besides an swizz-army-knife for URLs. Why not merge the two then..? Or rather, replace ext/curl with pecl/http once latter has BC API for us non-oo folks out there.. You don't have to write OO code to use pecl/http, neither do you have the possibility to query any protocol other than HTTP with pecl/http. Regards, Mike -- 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]
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... ;) 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 Regards, Mike -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Namespace Question - Simple
2008/9/26 Nathan Rixham [EMAIL PROTECTED]: Hi All, Can anybody answer the following question for me please. Why not follow (exactly) Java's strong static package/namespace system rather than a home grown dynamic namespace system? It works, it's common, logical, robust, a working model to follow, and ties in well with the PHP on Java movement. Regards, Nathan -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php From what I understand, JAVA is compiled and PHP isn't. PHP can include namespaces/classes/etc. at run time. Whereas everything has to be known upfront. -- - Richard Quadling Zend Certified Engineer : http://zend.com/zce.php?c=ZEND002498r=213474731 Standing on the shoulders of some very clever giants! -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Namespace Question - Simple
Richard Quadling wrote:
2008/9/26 Nathan Rixham [EMAIL PROTECTED]:
Hi All,
Can anybody answer the following question for me please.
Why not follow (exactly) Java's strong static package/namespace system
rather than a home grown dynamic namespace system?
It works, it's common, logical, robust, a working model to follow, and ties
in well with the PHP on Java movement.
Regards,
Nathan
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
From what I understand, JAVA is compiled and PHP isn't. PHP can
include namespaces/classes/etc. at run time. Whereas everything has to
be known upfront.
Richard Quadling wrote:
2008/9/26 Nathan Rixham [EMAIL PROTECTED]:
Hi All,
Can anybody answer the following question for me please.
Why not follow (exactly) Java's strong static package/namespace system
rather than a home grown dynamic namespace system?
It works, it's common, logical, robust, a working model to follow,
and ties
in well with the PHP on Java movement.
Regards,
Nathan
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
From what I understand, JAVA is compiled and PHP isn't. PHP can
include namespaces/classes/etc. at run time. Whereas everything has to
be known upfront.
Thanks Richard, but you know what.. I asked completely the wrong
question (it would appear I as everybody else, has very strong feelings
on this); the problem/niggle here is that namespaces do not help me as a
developer in the way they should; they're a bastardisation of namespaces
to allow people to either - in fact I'm going to stop the ranting as
it's pointless.
Here's what *I* /as an OO developer/ need(?want):
?php
package com.mydom.thispackage
{
import com.anotherdom.MysqlDbHandler as DbHandlerA;
import com.somedom.DbHandler as DbHandlerB; # as makes this easier
import com.mydom.thatpackage.RssParser; # we don't have to as
import net.php.pecl.Tidy into TidySpace; # into namespace
import org.nicedom.alwaysusethese.*; # why not?
public class MyClass # visibility on classes
{
private $dba:DbHandlerA = new DbHandlerA();
private $dbb:DbHandlerB = new DbHandlerB();
protected $xmlString:String;
public function __construct( String $xml ):void #return types
{
if( TidySpace::tidy_is_xml( $xml ) ) { #namespace function call
$this-xmlString = TidySpace::tidy_repair_string( $xml );
}
}
}
}
?
think that handle's everything; encourages a fixed file hierarchy for
classes as well which would save so many headaches; additionally allows
for import instead of the pesky include/require or auto-loading.
*sorry*
php dev's if you can do the above I'll be your best friends forever.
ps: Yep I know I can avoid namespaces if I want (but can't really when
other packages I'm using haven't avoided them..) - namespaces address a
problem, which is there, and thus needs a solution, so will have to use
them :)
Regards Great Work!
Nathan
(bows out)
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] ext/soap and http header
Hi,
Currently there isn't a way to add http headers into a soap
request. Below is a patch to get headers from the passed in context
(code taken from ext/standard/http_fopen_wrapper.c). Doing something
like this:
$opts = array('http' = array('header' = 'X-foo: bar'));
$ctx = stream_context_create($opts);
and then passing $ctx into the SoapClient constructor. This is a
simple patch as it assumes the user isn't going to duplicate items
like content-type, user-agent or other headers already set by the soap
client code.
This patch is based on 5.2.5, it could easily be ported to HEAD/5_3/5_2.
Thoughts?
Thanks,
Brian
-
--- ext/soap/php_http.c.orig2008-09-26 05:39:50.0 -0700
+++ ext/soap/php_http.c 2008-09-26 05:54:15.0 -0700
@@ -391,7 +391,8 @@
PG(allow_url_fopen) = old_allow_url_fopen;
if (stream) {
- zval **cookies, **login, **password;
+ php_stream_context *context = NULL;
+ zval **cookies, **login, **password, **tmpzval = NULL;
int ret = zend_list_insert(phpurl, le_url);
add_property_resource(this_ptr, httpurl, ret);
@@ -638,6 +639,23 @@
proxy_authentication(this_ptr, soap_headers TSRMLS_CC);
}
+ /* get context to check for http headers */
+ if (SUCCESS == zend_hash_find(Z_OBJPROP_P(this_ptr),
+ _stream_context, sizeof(_stream_context),
(void**)tmp)) {
+ context = php_stream_context_from_zval(*tmp, 0);
+ }
+
+ /* Send http headers from context */
+ if (context
+ php_stream_context_get_option(context, http, header,
tmpzval) == SUCCESS
+ Z_TYPE_PP(tmpzval) == IS_STRING Z_STRLEN_PP(tmpzval)) {
+ char *tmp = php_trim(Z_STRVAL_PP(tmpzval),
Z_STRLEN_PP(tmpzval), NULL, 0, NULL, 3 TSRMLS_CC);
+ int len = strlen(tmp);
+ if (len 0) {
+ smart_str_appendl(soap_headers, tmp, len);
+ }
+ }
+
/* Send cookies along with request */
if (zend_hash_find(Z_OBJPROP_P(this_ptr), _cookies,
sizeof(_cookies), (void **)cookies) == SUCCESS) {
zval **data;
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] ext/soap and http header
After some more testing I needed to tweak the patch and the example,
here is version 2.
$opts = array('http' = array('header' = 'X-foo: bar'));
$ctx = stream_context_create($opts);
Brian
--- ext/soap/php_http.c.orig2008-09-26 05:39:50.0 -0700
+++ ext/soap/php_http.c 2008-09-26 06:42:34.0 -0700
-391,7 +391,8 @@
PG(allow_url_fopen) = old_allow_url_fopen;
if (stream) {
- zval **cookies, **login, **password;
+ php_stream_context *context = NULL;
+ zval **cookies, **login, **password, **tmpzval = NULL;
int ret = zend_list_insert(phpurl, le_url);
add_property_resource(this_ptr, httpurl, ret);
-638,6 +639,19 @@
proxy_authentication(this_ptr, soap_headers TSRMLS_CC);
}
+ /* get context to check for http headers */
+ if (SUCCESS == zend_hash_find(Z_OBJPROP_P(this_ptr),
+ _stream_context, sizeof(_stream_context),
(void**)tmp)) {
+ context = php_stream_context_from_zval(*tmp, 0);
+ }
+
+ /* Send http headers from context */
+ if (context
+ php_stream_context_get_option(context, http, header,
tmpzval) == SUCCESS
+ Z_TYPE_PP(tmpzval) == IS_STRING Z_STRLEN_PP(tmpzval)) {
+ smart_str_appendl(soap_headers, Z_STRVAL_PP(tmpzval),
Z_STRLEN_PP(tmpzval));
+ }
+
/* Send cookies along with request */
if (zend_hash_find(Z_OBJPROP_P(this_ptr), _cookies,
sizeof(_cookies), (void **)cookies) == SUCCESS) {
zval **data;
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] namespace issues
Hi,
On Mon, 2008-09-22 at 12:45 -0700, Stanislav Malyshev wrote:
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.
I'm fine with that, personally I'd like having only the {}-Syntax but as
many people want both, well, ...
For future times (6.0) we might think about adding nesting support - if
we get it working good with the engine, but no show-stopper, we're
delayed enough...
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.
That will hurt a bit when working with DOM for example, but still +1.
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.
That's fine, I'm not sure about constants, neither one way nor the
other, but in general I see some support for dropping them.
johannes
--
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 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 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. Cheers, -- Pierre http://blog.thepimp.net | http://www.libgd.org -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [Fwd: [PATCH] Backport of HEADs output API]
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. You're releasing alphas still, so something like this is not really that bad.. --Jani -- 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 Fri, Sep 26, 2008 at 3:59 PM, Pierre Joye [EMAIL PROTECTED] wrote: I strongly disagree, for two reasons: 1. We are going to release an alpha3, that's the perfect time for such change 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. I've just been reading the thread as it's gone along and not contributing, but I'd like to add that I'm +1 with Pierre here. -- /Daniel P. Brown More full-root dedicated server packages: Intel 2.4GHz/60GB/512MB/2TB $49.99/mo. Intel 3.06GHz/80GB/1GB/2TB $59.99/mo. Intel 2.4GHz/320/GB/1GB/3TB $74.99/mo. Dedicated servers, VPS, and hosting from $2.50/mo. -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [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 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? 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. -Hannes -- 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 Fri, Sep 26, 2008 at 22:05, Lukas Kahwe Smith [EMAIL PROTECTED] wrote: 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? It does contain at least one bug fix (see HEAD NEWS) and many obscure bugs that have probably been bogusfied in the past. -Hannes -- 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] alpha3
Hey Lukas, Johannes, all... 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 :) Does that mean we can drop namespace support until 6.0? Please? Rationale: 1) It's uber-contentious, and all the good stuff's only just starting to turn up that would allow sane design decisions 2) If it's released as-is, there would be no going back due to BC concerns Simple as. I'm just worried about it all, and 5.3 should've been out months ago because it's otherwise brilliant. - Steph -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] alpha3
Hi! Does that mean we can drop namespace support until 6.0? Please? Rationale: 1) It's uber-contentious, and all the good stuff's only just starting to turn up that would allow sane design decisions I don't know what uber-contentios means, but no solution is going to satisfy 100% of people. The solution we have now is good for many uses, even if not for 100% of them, and delaying this much needed feature because of couple of vocal people of the list is just insane. 2) If it's released as-is, there would be no going back due to BC concerns Going back to what? To endless discussions about separator characters? No, we are not, and good riddance. Imperfect solution is much better than perpetual absence of any solution. -- Stanislav Malyshev, Zend Software Architect [EMAIL PROTECTED] http://www.zend.com/ (408)253-8829 MSN: [EMAIL PROTECTED] -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [Fwd: [PATCH] Backport of HEADs output API]
It does contain at least one bug fix (see HEAD NEWS) and many obscure
bugs that have probably been bogusfied in the past.
I'm mouthy tonight. But I should say two things ('cos that's what I do
best):
1) Mike's version of output buffering has been sitting in HEAD for a very
long time
2) He wrote it because he saw problems with the existing solution
the only issue is of course:
3) has it been tested enough to justify making it mainstream PHP?
- Steph
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] alpha3
Oh Stas, we have to fall out now! Imperfect solution is much better than perpetual absence of any solution. See, I'm not sure I agree with that. I think 'imperfect but basic solution that can be expanded on' would be a better approach than trying to do it all in one hit. And I still think putting it off to PHP 6 would be a smart move. It's the major thing that's holding up 5.3. - Steph -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] alpha3
Hi! And I still think putting it off to PHP 6 would be a smart move. It's the major thing that's holding up 5.3. Nothing is holding anything. Lukas has release schedule, and namespace implementation will fit it. -- Stanislav Malyshev, Zend Software Architect [EMAIL PROTECTED] http://www.zend.com/ (408)253-8829 MSN: [EMAIL PROTECTED] -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] alpha3
Steph Fox wrote:
Oh Stas, we have to fall out now!
Imperfect solution is much better than perpetual absence of any solution.
See, I'm not sure I agree with that.
I think 'imperfect but basic solution that can be expanded on' would be
a better approach than trying to do it all in one hit.
And I still think putting it off to PHP 6 would be a smart move. It's
the major thing that's holding up 5.3.
Hi,
I have to respectfully disagree with both of you:
Stas: choosing an imperfect solution when a better one already exists is
just plain stupid, and isn't what you want *or* what you suggested - the
solution you, Liz, Marcus and Andi proposed is not imperfect, it is
consistent, robust and far better than the existing CVS implementation
of namespaces. Don't sell yourself so short! :)
Steph: the limited solution proposed by Stas and company (removing
functions [and I would add constants]/fixing name resolution) *is* a
basic solution that can be expanded on. I outlined the steps in my
reply. It's the best solution to the problem, not an imperfect one. A
namespace solution that works brilliantly for classes will satisfy at
least 2/3 of the users who want it.
Adding support for functions, constants and even variables is actually
quite do-able with the solution I suggested (different separator between
namespace name and function/constant/variable name) and can be added easily.
file 1:
?php
namespace foo::bar;
class myclass {}
function myfunc()(}
var $myvar;
const myconst = 1;
?
file 2:
?php
include 'file1.php';
$a = new foo::bar::myclass;
foo::bar:myfunc; // separator : could be anything
echo foo::bar:$myvar;
echo foo::bar:myconst;
// all of the below would also be possible, although we may choose not
to implement things like use of a variable
use foo::bar::myclass, foo::bar:$myvar, foo::bar:myfunc(),
foo::bar:myconst, foo::bar;
?
So the question of whether we are making a mistake with Stas's
suggestion relayed from ZendCon is debunked by 2 facts:
1) the implementation is a reduced set based on the existing namespace
implementation which has been beaten up and tested thoroughly, and
because it is simpler, will be even easier to verify its veracity.
2) it can be easily extended to add support later for other components
like functions, while preserving 100% BC with the current::implementation.
There is also jvlad's suggestion to consider, but in my opinion, this
trades one conflict for another, as this code would be a fatal error:
?php
namespace http;
class Request {}
namespace http::request; // fatal error - name conflict between class
http::request and namespace http::request
class body {}
?
Unless we also used my suggestion of having a namespace member separator
different from scope resolution operator.
In addition, Rasmus has pointed out many times in the past that allowing
changing the namespace of external code depending on code load order
would simply break opcode caching for PHP.
Greg
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
