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: file 2: 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: 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
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
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] [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
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] 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] [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 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 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 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 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 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. -- 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]
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 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
[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 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
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] 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
[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] 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): 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
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=ZEND002498&r=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] [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] 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
[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] 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" -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
