[PHP-DEV] CVS Account Request: wharmby
Maintaining the COM extension. Andi Gutmans suggested I apply for access. -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Runtime-JIT, the whole enchilada
Hello Andrei, On 1/27/07, Andrei Zmievski [EMAIL PROTECTED] wrote: Good luck trying to retrain millions of programmers to use a CGI object or a function to retrieve GPC values. You will be surprised, really :) Really, how much of a performance hit is Sara's patch going to be, compared to other things in PHP 6? It is to early to argue about performance problems in my humble opinion. My point was more about the complexity. That's why I prefer the other solution which simply moves the JIT to runtime without other changes but a function to get the encoding error. To be honest, I do not understand the resistance to commit experimental code in head. For what really matters, we need a working solution. It does not need to be perfert, it needs to work (more or less). We still have plenty of time to improve it until 6 is out (not going to happen in the next months anyway). --Pierre -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] CVS Account Request: wharmby
On 1/27/07, andy wharmby [EMAIL PROTECTED] wrote: Maintaining the COM extension. Andi Gutmans suggested I apply for access. And if there is any need to confirm this request, please check Andy's nice work on the existing bug and his recent patch sent to the list. COM needs some love :) --Pierre -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
RE: [PHP-DEV] Runtime-JIT, the whole enchilada
-Original Message- From: Pierre [mailto:[EMAIL PROTECTED] Sent: Saturday, January 27, 2007 2:16 PM To: Andrei Zmievski Cc: Dmitry Stogov; Sara Golemon; internals@lists.php.net; Andi Gutmans; Zeev Suraski; Stanislav Malyshev Subject: Re: [PHP-DEV] Runtime-JIT, the whole enchilada Hello Andrei, On 1/27/07, Andrei Zmievski [EMAIL PROTECTED] wrote: Good luck trying to retrain millions of programmers to use a CGI object or a function to retrieve GPC values. You will be surprised, really :) Really, how much of a performance hit is Sara's patch going to be, compared to other things in PHP 6? It is to early to argue about performance problems in my humble opinion. My point was more about the complexity. Agree 100%. The slowdown is not large (may be 1%), but internal dependencies are to complex. This solution may be similar to indirect modification of overloaded properties or return by reference, then mistakes give hundreds of bug reports and takes years for completely fix. That's why I prefer the other solution which simply moves the JIT to runtime without other changes but a function to get the encoding error. To be honest, I do not understand the resistance to commit experimental code in head. For what really matters, we need a working solution. It does not need to be perfert, it needs to work (more or less). We still have plenty of time to improve it until 6 is out (not going to happen in the next months anyway). I cannot restrict commits, I only tell my opinion. If the patch will be fixed for opcode caches, and most of developers will vote for it, it can go. Dmitry. -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Runtime-JIT, the whole enchilada
On 1/27/07, Dmitry Stogov [EMAIL PROTECTED] wrote: -Original Message- From: Pierre [mailto:[EMAIL PROTECTED] Sent: Saturday, January 27, 2007 2:16 PM To: Andrei Zmievski Cc: Dmitry Stogov; Sara Golemon; internals@lists.php.net; Andi Gutmans; Zeev Suraski; Stanislav Malyshev Subject: Re: [PHP-DEV] Runtime-JIT, the whole enchilada Hello Andrei, On 1/27/07, Andrei Zmievski [EMAIL PROTECTED] wrote: Good luck trying to retrain millions of programmers to use a CGI object or a function to retrieve GPC values. You will be surprised, really :) Really, how much of a performance hit is Sara's patch going to be, compared to other things in PHP 6? It is to early to argue about performance problems in my humble opinion. My point was more about the complexity. Agree 100%. The slowdown is not large (may be 1%), but internal dependencies are to complex. This solution may be similar to indirect modification of overloaded properties or return by reference, then mistakes give hundreds of bug reports and takes years for completely fix. That's why I prefer the other solution which simply moves the JIT to runtime without other changes but a function to get the encoding error. To be honest, I do not understand the resistance to commit experimental code in head. For what really matters, we need a working solution. It does not need to be perfert, it needs to work (more or less). We still have plenty of time to improve it until 6 is out (not going to happen in the next months anyway). I cannot restrict commits, I only tell my opinion. If the patch will be fixed for opcode caches, and most of developers will vote for it, it can go. Oh! It was not a +1 from me for this patch, I still prefer my simpler solution (which has to be written ;). However, as a temporary/test code Sara's patch can do it for now no? -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] Improving the documentation
Hello internals, I've been helping with PHP documentation for 4 years now, and I still can't help the fact that a lt of things are not documented, that our/my way of handling the PHP documentation update is not accurate, nor productive, nor bug free at all. Personally, I try to follow commits on php.cvs, bug reports, Change Log?, user notes on the online manual.. but I still have the feeling of missing a lot of changes. After a year away from the project, I have _no_ clue what was added, when, and whether it was added to our documentation or not. I know that you developers are willing to help a lot with it, but that you cannot manage to save the spare time needed to do it the right way. That's why I would like to propose a simple/small/timeless change in your CVS commit messages: If you feel that the change need to be documented, place the @doc keyword at the end of your message log entry. And if you feel like telling us more about what you changed, point us to some online resource or whatever. Simply add that after the @doc tag. This additional comment is optional, and you don't need to bother if the change is obvious, or if you simply don't feel like doing it ATM. This small @doc tag could _slightly_ improve/optimize/sanitize our work on the documentation. By adding some SQL logging in loginfo.pl, and storing the following: * date: commit date * login: CVS account of the developer * branch: CVS branch * files: Changed files * commit: Commit message before @doc * desc : Optional developer description after @doc We would be able to have an interface displaying a dynamic phpdoc TODO, with some nice features like a search by PHP version, extension, assignee, keywords.. Additionally, we can imagine adding an online help feature on the interface, by setting a “help” flag on some hardly understandable change, to have [EMAIL PROTECTED] notified of our need for enlightenment. Any thoughts ? Mehdi Achour -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
RE: [PHP-DEV] Autoglobal CVs without silence -- Summary
Hi Sara, I don't feel to great with this patch. It kind of feels like twisting the language implementation around for some very specific problem which probably shouldn't be fixed at this level. Andrei says performance of Unicode isn't great so it shouldn't matter too much, but I think a) it's not only about performance but also about maintainability. The code in PHP 6 is already much more complex than that of PHP 5 and has become much harder to maintain. Such additional changes will make it worse b) There will still be plenty of people who use PHP 6 in PHP 5 mode. I still haven't quite understood why not just do the detection on the whole auto-global when it's being fetched (or even during request startup). As Andrei said, it's slow anyway so for people who need Unicode that should be an affordable hit. Maybe I don't understand the problem in enough detail and it might make sense for me to talk to Andrei via voice directly, but I really don't think we should be over eager commiting this patch. It'll not be good for the engine long term (not that I don't appreciate your efforts and hard work on this patch). Andi -Original Message- From: Sara Golemon [mailto:[EMAIL PROTECTED] Sent: Tuesday, January 23, 2007 11:02 AM To: internals@lists.php.net; Andrei Zmievski; Andi Gutmans; Dmitry Stogov Subject: [PHP-DEV] Autoglobal CVs without silence -- Summary OK. Now your patch will work, but I would like to think about more elegant solution. The problem that I am busy with other work. Could you please wait a week and then commit it if I won't return (on the next Tuesday). Argh. Can we please accelerate this somehow? This patch is necessary for the HTTP request decoding work in PHP 6 and we really should get it done sooner than later. Okay, rewind and reset time. Dmitry, here's a quick summary of what's being done, how, and why. Initial Problem: PHP6 needs better http input encoding detection, preferably with minimal wasted effort in conversion and limited vectors for conversion failure based attacks. Proposed Solution: Wait until the first time a given input argument is requested before actually converting it. This allows scripts to perform their own (potentially more relevant) determination of what the correct input encoding is. Proposed Implementation for this solution: Make JIT be runtime based and fine-grained enough to signal not just the autoglobal being fetched, but what specific dimension/property within that auto global is being requested. Using runtime-dimension-JIT to decode input arguments as they are requested. Rejected Implementation: Use object/array-access overloading to JIT the values instead. While this solution is the simplest and can be done with relatively few LOCs, it breaks assumptions about the GPC auto globals (is_array() fails, is_object() succeeds, assignments of the autoglobals becomes reference-like*). In short, this solution introduces BC issues. Next Problem: How to actually make runtime-JIT with dim/prop level granularity? Proposed Solution: Catch fetches during FETCH_DIM/FETCH_OBJ execution handlers. Next Problem: auto_globals aren't processed as CVs, meaning that during FETCH_DIM, there's no way to tell if op1 came from an auto global or not (since the fetch happened earlier). Solution (Implemented last week): Remove restriction on CVing auto globals by adding a fetch_type field to auto global structure. Next Problem: Silence operator forces non-CV even in situations where a CV is appropriate since the associated fetch_dim/obj op would not fall outside of silence scoping. Proposed Solution (patch from prior email): modify the variable parsing routines slightly to rewrite simple fetch ops to CV'd fetch_dim/obj ops when appropriate. I'm not meaning to apply pressure (a week doesn't effect my timetable any), I can even move-forward with the next (and last) ZE related patch (FETCH_DIM/FETCH_OBJ handling) separate from this one. I'm just trying to balance Andrei's timetable on one side, with a desired to not overwhelm you and Andi with ZE patches on the other. Hopefully this summary helps everyone get on the same page. -Sara * - Sidenote: I refuse to call object behavior reference by default, I've had too many people notice that it's not actually true and expect me to explain why in 2 minutes without the aid of a whiteboard.in -- 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:
RE: [PHP-DEV] Autoglobal CVs without silence -- Summary
Btw, for people who truly need the Unicode support I actually do think we might want to consider requiring them to fetch the input variables through a new API and/or object. I don't think we need to make it seamless if the default behavior we provide (whatever that ends up being) isn't good enough... Andi -Original Message- From: Andi Gutmans [mailto:[EMAIL PROTECTED] Sent: Saturday, January 27, 2007 9:15 AM To: 'Sara Golemon'; 'internals@lists.php.net'; 'Andrei Zmievski'; 'Dmitry Stogov' Subject: RE: [PHP-DEV] Autoglobal CVs without silence -- Summary Hi Sara, I don't feel to great with this patch. It kind of feels like twisting the language implementation around for some very specific problem which probably shouldn't be fixed at this level. Andrei says performance of Unicode isn't great so it shouldn't matter too much, but I think a) it's not only about performance but also about maintainability. The code in PHP 6 is already much more complex than that of PHP 5 and has become much harder to maintain. Such additional changes will make it worse b) There will still be plenty of people who use PHP 6 in PHP 5 mode. I still haven't quite understood why not just do the detection on the whole auto-global when it's being fetched (or even during request startup). As Andrei said, it's slow anyway so for people who need Unicode that should be an affordable hit. Maybe I don't understand the problem in enough detail and it might make sense for me to talk to Andrei via voice directly, but I really don't think we should be over eager commiting this patch. It'll not be good for the engine long term (not that I don't appreciate your efforts and hard work on this patch). Andi -Original Message- From: Sara Golemon [mailto:[EMAIL PROTECTED] Sent: Tuesday, January 23, 2007 11:02 AM To: internals@lists.php.net; Andrei Zmievski; Andi Gutmans; Dmitry Stogov Subject: [PHP-DEV] Autoglobal CVs without silence -- Summary OK. Now your patch will work, but I would like to think about more elegant solution. The problem that I am busy with other work. Could you please wait a week and then commit it if I won't return (on the next Tuesday). Argh. Can we please accelerate this somehow? This patch is necessary for the HTTP request decoding work in PHP 6 and we really should get it done sooner than later. Okay, rewind and reset time. Dmitry, here's a quick summary of what's being done, how, and why. Initial Problem: PHP6 needs better http input encoding detection, preferably with minimal wasted effort in conversion and limited vectors for conversion failure based attacks. Proposed Solution: Wait until the first time a given input argument is requested before actually converting it. This allows scripts to perform their own (potentially more relevant) determination of what the correct input encoding is. Proposed Implementation for this solution: Make JIT be runtime based and fine-grained enough to signal not just the autoglobal being fetched, but what specific dimension/property within that auto global is being requested. Using runtime-dimension-JIT to decode input arguments as they are requested. Rejected Implementation: Use object/array-access overloading to JIT the values instead. While this solution is the simplest and can be done with relatively few LOCs, it breaks assumptions about the GPC auto globals (is_array() fails, is_object() succeeds, assignments of the autoglobals becomes reference-like*). In short, this solution introduces BC issues. Next Problem: How to actually make runtime-JIT with dim/prop level granularity? Proposed Solution: Catch fetches during FETCH_DIM/FETCH_OBJ execution handlers. Next Problem: auto_globals aren't processed as CVs, meaning that during FETCH_DIM, there's no way to tell if op1 came from an auto global or not (since the fetch happened earlier). Solution (Implemented last week): Remove restriction on CVing auto globals by adding a fetch_type field to auto global structure. Next Problem: Silence operator forces non-CV even in situations where a CV is appropriate since the associated fetch_dim/obj op would not fall outside of silence scoping. Proposed Solution (patch from prior email): modify the variable parsing routines slightly to rewrite simple fetch ops to CV'd fetch_dim/obj ops when appropriate. I'm not meaning to apply pressure (a week doesn't effect my timetable any), I can even move-forward with the next (and last) ZE related patch
RE: [PHP-DEV] Runtime-JIT, the whole enchilada
Btw, having a request object was one of the #1 requests in framework :) People actually really like encapsulating this because it also makes unit testing easier down the road... Just mentioning this because I don't think we should be too set with our ways esp. for people who need to accomplish more functionality. Andi -Original Message- From: Pierre [mailto:[EMAIL PROTECTED] Sent: Saturday, January 27, 2007 3:16 AM To: Andrei Zmievski Cc: Dmitry Stogov; Sara Golemon; internals@lists.php.net; Andi Gutmans; Zeev Suraski; Stanislav Malyshev Subject: Re: [PHP-DEV] Runtime-JIT, the whole enchilada Hello Andrei, On 1/27/07, Andrei Zmievski [EMAIL PROTECTED] wrote: Good luck trying to retrain millions of programmers to use a CGI object or a function to retrieve GPC values. You will be surprised, really :) Really, how much of a performance hit is Sara's patch going to be, compared to other things in PHP 6? It is to early to argue about performance problems in my humble opinion. My point was more about the complexity. That's why I prefer the other solution which simply moves the JIT to runtime without other changes but a function to get the encoding error. To be honest, I do not understand the resistance to commit experimental code in head. For what really matters, we need a working solution. It does not need to be perfert, it needs to work (more or less). We still have plenty of time to improve it until 6 is out (not going to happen in the next months anyway). --Pierre -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
RE: [PHP-DEV] Runtime-JIT, the whole enchilada
Sorry for the spam (I'm a bit behind). I agree 100% with Dmitry. Guys (n'girls), I don't know if you've realized but the engine has become much involved. We've added a lot of new features in PHP 5 and beyond, Unicode has muliplied that by 2, we added some performance features and we've just more or less managed to solve some of the ugly issues with return by reference and overloaded properties. I think we need to move into a state of mind now that adding additional implementation complexity is a last and not a first resort. Otherwise it'll end up being impossible to maintain all the interdependencies. I said the same with past features during PHP 5 where I warned that they might introduce bugs in other areas but it's hard to forsee. No one believed me because I couldn't give a concrete enough example and we had quite a few of those bugs afterwards. As some point the platform has to be the one that grows and not the language. So if we need to evolve it to have a different way of fetching input variables that's what we should do. You don't see other languages change every day because of a higher level requirement. And have no doubt, PHP 6 will take a long time to truly stabilize and make consistent because there've been huge changes. Andi -Original Message- From: Dmitry Stogov [mailto:[EMAIL PROTECTED] Sent: Saturday, January 27, 2007 3:51 AM To: 'Pierre'; 'Andrei Zmievski' Cc: 'Sara Golemon'; internals@lists.php.net; 'Andi Gutmans'; 'Zeev Suraski'; 'Stanislav Malyshev' Subject: RE: [PHP-DEV] Runtime-JIT, the whole enchilada -Original Message- From: Pierre [mailto:[EMAIL PROTECTED] Sent: Saturday, January 27, 2007 2:16 PM To: Andrei Zmievski Cc: Dmitry Stogov; Sara Golemon; internals@lists.php.net; Andi Gutmans; Zeev Suraski; Stanislav Malyshev Subject: Re: [PHP-DEV] Runtime-JIT, the whole enchilada Hello Andrei, On 1/27/07, Andrei Zmievski [EMAIL PROTECTED] wrote: Good luck trying to retrain millions of programmers to use a CGI object or a function to retrieve GPC values. You will be surprised, really :) Really, how much of a performance hit is Sara's patch going to be, compared to other things in PHP 6? It is to early to argue about performance problems in my humble opinion. My point was more about the complexity. Agree 100%. The slowdown is not large (may be 1%), but internal dependencies are to complex. This solution may be similar to indirect modification of overloaded properties or return by reference, then mistakes give hundreds of bug reports and takes years for completely fix. That's why I prefer the other solution which simply moves the JIT to runtime without other changes but a function to get the encoding error. To be honest, I do not understand the resistance to commit experimental code in head. For what really matters, we need a working solution. It does not need to be perfert, it needs to work (more or less). We still have plenty of time to improve it until 6 is out (not going to happen in the next months anyway). I cannot restrict commits, I only tell my opinion. If the patch will be fixed for opcode caches, and most of developers will vote for it, it can go. Dmitry. -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] [PATCH] fix zend_llist_remove_tail
The attached patch fixes zend_llist_remove_tail() which didn't reset
zend_llist-head properly.
The diff was generated against 5_2.
Regards,
--
Michael
Index: Zend/zend_llist.c
===
RCS file: /repository/ZendEngine2/zend_llist.c,v
retrieving revision 1.35.2.1.2.1
diff -u -p -d -r1.35.2.1.2.1 zend_llist.c
--- Zend/zend_llist.c 1 Jan 2007 09:35:46 - 1.35.2.1.2.1
+++ Zend/zend_llist.c 27 Jan 2007 17:31:36 -
@@ -130,28 +130,17 @@ ZEND_API void zend_llist_clean(zend_llis
ZEND_API void *zend_llist_remove_tail(zend_llist *l)
{
- zend_llist_element *old_tail;
+ zend_llist_element *current = l-tail;
void *data;
-
- if ((old_tail = l-tail)) {
- if (l-tail-prev) {
- l-tail-prev-next = NULL;
- }
-
- data = old_tail-data;
-
- l-tail = l-tail-prev;
- if (l-dtor) {
- l-dtor(data);
- }
- pefree(old_tail, l-persistent);
-
- --l-count;
-
- return data;
+
+ if (current) {
+ data = current-data;
+ DEL_LLIST_ELEMENT(current, l);
+ } else {
+ data = NULL;
}
-
- return NULL;
+
+ return data;
}
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Autoglobal CVs without silence -- Summary
On Jan 27, 2007, at 9:15 AM, Andi Gutmans wrote: Hi Sara, I don't feel to great with this patch. It kind of feels like twisting the language implementation around for some very specific problem which probably shouldn't be fixed at this level. Andrei says performance of Unicode isn't great so it shouldn't matter too much, but I think a) it's not only about performance but also about maintainability. The code in PHP 6 is already much more complex than that of PHP 5 and has become much harder to maintain. Such additional changes will make it worse b) There will still be plenty of people who use PHP 6 in PHP 5 mode. Compared to the overall complexity of the PHP 6 code, this is a minor change. I still haven't quite understood why not just do the detection on the whole auto-global when it's being fetched (or even during request startup). As Andrei said, it's slow anyway so for people who need Unicode that should be an affordable hit. Maybe I don't understand the problem in enough detail and it might make sense for me to talk to Andrei via voice directly, but I really don't think we should be over eager commiting this patch. It'll not be good for the engine long term (not that I don't appreciate your efforts and hard work on this patch). Here is a link to a message Rasmus posted describing the problems with JIT'ing the whole array at once. http://marc.theaimsgroup.com/?l=php-devm=116624773928646w=2 -Andrei -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] Objectified Request Parameters
Btw, having a request object was one of the #1 requests in framework
:) People actually really like encapsulating this because it
also makes unit testing easier down the road...
Just mentioning this because I don't think we should be too set with
our ways esp. for people who need to accomplish more
functionality.
For the record, I *do* prefer the simplicity of implementation of going
with a request object, and I *personally* don't see it as a
show-stopping BC break. Then again, I didn't see that fgets() change as
show-stopping either.
So let's start back from square one. How about a fresh round of
discussion on the request object approach, in psuedo-code:
class PHPGetObject implements ArrayAccess
{
private $decoded = array();
public function __offset_get($varname)
{
if (!isset($this-decoded[$varname])) {
$val = http_decode_get($varname);
$this-decoded[$varname] = $val;
}
return $this-decoded[$varname];
}
/* plus set,isset,unset of course */
/* Probably need an iterator too */
}
Pros: Fast, (mostly) clean, and cheap.
Cons: Breaks the following BC bahaviors:
* is_array($_GET) === false
* is_object($_GET) === true
* Referenceishness:
$get = $_GET;
$get['foo'] = 'bar';
var_dump($_GET['foo']); /* 'bar' */
My vote: +1 as I don't think the Cons are that serious.
-Sara
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Runtime-JIT, the whole enchilada
Hi Andi, On 1/27/07, Andi Gutmans [EMAIL PROTECTED] wrote: s during PHP 5 where I warned that they might introduce bugs in other areas but it's hard to forsee. No one believed me because I couldn't give a concrete enough example and we had quite a few of those bugs afterwards. Given the state of PHP5 when it was released, everyone sane should believe (I would say trust) you, even if you were the one pushing php5 final release :) As some point the platform has to be the one that grows and not the language. So if we need to evolve it to have a different way of fetching input variables that's what we should do. Exactly my point (again :-/), it is my goal for filter. That's also why I asked you (I still wait the answer by the way) earlier this year what are your needs about filters and what do you mean in your post, as you were saying that we did not do a good job. I, and I'm the only one in the active filter maintainers, changed my mind (more open) and I really think that we should provide a OO way to fetch the inputs. It can be type oriented (::getInteger()), variable oriented (::get($name), and/or both. But the needs are definitively here and I will do my best to push that in (a cgi-like object is one solution). You don't see other languages change every day because of a higher level requirement. And have no doubt, PHP 6 will take a long time to truly stabilize and make consistent because there've been huge changes. I 100% agree. No matter how much efforts are pushed into its development, I cannot imagine a first stable release in a near future, next year at best. By stable I mean a release not marked RC and something with at least a beta quality and not alpha like 5.0.0. Nobody will expect 6.0.0 to be perfect, but we should not make the same mistake again. Regards, --Pierre -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Autoglobal CVs without silence -- Summary
Hi Andi, On 1/27/07, Andi Gutmans [EMAIL PROTECTED] wrote: Hi Sara, I don't feel to great with this patch. It kind of feels like twisting the language implementation around for some very specific problem which probably shouldn't be fixed at this level. Andrei says performance of Unicode isn't great so it shouldn't matter too much, but I think a) it's not only about performance but also about maintainability. The code in PHP 6 is already much more complex than that of PHP 5 and has become much harder to maintain. Such additional changes will make it worse b) There will still be plenty of people who use PHP 6 in PHP 5 mode. I still haven't quite understood why not just do the detection on the whole auto-global when it's being fetched (or even during request startup). As Andrei said, it's slow anyway so for people who need Unicode that should be an affordable hit. Please read (once or again) my initial proposal, it is the base of Sara's proposals. Request startup is _not_ a solution because the users must have the ability to define the input encoding before the fist fetch. That's why we decide to move the JIT trigger at runtime instead of compile time. --Pierre -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Autoglobal CVs without silence -- Summary
On 1/27/07, Andi Gutmans [EMAIL PROTECTED] wrote: Btw, for people who truly need the Unicode support I actually do think we might want to consider requiring them to fetch the input variables through a new API and/or object. I don't think we need to make it seamless if the default behavior we provide (whatever that ends up being) isn't good enough... Amen. And know what? ext/filter provides all we need except the object interface, but I promise to come with a proposal+patch for it as soon as possible. --Pierre -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
RE: [PHP-DEV] Objectified Request Parameters
Thanks Sara for the additional insight. Give me a few days to look into this
further and catch the various people in person.
Unfortunately I'm going to be at a four day offsite Monday-Thursday but I'll
still try my best to touch base and try and find some
agreed upon solution.
Right now, I would lean towards something like Sara suggested in this email
(overloaded object), possibly improving some overloading
functionality on top. But I need to dive deeper into this. I have really been
behind all this stuff due to a heavy work load.
Andi
-Original Message-
From: Sara Golemon [mailto:[EMAIL PROTECTED]
Sent: Saturday, January 27, 2007 11:21 AM
To: Andi Gutmans
Cc: 'Pierre'; 'Andrei Zmievski'; 'Dmitry Stogov';
internals@lists.php.net; 'Zeev Suraski'; 'Stanislav Malyshev'
Subject: [PHP-DEV] Objectified Request Parameters
Btw, having a request object was one of the #1 requests in
framework
:) People actually really like encapsulating this because it
also makes unit testing easier down the road...
Just mentioning this because I don't think we should be
too set with our ways esp. for people who need to accomplish
more functionality.
For the record, I *do* prefer the simplicity of
implementation of going with a request object, and I
*personally* don't see it as a show-stopping BC break. Then
again, I didn't see that fgets() change as show-stopping either.
So let's start back from square one. How about a fresh round
of discussion on the request object approach, in psuedo-code:
class PHPGetObject implements ArrayAccess {
private $decoded = array();
public function __offset_get($varname)
{
if (!isset($this-decoded[$varname])) {
$val = http_decode_get($varname);
$this-decoded[$varname] = $val;
}
return $this-decoded[$varname];
}
/* plus set,isset,unset of course */
/* Probably need an iterator too */ }
Pros: Fast, (mostly) clean, and cheap.
Cons: Breaks the following BC bahaviors:
* is_array($_GET) === false
* is_object($_GET) === true
* Referenceishness:
$get = $_GET;
$get['foo'] = 'bar';
var_dump($_GET['foo']); /* 'bar' */
My vote: +1 as I don't think the Cons are that serious.
-Sara
--
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] Objectified Request Parameters
On 1/27/07, Sara Golemon [EMAIL PROTECTED] wrote:
Btw, having a request object was one of the #1 requests in framework
:) People actually really like encapsulating this because it
also makes unit testing easier down the road...
Just mentioning this because I don't think we should be too set with
our ways esp. for people who need to accomplish more
functionality.
For the record, I *do* prefer the simplicity of implementation of going
with a request object, and I *personally* don't see it as a
show-stopping BC break. Then again, I didn't see that fgets() change as
show-stopping either.
So let's start back from square one. How about a fresh round of
discussion on the request object approach, in psuedo-code:
class PHPGetObject implements ArrayAccess
{
private $decoded = array();
public function __offset_get($varname)
{
if (!isset($this-decoded[$varname])) {
$val = http_decode_get($varname);
$this-decoded[$varname] = $val;
}
return $this-decoded[$varname];
}
/* plus set,isset,unset of course */
/* Probably need an iterator too */
}
Pros: Fast, (mostly) clean, and cheap.
Cons: Breaks the following BC bahaviors:
* is_array($_GET) === false
* is_object($_GET) === true
* Referenceishness:
$get = $_GET;
$get['foo'] = 'bar';
var_dump($_GET['foo']); /* 'bar' */
My vote: +1 as I don't think the Cons are that serious.
That's not what I had in mind while talking about an object.
ArrayAccess was never an option for the exact reasons you quoted in
the cons. However if this problem can get fixed at the engine level,
why not.
--Pierre
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
