Re: [PHP-DEV] Inconsistencies in callable, call_user_func and direct variable calls
Andrea Faulds wrote on 23/01/2015 14:37:
Hey Nikita,
On 20 Jan 2015, at 21:46, Nikita Popov nikita@gmail.com wrote:
On Tue, Jan 20, 2015 at 9:54 PM, Marc Bennewitz dev@mabe.berlin wrote:
valid for call_user_func[_array] and callable type-hint but invalid for
for direct variable calls:
- string MyClass::staticFunc
- string self::staticFunc
- string static::staticFunc
- string parent::func
- string parent::staticFunc
see http://3v4l.org/1oSO3
Thoughts ?
I would prefer deprecating this alternative notation instead of adding more
support for it. The [$class, $method] form is the canonical form we support
everywhere and which is consistent with the [$obj, $method] callbacks.
There's no point supporting another alternative notation, especially if it
was effectively unusable for a while now already.
By the way, this notation is also used by constant() and defined():
$ php -r 'class Foo { const FOO = 3; } var_dump(constant(Foo::FOO),
defined(Foo::FOO));'
int(3)
bool(true)
It’s also very intuitive compared to the function syntax. I see no reason we
shouldn’t support it more widely.
+1 on this being more intuitive syntax, although the array syntax is
convenient for dynamically selecting each part separately, and obviously
for calling non-static methods.
It actually feels kind of weird that as of PHP 7, an array is more
callable than a string:
class Foo { static function bar() { echo 'Hello'; } }
Foo::bar(); // OK
['Foo', 'bar'](); // OK
'Foo::bar'(); // FATAL ERROR
http://3v4l.org/f7rvc
Regards,
--
Rowan Collins
[IMSoP]
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Re: [RFC][VOTE] Turn gc_collect_cycles into function pointer
On 22 January 2015 at 00:56, Benjamin Eberlei kont...@beberlei.de wrote: On Wed, Jan 7, 2015 at 8:33 PM, Benjamin Eberlei kont...@beberlei.de wrote: Hello everyone, After discussion I am putting the RFC on turning gc_collect_cycles into a function pointer to vote: https://wiki.php.net/rfc/gc_fn_pointer Votes will end on 2015-01-21 19:31 (in 14 days). Sorry, I forgot to send a reminder, but given the results of 18-0 I think this is ok. The gc_fn_pointer RFC was accepted with 18-0! Thanks everyone :-) Thanks Benjamin! I've rebased my branch against master and created a PR: https://github.com/php/php-src/pull/1023. If someone with Zend karma would be so kind as to merge it, please, I'd appreciate it. Alternatively, you may consider this my semi-annual reminder that I don't have Zend karma and would like it. :) Thanks, Adam -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] [VOTE] Last call for default ctors RFC
Hi! Here's the reminder the vote for https://wiki.php.net/rfc/default_ctor is closing in a couple of days. If you didn't vote yet please do. Thanks, -- Stas Malyshev smalys...@gmail.com -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [RFC] Combined Comparison (Spaceship) Operator
Hi all, On Fri, Jan 23, 2015 at 8:05 PM, Andrea Faulds a...@ajf.me wrote: On 23 Jan 2015, at 10:02, Alain Williams a...@phcomp.co.uk wrote: On Fri, Jan 23, 2015 at 12:24:25AM +, Andrea Faulds wrote: Having it be the same as === would be inconsistent with our existing sorting and comparison behaviour, so I don’t think it should be changed. If we made it strict like that, we’d also have to define a strict and as well, otherwise we have a problem, because in some cases ($x !== $y !($x $y) !($x $y)) is TRUE. I think that you mentioned that you might come up with another RFC if = is successful - that would be for a == operator. You might want to mention that ... but it is more complicated if the operands are of different types - what does it return in that case ? FALSE ? But the same as = if the types are the same ? The RFC did originally say that, Davey had thought of it. I'm not too keen on the idea and have removed that bit: I don't really think you can do any reasonable strict ordering. An error on unmatching types is a royal pain, and I know this because I've had to deal with Game Maker Language which did this. Sorting by type is fairly unintuitive. I think that if people want strict ordering, it's trivial to implement the particular scheme they want using =, casts, type checks, or strcmp(). The only reasonable behavior for ==, ==, == would be raising error/exception if type differs. E_RECOVERABLE_ERROR may be used. If anyone write RFC for these operators, I'll vote +1. Regards, -- Yasuo Ohgaki yohg...@ohgaki.net
Re: [PHP-DEV] [RFC] pecl_http
Hi Mike, On Fri, Jan 23, 2015 at 5:34 PM, Michael Wallner m...@php.net wrote: On 23 01 2015, at 09:11, Michael Wallner m...@php.net wrote: On 23 01 2015, at 04:42, Yasuo Ohgaki yohg...@ohgaki.net wrote: Could you include http_build_query() modification in the RFC? http_build_query() escapes ' ' as '+' currently. It should be '%20'. I was about to proposing this change, but it was http_* function and the change does not break scripts. I don’t think that belongs to this RFC, Yasuo. But I’m +1 on your request, because it seems a no-brainer. BTW, there already is PHP_QUERY_RFC3986. Yes there is. I will propose changing the default. Regards, -- Yasuo Ohgaki yohg...@ohgaki.net
Re: [PHP-DEV] Re: PHP7 Homework for everyone reading this list
Dmitry Stogov in php.internals (Fri, 23 Jan 2015 17:54:45 +0400): master branch. propro, raphf and pecl_http do not compile with the master branch. You'll have to checkout the phpng branch. These extensions did compile and load: https://phpdev.toolsforresearch.com/php-7.0.0-dev-nts-Win32-VC11-x86.htm Build: https://phpdev.toolsforresearch.com/php-7.0.0-dev-nts-Win32-VC11-x86.zip Maybe there are other PECL extension that have PHP7 branches, unknown to you and me. Jan -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] PHP7 Homework for everyone reading this list
Lester Caine in php.internals (Thu, 22 Jan 2015 21:07:36 +): On 22/01/15 17:05, Rasmus Lerdorf wrote: Install php7, then install any random app and see how it goes. When I can actually run my infrastructure on PHP7 then I could at least see if there is a performance improvement. Although I think only interbase is left on the unavailable list. imagick is now available? Interbase builds and loads under Windows with VC11 x86. If it works I do not test: https://phpdev.toolsforresearch.com/php-7.0.0-dev-nts-Win32-VC11-x86.htm https://phpdev.toolsforresearch.com/php-7.0.0-dev-nts-Win32-VC11-x86.zip The configure line is misleading. For instance OCI does not build yet. Just look at the other output of phpinfo(). Jan -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Re: PHP7 Homework for everyone reading this list
Jan Ehrhardt in php.internals (Fri, 23 Jan 2015 22:18:50 +0100): Dmitry Stogov in php.internals (Fri, 23 Jan 2015 17:54:45 +0400): master branch. propro, raphf and pecl_http do not compile with the master branch. You'll have to checkout the phpng branch. These extensions did compile and load: https://phpdev.toolsforresearch.com/php-7.0.0-dev-nts-Win32-VC11-x86.htm Build: https://phpdev.toolsforresearch.com/php-7.0.0-dev-nts-Win32-VC11-x86.zip The TS build is very much alike: https://phpdev.toolsforresearch.com/php-7.0.0-dev-Win32-VC11-x86.htm https://phpdev.toolsforresearch.com/php-7.0.0-dev-Win32-VC11-x86.zip What you cannot see in phpinfo() is that php7apache2_4.dll and even php7apache2_2.dll also compile fine. Maybe there are other PECL extension that have PHP7 branches, unknown to you and me. Jan -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Removing base class from session handler
Hi Stas,
On Fri, Jan 23, 2015 at 3:47 PM, Stanislav Malyshev smalys...@gmail.com
wrote:
User may extend SessionHandler class like
class MySession extends SessionHandler {}
but user cannot extend base class(SessionHandler) capability because
user script
cannot access to PS(mod_data).
Not sure what you mean by that. Absence of access to PS(mod_data)
certainly doesn't mean the user can not extend it's function, e.g. the
manual demonstrates EncryptedSessionHandler - is there something wrong
with that? Of course, there can be many more examples of it.
This is the only reasonable use I know. I would to write user
serializer(read/writer)
handler for it.
User serializer is much powerful. Users may implement JSON/BSON/YAML/XML/
whatever serialization methods, along with encrypt/decrypt,
compress/uncompress
session data.
NOTE: Session module always serialize session data with serializer, user
cannot
implement JSON/BSON/etc without native serializer.
My point is SessionHandler class is (almost) useless as a CLASS. It
requires
implementing ALL required functions by user. There is INTERFACE for class
that requires to implement all methods.
I should have written remove the SessionHandler class. As I wrote,
user may
extend SessionHandler class.
I don't think this is a good idea. There are valid uses of this, and
there's code using it. Removing it does not achieve any goal as far as I
can see.
Goal is removing abused class usage.(cleanup) e.g. Refer to
PHP_FUNCTION(session_set_save_handler).
Advocate OOP best practice. i.e. Use INTERFACE when user is required to
implement all required methods.
And provide good API (both internal/user). e.g. Missing functions like user
serializer, gc, create_id.
Some cleanups have done in my last PR, but there are more cleanups to do.
However, defining user session class as
class MySession extends SessionHandler {}
have no merit. Users must implement required methods to be useful.
I'm not sure why you say that - if they don't implement any methods,
wouldn't that class work exactly as the native handler? Isn't the native
handler useful?
If user need native handler, they should use it directly. IMO.
Anyway, it seems it's better to propose user serializer first, then
SessionHandler
removal. (I would like to cleanup things first, then add new features one
by one though.
Session module can be simpler with a little compatibility sacrifice.)
I would like to discuss one by one. Shall we discuss user serializer? What
do you think?
Regards,
--
Yasuo Ohgaki
yohg...@ohgaki.net
[PHP-DEV] PHP 5.5.21 is available
Hi, The PHP development team announces the immediate availability of PHP 5.5.21. CVE-2015-0231, CVE-2014-9427 and CVE-2015-0232 have been addressed in this release, as well as many other bug fixes. All PHP 5.5 users are encouraged to upgrade to this version. For source downloads of PHP 5.5.21 please visit our downloads page: http://www.php.net/downloads.php Windows binaries can be found on http://windows.php.net/download/ The list of changes is recorded in the ChangeLog: http://www.php.net/ChangeLog-5.php#5.5.21 Thank you. Julien.Pauli and David Soria Parra
Re: [PHP-DEV] Re: PHP7 Homework for everyone reading this list
master branch. On Fri, Jan 23, 2015 at 12:43 AM, Jan Ehrhardt php...@ehrhardt.nl wrote: Rasmus Lerdorf in php.internals (Thu, 22 Jan 2015 09:05:28 -0800): Hopefully everyone here knows how to compile from git and get things up and running. I would love to test a Windows build with all kinds of extensions if there was a consistent way to find out which branch I'd have to checkout. For http v2, propro and raphf that is the 'phpng' branch, but I have no idea what choices other extension maintainers have made. Jan -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] PHP7 Homework for everyone reading this list
Thanks. This problem was introduced yesterday and must be already fixed. Dmitry. On Fri, Jan 23, 2015 at 7:45 AM, Juan Basso jrba...@gmail.com wrote: Trying to run phpunit on the latest CakePHP 3 gives a lot of errors of this type (not on every test case): php: /.../php-src/Zend/zend_gc.c:144: gc_possible_root: Assertion `((zend_refcounted*)(ref))-u.v.type == 7 || ((zend_refcounted*)(ref))-u.v.type == 8' failed. This errors happens after the test is completed and all output from PHPUnit is done. I am using Ubuntu 12.04 with and the last commit of my php is b8e262901e56a4d9a6664d348c9878246579239e (Thu Jan 22 14:04:49 2015 -0800). This is the gdb backtrace: (gdb) bt #0 0x761840d5 in raise () from /lib/x86_64-linux-gnu/libc.so.6 #1 0x7618783b in abort () from /lib/x86_64-linux-gnu/libc.so.6 #2 0x7617cd9e in ?? () from /lib/x86_64-linux-gnu/libc.so.6 #3 0x7617ce42 in __assert_fail () from /lib/x86_64-linux-gnu/libc.so.6 #4 0x0090ed19 in gc_possible_root (ref=0x74038820) at /.../php-src/Zend/zend_gc.c:144 #5 0x008f1b25 in gc_check_possible_root (z=0x740302e0) at /.../php-src/Zend/zend_gc.h:145 #6 0x008f1b83 in i_zval_ptr_dtor (zval_ptr=0x740302e0, __zend_filename=0xe493f0 /.../php-src/Zend/zend_hash.c, __zend_lineno=929) at /.../php-src/Zend/zend_variables.h:54 #7 0x008f4824 in zend_array_destroy (ht=0x740391e8) at /.../php-src/Zend/zend_hash.c:929 #8 0x008de252 in _zval_dtor_func_for_ptr (p=0x740391e0, __zend_filename=0xe46470 /.../php-src/Zend/zend_opcode.c, __zend_lineno=158) at /.../php-src/Zend/zend_variables.c:105 #9 0x008c76d4 in i_zval_ptr_dtor (zval_ptr=0x743e3130, __zend_filename=0xe46470 /.../php-src/Zend/zend_opcode.c, __zend_lineno=158) at /.../php-src/Zend/zend_variables.h:52 #10 0x008c8b43 in _zval_ptr_dtor (zval_ptr=0x743e3130, __zend_filename=0xe46470 /.../php-src/Zend/zend_opcode.c, __zend_lineno=158) at /.../php-src/Zend/zend_execute_API.c:483 #11 0x008cdbce in zend_cleanup_user_class_data (ce=0x7400e918) at /.../php-src/Zend/zend_opcode.c:158 #12 0x008c84b2 in shutdown_executor () at /.../php-src/Zend/zend_execute_API.c:318 #13 0x008e08ce in zend_deactivate () at /.../php-src/Zend/zend.c:886 #14 0x00851d09 in php_request_shutdown (dummy=0x0) at /.../php-src/main/main.c:1856 #15 0x009861e2 in do_cli (argc=3, argv=0x11b1990) at /.../php-src/sapi/cli/php_cli.c:1159 #16 0x0098696a in main (argc=3, argv=0x11b1990) at /.../php-src/sapi/cli/php_cli.c:1361 Any idea? I am trying to isolate the problem, but may take a while. On Thu, Jan 22, 2015 at 7:19 PM, Rasmus Lerdorf ras...@lerdorf.com wrote: On 01/22/2015 02:30 PM, Dan Ackroyd wrote: On 22 January 2015 at 21:07, Lester Caine les...@lsces.co.uk wrote: imagick is now available? Not yet. I'll try to finish it off before the end of the weekend. Most of the work was done earlier, but I need to add the changes for the Native TLS. btw this request to update the PHPNG upgrading guide is still open: Thanks. I think the TSRM changes need to be added, which could be copied from: https://github.com/php/php-src/commit/dec8eb431adee340fb8dfb9ff33ed29d3279c35f Providing a link to a commit that implemented the TSRM changes for an extension, so that people could see the actual changes needed, would be awesome. For most extensions that just do something simple like imagick does: #ifdef ZTS # define IMAGICK_G(v) TSRMG(imagick_globals_id, zend_imagick_globals *, v) #else # define IMAGICK_G(v) (imagick_globals.v) #endif There is absolutely nothing to do. You can, just for your own amusement and because it makes the code look prettier, go through and remove all instances of TSRMLS_* macros in all your C files. But it isn't critical since they are just defined to nothing in PHP7. Just leave that TSRMG define in your .h file and it will do the right thing. -Rasmus
Re: [PHP-DEV] [RFC] pecl_http
On 23 01 2015, at 02:40, Pierre Joye pierre@gmail.com wrote: On Thu, Jan 22, 2015 at 5:32 PM, Michael Wallner m...@php.net wrote: Hi! Now, that I'm mostly done with porting pecl/http [1] and dependencies (propro [2] and raphf [3]) to ZE3 I'd like to restart discussion on the topic, whether it is feasible to add pecl_http as a bundled extension to the core. https://wiki.php.net/rfc/pecl_http [1] https://github.com/php/pecl-http-pecl_http/tree/phpng [2] https://github.com/php/pecl-php-propro/tree/phpng [3] https://github.com/php/pecl-php-raphf/tree/phpng For a test run with master, clone into ext/ and `configure --with-http --enable-propro --enable-raphf` after buildconf. Let me know if it doesn't work out of the box for you. I'll have to update the corresponding links in the RFC to the phpng branches and refresh the code coverage reports in the next few days. Reminder! Do not look at php.net/http; API docs are here: http://devel-m6w6.rhcloud.com/mdref/http/ I am still all for it :) By the way, I did not yet look more deeply to raphf and propro but that's something I like to discuss. If their feautures are useful for other parts of the core, extensions, bundled or not, we should consider moving them to the main APIs and not as two new independent extensions. Well, I’m not the one to tell you that :) If I didn’t find it useful, I wouldn’t have built it. Don’t hesitate, if there are questions about what they conceptually are trying to accomplish. I think a short discussion about where to put the dependant code and noting the outcome in the RFC could be the way to go. I guess just a few people who think that pecl_http is about to be included would suffice. Best regards, Mike -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [RFC] Combined Comparison (Spaceship) Operator
Hi Stas, On 23 Jan 2015, at 23:42, Stanislav Malyshev smalys...@gmail.com wrote: The only reasonable behavior for ==, ==, == would be raising error/exception if type differs. E_RECOVERABLE_ERROR may be used. Comparison operators raising exceptions doesn't sound like a very nice thing to work with. I agree. As I’ve already mentioned, I have used (sometimes still do use) the relatively obscure Game Maker Language, which made this mistake. 1 == “1” is an error, “1” 1 is an error, and so on. It is incredibly impractical, especially since you’ll sometimes get the “wrong” type when errors happen, just like how in PHP a function might return FALSE or NULL if it’s given the wrong arguments. Compare that value, and bam, your game just crashed! I really don’t think we should make the mistake of copying GML here. Thanks. -- Andrea Faulds http://ajf.me/ -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [RFC][Vote] Return Types
As a reminder, this RFC (https://wiki.php.net/rfc/return_types) will close in a few hours. I want to thank everyone who has voted so far, and encourage anyone who has not yet voted to do so. -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Removing base class from session handler
Hi Stas, On Sat, Jan 24, 2015 at 9:29 AM, Stanislav Malyshev smalys...@gmail.com wrote: Let's keep SessionHandler class. However, PHP_FUNCTION(session_set_save_handler) should be cleaned up to verify implemented/extended interface/class. It's BC. Do you have opinion for this? I think it would be OK to require implementing the interface (and of course the class should be implementing that as well). That sounds to me like a kind of BC break that is acceptable in PHP 7. Probably requires an RFC though as it is a BC break - and maybe there are reasons why it wasn't done that I was missing, then they will be exposed when discussing the RFC. I don't remember well the reason why neither. I guess the reason why session_set_save_handler() does not check class/interface definition as usual is for PHP4 compatibility. It's legacy code anyway. I'll write the RFC as soon as other proposal discussion finishes. Regards, -- Yasuo Ohgaki yohg...@ohgaki.net
Re: [PHP-DEV] User defined session serialize handler
Sessions take a big amount of data in production systems, so it might be worth
to use msgpack (or others) as an option.
Regards
Thomas
Yasuo Ohgaki wrote on 24.01.2015 03:28:
Hi all,
Session module has session serializer modules that serializes $_SESSION
back and forth.
Session serializer module can be defined by user if there is API for it. I
would like to
propose user defined serialize handler API.
The user defined serializer API will have similar API like
session_set_save_handler().
bool session_set_save_handler(callable $serialize_callback, callable
$unserialize_callback)
bool session_set_save_handler(SessionSerializer $serializer);
interface SessionSerializer {
public string function serialize(array $_SESSION); // Return serialized
session data
public bool function unserialize(array $_SESSION, string $session_data);
// Initialize $_SESSION by $session_data
}
php.ini :
There is session.serialize_handler (Default: php) user will be added,
but user must use
session_set_serialize_handler() just like session_set_save_handler().
I also would like to php_serialize handler as the default serializer and
make php/php_binary deprecated.
php/php_binary serializers are made to work with register_globals and have
many limitations.
e.g. Integer key not allowed, key cannot start with number, delimiter chars
are invalid and
ignored, etc. php_serialize does not have such limitations at all.
Thank you for your feedback.
Regards,
--
Yasuo Ohgaki
yohg...@ohgaki.net
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [RFC] Combined Comparison (Spaceship) Operator
Hi! The only reasonable behavior for ==, ==, == would be raising error/exception if type differs. E_RECOVERABLE_ERROR may be used. Comparison operators raising exceptions doesn't sound like a very nice thing to work with. -- Stas Malyshev smalys...@gmail.com -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Removing base class from session handler
Hi Stas,
On Sat, Jan 24, 2015 at 8:49 AM, Stanislav Malyshev smalys...@gmail.com
wrote:
This is the only reasonable use I know. I would to write user
serializer(read/writer)
handler for it.
So we went from no reasonable use to one reasonable use, documented at
the manual. I think it is also reasonable to suppose there are more uses
for it.
This is because session module lacks user defined serializer. Save handler
handles session data storage. Serialize handler handles how data is
converted/represented. IMHO.
Basic save handler design is good while it is bad not to provide user
serialize
handler.
My point is SessionHandler class is (almost) useless as a CLASS. It
I think we established it is not useless. It may not be useful for you,
but may be useful for other people. Creating a large BC break for a
reason that something is not useable for someone is not a good idea, I
think. I do not see any benefit such action would produce.
Goal is removing abused class usage.(cleanup) e.g. Refer to
The action should not be its own goal, and I don't see how it's
abused. So far we have seen an example of use which you recognized as
reasonable, and which is endorsed by our own manual,, and no examples of
abuse.
I've mentioned the code, PHP_FUNCTION(session_set_save_handler).
/* For compatibility reason, implemeted interface is not checked */
/* Find implemented methods - SessionHandlerInterface */
i = 0;
ZEND_HASH_FOREACH_STR_KEY(php_session_iface_entry-function_table,
func_name) {
if ((current_mptr = zend_hash_find_ptr(Z_OBJCE_P(obj)-function_table,
func_name))) {
if (!Z_ISUNDEF(PS(mod_user_names).names[i])) {
zval_ptr_dtor(PS(mod_user_names).names[i]);
}
array_init_size(PS(mod_user_names).names[i], 2);
Z_ADDREF_P(obj);
add_next_index_zval(PS(mod_user_names).names[i], obj);
add_next_index_str(PS(mod_user_names).names[i],
zend_string_copy(func_name));
} else {
php_error_docref(NULL, E_ERROR, Session handler's function table is
corrupt);
RETURN_FALSE;
}
++i;
} ZEND_HASH_FOREACH_END();
/* Find implemented methods - SessionIdInterface (optional) */
ZEND_HASH_FOREACH_STR_KEY(php_session_id_iface_entry-function_table,
func_name) {
if ((current_mptr = zend_hash_find_ptr(Z_OBJCE_P(obj)-function_table,
func_name))) {
if (!Z_ISUNDEF(PS(mod_user_names).names[i])) {
zval_ptr_dtor(PS(mod_user_names).names[i]);
}
array_init_size(PS(mod_user_names).names[i], 2);
Z_ADDREF_P(obj);
add_next_index_zval(PS(mod_user_names).names[i], obj);
add_next_index_str(PS(mod_user_names).names[i],
zend_string_copy(func_name));
} else {
if (!Z_ISUNDEF(PS(mod_user_names).names[i])) {
zval_ptr_dtor(PS(mod_user_names).names[i]);
ZVAL_UNDEF(PS(mod_user_names).names[i]);
}
}
++i;
} ZEND_HASH_FOREACH_END();
/* Find implemented methods - SessionUpdateTimestampInterface (optional) */
ZEND_HASH_FOREACH_STR_KEY(php_session_update_timestamp_iface_entry-function_table,
func_name) {
if ((current_mptr = zend_hash_find_ptr(Z_OBJCE_P(obj)-function_table,
func_name))) {
if (!Z_ISUNDEF(PS(mod_user_names).names[i])) {
zval_ptr_dtor(PS(mod_user_names).names[i]);
}
array_init_size(PS(mod_user_names).names[i], 2);
Z_ADDREF_P(obj);
add_next_index_zval(PS(mod_user_names).names[i], obj);
add_next_index_str(PS(mod_user_names).names[i],
zend_string_copy(func_name));
} else {
if (!Z_ISUNDEF(PS(mod_user_names).names[i])) {
zval_ptr_dtor(PS(mod_user_names).names[i]);
ZVAL_UNDEF(PS(mod_user_names).names[i]);
}
}
++i;
} ZEND_HASH_FOREACH_END();
As you can see, it does not check if user class implements/extends
interface/class.
PHP_FUNCTION(session_set_save_handler).
Advocate OOP best practice. i.e. Use INTERFACE when user is required to
implement all required methods.
There's no OOP best practice that says you can not extend classes and
override some of its methods in order to modify parent's behavior. On
the contrary, doing this is one of common OOP practices.
The PHP_FUNCTION(session_set_save_handler) code could be best practice
hardly.
And provide good API (both internal/user). e.g. Missing functions like
user serializer, gc, create_id.
If you want to provide additional API, by all means please make an RFC.
But I do not see how removing this class is required for providing any API.
Fair enough. I'll implement user serialize handler. Removal of
SessionHandler
class may be discussed when use of user serialize handler became dominant.
I would like to make SessionHandler deprecated, encourage user serialize
handler for new PHP because it's more efficient and clean. Do you agree?
If user need native handler, they should use it directly. IMO.
I do not see any reason for that. You can clearly use native handler and
add modifications for it. In fact, that is exactly why that class exists.
I would like to discuss one by one. Shall we discuss user serializer?
What do you think?
Again, if you want to propose new feature, by all means please do. I
still don't see how it requires removing existing classes. This is a
Re: [PHP-DEV] Removing base class from session handler
Hi! Let's keep SessionHandler class. However, PHP_FUNCTION(session_set_save_handler) should be cleaned up to verify implemented/extended interface/class. It's BC. Do you have opinion for this? I think it would be OK to require implementing the interface (and of course the class should be implementing that as well). That sounds to me like a kind of BC break that is acceptable in PHP 7. Probably requires an RFC though as it is a BC break - and maybe there are reasons why it wasn't done that I was missing, then they will be exposed when discussing the RFC. -- Stas Malyshev smalys...@gmail.com -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] Re: User defined session serialize handler
Hi all, Additional comments. On Sat, Jan 24, 2015 at 11:28 AM, Yasuo Ohgaki yohg...@ohgaki.net wrote: php.ini : There is session.serialize_handler (Default: php) user will be added, but user must use session_set_serialize_handler() just like session_set_save_handler(). I also would like to php_serialize handler as the default serializer and make php/php_binary deprecated. php/php_binary serializers are made to work with register_globals and have many limitations. e.g. Integer key not allowed, key cannot start with number, delimiter chars are invalid and ignored, etc. php_serialize does not have such limitations at all. php_serialize uses plain PHP serialize/unserialize for $_SESSION. i.e. Serialized data is the same as serialize($_SESSION). php_serialize is introduced from PHP 5.5. Regards, -- Yasuo Ohgaki yohg...@ohgaki.net
Re: [PHP-DEV] Inconsistencies in callable, call_user_func and direct variable calls
Hi! Foo::bar(); // OK ['Foo', 'bar'](); // OK 'Foo::bar'(); // FATAL ERROR I'm not sure why one would ever need/want the latter. IMO, it just looks weird. -- Stas Malyshev smalys...@gmail.com -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Removing base class from session handler
Hi! This is the only reasonable use I know. I would to write user serializer(read/writer) handler for it. So we went from no reasonable use to one reasonable use, documented at the manual. I think it is also reasonable to suppose there are more uses for it. My point is SessionHandler class is (almost) useless as a CLASS. It I think we established it is not useless. It may not be useful for you, but may be useful for other people. Creating a large BC break for a reason that something is not useable for someone is not a good idea, I think. I do not see any benefit such action would produce. Goal is removing abused class usage.(cleanup) e.g. Refer to The action should not be its own goal, and I don't see how it's abused. So far we have seen an example of use which you recognized as reasonable, and which is endorsed by our own manual,, and no examples of abuse. PHP_FUNCTION(session_set_save_handler). Advocate OOP best practice. i.e. Use INTERFACE when user is required to implement all required methods. There's no OOP best practice that says you can not extend classes and override some of its methods in order to modify parent's behavior. On the contrary, doing this is one of common OOP practices. And provide good API (both internal/user). e.g. Missing functions like user serializer, gc, create_id. If you want to provide additional API, by all means please make an RFC. But I do not see how removing this class is required for providing any API. If user need native handler, they should use it directly. IMO. I do not see any reason for that. You can clearly use native handler and add modifications for it. In fact, that is exactly why that class exists. I would like to discuss one by one. Shall we discuss user serializer? What do you think? Again, if you want to propose new feature, by all means please do. I still don't see how it requires removing existing classes. This is a very big BC break and requires very big gain to justify, and so far the gain was not shown I think. -- Stas Malyshev smalys...@gmail.com -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [RFC] Combined Comparison (Spaceship) Operator
Hi Stas, On Sat, Jan 24, 2015 at 8:42 AM, Stanislav Malyshev smalys...@gmail.com wrote: The only reasonable behavior for ==, ==, == would be raising error/exception if type differs. E_RECOVERABLE_ERROR may be used. Comparison operators raising exceptions doesn't sound like a very nice thing to work with. I meant if it's ever implemented. DbC would do the job to prevent/detect illegal comparison and it's much better than catching errors in comparison. IMHO. Type hint is useful for preventing/detecting illegal comparisons also. There are many cases that types are better to be checked always. However, there are many cases that type checks are better to be omitted for production code also. DbC can be use in this case for faster execution while asserting types during development. Anyway, it's off topic. Regards, -- Yasuo Ohgaki yohg...@ohgaki.net
[PHP-DEV] User defined session serialize handler
Hi all,
Session module has session serializer modules that serializes $_SESSION
back and forth.
Session serializer module can be defined by user if there is API for it. I
would like to
propose user defined serialize handler API.
The user defined serializer API will have similar API like
session_set_save_handler().
bool session_set_save_handler(callable $serialize_callback, callable
$unserialize_callback)
bool session_set_save_handler(SessionSerializer $serializer);
interface SessionSerializer {
public string function serialize(array $_SESSION); // Return serialized
session data
public bool function unserialize(array $_SESSION, string $session_data);
// Initialize $_SESSION by $session_data
}
php.ini :
There is session.serialize_handler (Default: php) user will be added,
but user must use
session_set_serialize_handler() just like session_set_save_handler().
I also would like to php_serialize handler as the default serializer and
make php/php_binary deprecated.
php/php_binary serializers are made to work with register_globals and have
many limitations.
e.g. Integer key not allowed, key cannot start with number, delimiter chars
are invalid and
ignored, etc. php_serialize does not have such limitations at all.
Thank you for your feedback.
Regards,
--
Yasuo Ohgaki
yohg...@ohgaki.net
Re: [PHP-DEV] [RFC] pecl_http
On 22 01 2015, at 19:51, Levi Morrison le...@php.net wrote: Now, that I'm mostly done with porting pecl/http [1] and dependencies (propro [2] and raphf [3]) to ZE3 I'd like to restart discussion on the topic, whether it is feasible to add pecl_http as a bundled extension to the core. https://wiki.php.net/rfc/pecl_http The RFC doesn't mention if you intend for it to be enabled by default or just included with the php-src repository. I can reasonably see this detail influencing the way someone would vote, so can you please update the RFC accordingly? I’m not sure why that would directly influence a yay/nay but I guess we could either make a 3-way poll or a separate vote on enabling it by default? Regards, Mike -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Re: PHP7 Homework for everyone reading this list
I found another segment fault on PHP 7 during CakePHP 3 tests. I reported the issue on https://bugs.php.net/bug.php?id=68896 On Fri, Jan 23, 2015 at 5:01 PM, Jan Ehrhardt php...@ehrhardt.nl wrote: Jan Ehrhardt in php.internals (Fri, 23 Jan 2015 22:18:50 +0100): Dmitry Stogov in php.internals (Fri, 23 Jan 2015 17:54:45 +0400): master branch. propro, raphf and pecl_http do not compile with the master branch. You'll have to checkout the phpng branch. These extensions did compile and load: https://phpdev.toolsforresearch.com/php-7.0.0-dev-nts-Win32-VC11-x86.htm Build: https://phpdev.toolsforresearch.com/php-7.0.0-dev-nts-Win32-VC11-x86.zip The TS build is very much alike: https://phpdev.toolsforresearch.com/php-7.0.0-dev-Win32-VC11-x86.htm https://phpdev.toolsforresearch.com/php-7.0.0-dev-Win32-VC11-x86.zip What you cannot see in phpinfo() is that php7apache2_4.dll and even php7apache2_2.dll also compile fine. Maybe there are other PECL extension that have PHP7 branches, unknown to you and me. Jan -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [RFC][Vote] Return Types
On Fri, Jan 23, 2015 at 5:06 PM, Levi Morrison le...@php.net wrote: As a reminder, this RFC (https://wiki.php.net/rfc/return_types) will close in a few hours. I want to thank everyone who has voted so far, and encourage anyone who has not yet voted to do so. I have close the voting. It has passed with a vote of 47 to 3. I will update the patch to the latest master and then ping Dmitry to do a final pass before merging it into master. -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Re: PHP7 Homework for everyone reading this list
This is not a segfault, but another issue exclusive from PHP 7 https://bugs.php.net/bug.php?id=68897 On Fri, Jan 23, 2015 at 11:54 PM, Juan Basso jrba...@gmail.com wrote: I found another segment fault on PHP 7 during CakePHP 3 tests. I reported the issue on https://bugs.php.net/bug.php?id=68896 On Fri, Jan 23, 2015 at 5:01 PM, Jan Ehrhardt php...@ehrhardt.nl wrote: Jan Ehrhardt in php.internals (Fri, 23 Jan 2015 22:18:50 +0100): Dmitry Stogov in php.internals (Fri, 23 Jan 2015 17:54:45 +0400): master branch. propro, raphf and pecl_http do not compile with the master branch. You'll have to checkout the phpng branch. These extensions did compile and load: https://phpdev.toolsforresearch.com/php-7.0.0-dev-nts-Win32-VC11-x86.htm Build: https://phpdev.toolsforresearch.com/php-7.0.0-dev-nts-Win32-VC11-x86.zip The TS build is very much alike: https://phpdev.toolsforresearch.com/php-7.0.0-dev-Win32-VC11-x86.htm https://phpdev.toolsforresearch.com/php-7.0.0-dev-Win32-VC11-x86.zip What you cannot see in phpinfo() is that php7apache2_4.dll and even php7apache2_2.dll also compile fine. Maybe there are other PECL extension that have PHP7 branches, unknown to you and me. Jan -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] VCS Account Request: desty
Developing the PHP runtime Maintaining an official, bundled PHP extension Maintaining the documentation Translating the documentation Maintaining php.net -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Enable error_handler callback parameters to be passed by reference
function myErrorHandler($errno, $errstr, $errfile, $errline) {...}
It would be awesome to also pass $errfile and $errline by reference. This
would allow mapping compiled source to real source code and have
meaningful error file+line information.
By compiled, I mean e.g. inlined classes (like the bootstrap.cache.php
file in Symfony), or preprocessed sources, etc.
Nicolas
[PHP-DEV] Packaging in general - was Re: [PHP-DEV] [RFC] pecl_http
On 23/01/15 08:27, Michael Wallner wrote: Well, I’m not the one to tell you that :) If I didn’t find it useful, I wouldn’t have built it. Don’t hesitate, if there are questions about what they conceptually are trying to accomplish. I think a short discussion about where to put the dependant code and noting the outcome in the RFC could be the way to go. I guess just a few people who think that pecl_http is about to be included would suffice. I started using PHP one windows, and so have always viewed it as a smaller core and a series of modules. SUSE continues that model and I see no reason to change now, so in my book it is the the current bundling and enabling by default that has always been the wrong approach. I simply enable the elements I need and leave out all the other stuff which I don't. So the debate should be if other 'dependant code' exists. A large section of the ini file relates to modules which may well not be enabled so that gets deleted and moved to the relevant sub.ini . You are already talking about pushing php_interbase and other extensions into pecl, so they can be ignored but we got agreement a long time ago that no one database would be enabled by default, so all should be easily available. I would probably add that for a long time now I think most distributions have bundled mysql and mysqli in the one package, so the idea of removing mysql may not be so easy to achieve. -- Lester Caine - G8HFL - Contact - http://lsces.co.uk/wiki/?page=contact L.S.Caine Electronic Services - http://lsces.co.uk EnquirySolve - http://enquirysolve.com/ Model Engineers Digital Workshop - http://medw.co.uk Rainbow Digital Media - http://rainbowdigitalmedia.co.uk -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Enable error_handler callback parameters to be passed by reference
Yeah, seem other want it it too, so I just updated the PR to allow the
first four parameters been passed by reference.
On 23 January 2015 at 16:23, Nicolas Grekas nicolas.grekas+...@gmail.com
wrote:
function myErrorHandler($errno, $errstr, $errfile, $errline) {...}
It would be awesome to also pass $errfile and $errline by reference. This
would allow mapping compiled source to real source code and have
meaningful error file+line information.
By compiled, I mean e.g. inlined classes (like the bootstrap.cache.php
file in Symfony), or preprocessed sources, etc.
Nicolas
Re: [PHP-DEV] [RFC] Combined Comparison (Spaceship) Operator
On Fri, Jan 23, 2015 at 12:24:25AM +, Andrea Faulds wrote: Having it be the same as === would be inconsistent with our existing sorting and comparison behaviour, so I don’t think it should be changed. If we made it strict like that, we’d also have to define a strict and as well, otherwise we have a problem, because in some cases ($x !== $y !($x $y) !($x $y)) is TRUE. I think that you mentioned that you might come up with another RFC if = is successful - that would be for a == operator. You might want to mention that ... but it is more complicated if the operands are of different types - what does it return in that case ? FALSE ? But the same as = if the types are the same ? -- Alain Williams Linux/GNU Consultant - Mail systems, Web sites, Networking, Programmer, IT Lecturer. +44 (0) 787 668 0256 http://www.phcomp.co.uk/ Parliament Hill Computers Ltd. Registration Information: http://www.phcomp.co.uk/contact.php #include std_disclaimer.h -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [RFC] Combined Comparison (Spaceship) Operator
Hi Alain, On 23 Jan 2015, at 10:02, Alain Williams a...@phcomp.co.uk wrote: On Fri, Jan 23, 2015 at 12:24:25AM +, Andrea Faulds wrote: Having it be the same as === would be inconsistent with our existing sorting and comparison behaviour, so I don’t think it should be changed. If we made it strict like that, we’d also have to define a strict and as well, otherwise we have a problem, because in some cases ($x !== $y !($x $y) !($x $y)) is TRUE. I think that you mentioned that you might come up with another RFC if = is successful - that would be for a == operator. You might want to mention that ... but it is more complicated if the operands are of different types - what does it return in that case ? FALSE ? But the same as = if the types are the same ? The RFC did originally say that, Davey had thought of it. I'm not too keen on the idea and have removed that bit: I don't really think you can do any reasonable strict ordering. An error on unmatching types is a royal pain, and I know this because I've had to deal with Game Maker Language which did this. Sorting by type is fairly unintuitive. I think that if people want strict ordering, it's trivial to implement the particular scheme they want using =, casts, type checks, or strcmp(). Thanks! -- Andrea Faulds http://ajf.me/ -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [RFC] pecl_http
On 23 01 2015, at 04:42, Yasuo Ohgaki yohg...@ohgaki.net wrote: Could you include http_build_query() modification in the RFC? http_build_query() escapes ' ' as '+' currently. It should be '%20'. I was about to proposing this change, but it was http_* function and the change does not break scripts. I don’t think that belongs to this RFC, Yasuo. But I’m +1 on your request, because it seems a no-brainer. Cheers, Mike -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [RFC] pecl_http
On 23 01 2015, at 09:11, Michael Wallner m...@php.net wrote: On 23 01 2015, at 04:42, Yasuo Ohgaki yohg...@ohgaki.net wrote: Could you include http_build_query() modification in the RFC? http_build_query() escapes ' ' as '+' currently. It should be '%20'. I was about to proposing this change, but it was http_* function and the change does not break scripts. I don’t think that belongs to this RFC, Yasuo. But I’m +1 on your request, because it seems a no-brainer. BTW, there already is PHP_QUERY_RFC3986. Mike -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Inconsistencies in callable, call_user_func and direct variable calls
I'm not sure though if it should be done by adding
'foo::bar' to $a() or removing it from call_user_func().
call_user_func('foo::bar') work since 5.2.2 (see http://3v4l.org/k2SOU).
Is there a serious reason to break code that is perfectly fine since 2007.
Breaking BC needs a serious reason IMHO.
Re: [PHP-DEV] Casting a PHP type, new SAPI
On Fri, 2015-01-23 at 07:38 +0100, Kevin Ingwersen (Ingwie Phoenix)
wrote:
Am 20.01.2015 um 23:11 schrieb Johannes Schlüter johan...@schlueters.de:
Hi,
On Tue, 2015-01-20 at 06:36 +0100, Kevin Ingwersen (Ingwie Phoenix)
wrote:
Today I have started to concept a new SAPI which I have wanted to do
in quite a while now. To learn more, here is a README:
https://github.com/IngwiePhoenix/php-jrp/blob/master/README.md
https://github.com/IngwiePhoenix/php-jrp/blob/master/README.md
I have to agree with Bas van Beek that I don't see the benefit of using
a custom protocol over existing ones. This protocol doesn't seem to have
less overhead than HTTP and you loose ability of using established
libraries, debugging tools, scaling tools, ...
…but you gain the headache of FastCGI. I just wasted 3 hours, trying
to get this working right. It was more of an issue with the script
language I am using to write the web server - but getting my head
around FastCGI in the first place is a mess. When was it written and
published, 1996?
Written and published in 1996 means there are stable tools and
libraries ;-)
And well, a few hours learning FastCGI vs. long time to invent something
new. But your call, and maybe you are successful and create something
better ...
Using threads means pain with PHP. One thing is TSRM (while
replaced in PHP 7 with TLS)[...]
I thought TSRM was stable?
TSRM itself is stable. Doesn't mean it's good. It has a notable
performance penalty (Zend/bench.php on my machine with 5.6 is ca. 2.0s
vs 2.6s, also requires more memory, this is better in PHP 7, but not
perfect either) and is less tested (I doubt we have many devs actually
running in a threaded context to observe races, true, it's some time
since I debugged such a thing but don't know how many of our can't
reproduce bugs are threading issues ...)
[...]the other thing is stability: A crash in one
thread will crash the whole server, in a process-based model like
FastCGI or apache mod_prefork only the single process and request will
die. Crashing PHP is trivial (infinite recursion etc.)
My idea was to use a thread per process watchdog. So a request is
started, and it is given to a new thread - so it has its own PHP
process running and when that one dies, it can send back an error
message accordingly. PHP was not ment to run in the same process in
the first place.
If PHP crashes due to something like
$ php -nr 'function a() { call_user_func(a); } a();'
Segmentation fault (core dumped)
your watchdog thread will die, too, as will each other PHP thread in the
same process. (yes, eventually one could catch SIGSEGV and then try to
do some magic but welcome to devil's kitchen)
pcntl_fork() is not in the standart PHP it seems, otherwise I would
have written JRP using that. But since this is going to be a
general-purpose SAPI anyway, I can just write it in C++ from the
get-go.
pcntl_fork is a default extension for CLI SAPI, for other SAPIs it's
disabled. Distributors sometimes split that up differently. Properly
forking however is complicated when having opened resources. Also this
sounds like long running scripts ... since 5.3's GC it's better, but
PHP's memory and resource handling isn't really aimed at scripts running
longer than a few milliseconds.
johannes
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Removing base class from session handler
Hi, I agree that the low-level details of different session handlers makes the SessionHandler class a bit weird. However, I disagree that it is useless. We've discussed this before and I want to re-iterate my suggestion to simply provide a separate class for each underlying save_handler, like FilesSessionHandler, MemcacheSessionHandler, etc. Cheers, Andrey. -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Inconsistencies in callable, call_user_func and direct variable calls
Hey Nikita,
On 20 Jan 2015, at 21:46, Nikita Popov nikita@gmail.com wrote:
On Tue, Jan 20, 2015 at 9:54 PM, Marc Bennewitz dev@mabe.berlin wrote:
valid for call_user_func[_array] and callable type-hint but invalid for
for direct variable calls:
- string MyClass::staticFunc
- string self::staticFunc
- string static::staticFunc
- string parent::func
- string parent::staticFunc
see http://3v4l.org/1oSO3
Thoughts ?
I would prefer deprecating this alternative notation instead of adding more
support for it. The [$class, $method] form is the canonical form we support
everywhere and which is consistent with the [$obj, $method] callbacks.
There's no point supporting another alternative notation, especially if it
was effectively unusable for a while now already.
By the way, this notation is also used by constant() and defined():
$ php -r 'class Foo { const FOO = 3; } var_dump(constant(Foo::FOO),
defined(Foo::FOO));'
int(3)
bool(true)
It’s also very intuitive compared to the function syntax. I see no reason we
shouldn’t support it more widely.
--
Andrea Faulds
http://ajf.me/
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] in Operator
Yasuo Ohgaki wrote on 23/01/2015 03:01:
Hi Niklas,
On Mon, Jan 19, 2015 at 9:42 AM, Niklas Kellerm...@kelunik.com wrote:
I'd like to propose a new feature to PHP: The in Operator
Bob mentioned a few weeks ago he wants such an operator in PHP and today I
stumbled over
http://nikic.github.io/2012/07/27/How-to-add-new-syntactic-features-to-PHP.html
again,
which uses the in operator as a sample.
Use cases:
$obj = new StdClass;
$obj-prop = value;
$languages = [PHP, C, Java];
var_dump(PHP in $languages); // true
var_dump(Python in $languages); // false
var_dump(0 in $languages); // false
var_dump(0x0 in [0e3]); // false
var_dump(prop in $obj); // true
var_dump(foo in $obj); // false
var_dump(Hello in Hello World!); // true
For strings, it would replace `strpos(Hello World!, Hello) !== false)`,
for arrays it would replace `in_array($needle, $haystack, true)`
and for objects it would be a replacement of property_exists($class,
$property)`.
This change would mainly be syntax sugar, but I think it's worth because:
* `0x0 in [0e3]` would return false while `in_array(0x0, [0e3])`
returns true, that's probably an edge case, but there may be a lot of
people that don't use the `$strict` parameter, seehttp://3v4l.org/0K7E5
* It would solve the issue that it's hard to remember the order of the
arguments for in_array and strpos, just had to look it up again.
Bob would volunteer to implement that feature.
I would like to reserve 'in' and 'out' for Design by Contract (DbC).
http://en.wikipedia.org/wiki/Design_by_contract
D language has in and out like
function foo() {
in {
// precondition
}
out {
// postcondition
}
{
// function body
}
Would this conflict? It seems to me that this syntax could only ever
exist in a declaration (function signature) context, and the proposed in
operator could only ever exist in a procedural code (function body)
context, which are surely completely separate sections of the parser.
If anything, wanting the keyword for another purpose might strengthen
its case, because each feature isn't reserving a new word. It's not the
first keyword to have distinct meanings by context - use means very
different things for namespaces, traits, and closures.
Regards,
--
Rowan Collins
[IMSoP]
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
