Re: [PHP-DEV] Type hinting/casting request for vote
Ilia Alshanetsky wrote: [..] I would like to ask all developers to voice their opinions of whether it makes sense to add this to 5.3 or to throw it away (either one is fine btw). +1 [..] - Mark -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] RFC: Type hinting revisited for PHP 5.3
Ilia Alshanetsky wrote: There has been quite a bit of discussion on this list, IRC, developer meetings, etc... about introduction of type hinting to PHP. [..] My hope is that the latest changes will allow this to become a standard part of PHP. +1 [..] - Mark -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] SPL ArrayAccess offsetExists default behavior
Hi list, The following doesn't strike me as consistent behavior: $a = new ArrayObject(); $a[foobar] = NULL; echo (int) isset( $a[foobar] ); // Output: 1 While it's technically correct, I find it confusing. The reason is probably because of a array_key_exists (or property_exists) check within offsetExists() that do not take return false on a NULL value, unlike isset(). What say you ? - Mark -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] register globals - PHP6 still replaces . in variables from outside
Sorry for bringing an old thread back to life, but imo this needs some more attention. Sebastian wrote: hi, PHP6 still replaces . with an underscore in variables from outside. this is an old behavior forced by register globals so i would say its a bug since . is valid in array keys. for sample: call a script like http://www.example.com/?my.var=1 now $_GET will look like this: Array ( [my_var] = 1) Thanks It's a valid HTML input name attribute character [1] and imo the replacement feature (where ' ' and '.' characters are replaced to '_') should be removed in PHP 6, when the register_globals feature is removed. There will be PHP applications that need changing, but I estimate that it will be fixed easily. And since PHP 6 is breaking a lot anyway, what other version would be more suitable to change this. [1] - http://www.w3schools.com/TAGS/att_input_name.asp - Mark -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] register globals - PHP6 still replaces . in variables from outside
Hannes Magnusson wrote: On Wed, Nov 12, 2008 at 03:57, Stan Vassilev | FM [EMAIL PROTECTED] wrote: I don't see it would work with something like import_request_variables() unless thats removed or extract(), which is some of the reasons for this replacement feature afair. There was never a need for the replacement to occur for the GPC superglobals. Isn't that fixed already? I could have sworn seeing a commit from Ilia that allowed dots in the superglobals (duplicating the key, one with dot and one with underscore) some months ago...? I do did read some code related to that, but I got the feeling that was purely for unicode related matters and I still see replacements. But perhaps I'm reading it wrong. If it has been changed, that would be excellent and it would be great if the documentation got an update also ( http://php.net/register_globals ) offtopic I was working on a patch, but I can't get PHP 6 compiled atm (tokenizer.c 'yycINITIAL' re2c v 0.13.5) /offtopic -Hannes - Mark -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] array_key_exists BC break
Stanislav Malyshev wrote: Hi! I notice that 5.3 differs from 5.2 in how array_key_exists treats objects. In 5.2, if the second parameter (array) is allowed to be object and HASH_OF is applied to it. However, in 5.3 it would produce a warning requiring an array if object passed to it. Was it intentional? Maybe the problem is deeper and is in zend_parse_arg_impl where it should allow objects for 'a' if we can have HASH_OF from them? To my understanding, it's superseded by the function property_exists. Also notice the difference of argument order. As written here: http://docs.php.net/array_key_exists -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] multiple use
Hannes Magnusson wrote: On Sun, Jun 1, 2008 at 7:43 PM, Stanislav Malyshev [EMAIL PROTECTED] wrote: Hi! use FooBar::In::Some::NameSpace as foo, SomeOther::Cool:Massive::awesome::space as bar, And::other:namespace as foobar; vs use FooBar::In::Some::NameSpace as foo; use SomeOther::Cool:Massive::awesome::space as bar; use And::other:namespace as foobar; Well, with (im)proper formatting many things can be unreadable, but use FooBar::In::Some::NameSpace as foo, SomeOther::Cool:Massive::awesome::space as bar, And::other:namespaceas foobar; doesn't seem unreadable at all to me. Repeating use is just clutter which doesn't add anything. And btw not all names are that long - when I actually used namespaces in the code, I found that it'd be much easier if I could chain declarations. Just as it is easier to do $a = array(1,2,3) and not $a = array(); $a[0] = 1; $a[1] = 2; $a[2] = 3; I don't know what else I can say. You asked if someone had objections and I replied stating my personal opinion that I find explicit use statements in multiple lines more readable. Perhaps it is. But like mentioned earlier, you can do it with multiple things already, it only makes sense adding that support to the use feature also. I don't really see the point in dropping three characters if you are going to indent it just the same anyway, doesn't even safe you a single keystroke.. I'd say use tab more often :- You don't have to use it, it doesn't exclude the other. -Hannes If it's not too much work, and if it doesn't break anything. I'd say just add it, let's not counter every patch that makes it to the list. - Mark -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] RFC: allow_call_pass_by_reference
Derick Rethans wrote: On Wed, 21 May 2008, Steph Fox wrote: I looked into it again (and found things I didn't know before). This one's bugging me enough that I braved the Wiki: http://wiki.php.net/rfc/calltimebyref I don't think we should get rid of it, or add a notice/message/whatever. Because this: http://pastebin.com/d6e055957 This pastebin expired, but is the same as: http://pastebin.com/f1d8c08e8 and: http://bugs.php.net/bug.php?id=45126 could not be done without call time pass by ref right now. So unless that's fixed, we shouldn't deprecate it. regards, Derick - Mark -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [RFC] Type hints (parameter and return value)
Derick Rethans wrote:
On Thu, 17 Apr 2008, Felipe Pena wrote:
Now with both parameter and return value type hints.
For parameter type hints, i have completed the actual implementation
with the leftover php types:
- string (binary string and unicode)
- integer (accepting numeric string too)
- double (accepting numeric string too)
- boolean ('0', '1', true, false)
I think that the typehints should be strict, if you don't want
strictness, don't use type hints.
+1
- Mark
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] RFC: Traits for PHP
[EMAIL PROTECTED] wrote: Hi, [..] Request for Comments: Traits for PHP [..] If it doesn't affect performance *MUCH* then I'm all for it ! It can bring better structure for complex designs. Also by reusing, I'm assuming less memory will be needed for the code base which is beneficial. - Mark -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] get_magic_quotes_gpc, get-magic-quotes-runtime in head, get a final decision
Pierre Joye wrote: Hi, +1: remove them (as it is now in HEAD) -1: Restore them and always return FALSE (not 0) 0: I don't care, do what you wish, I never use them anyway -1 -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] PHP taint support updated
Wietse Venema wrote: I've uploaded a new version of taint support for PHP. You can find all the files via: ftp://ftp.porcupine.org/pub/php/index.html [..] For examples and details, see the README file, also on-line at: ftp://ftp.porcupine.org/pub/php/php-5.2.5-taint-20080130.README.html I need your feedback to make this code complete. I hope to do several quick 1-2 month release cycles in which I collect feedback, fill in missing things, and adjust course until things stabilize. I must say I like the idea, but I'm not too fond about the error handling. For it to help with (especially) the unexperienced programmers it should be enabled by default, which automatically is going to break a lot of websites if put in production environments. However turning it off by default isn't going to help, most people don't even set their error_reporting() to a respectable setting, let alone a new setting. And how does this work with the Filter ( http://docs.php.net/filter ) extension ? Wietse - Mark -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
