Hi,
What do you think about merging the following proposals into a single and
consistent one:
https://wiki.php.net/rfc/scalar_type_hinting_with_cast
https://wiki.php.net/rfc/returntypehinting
https://wiki.php.net/rfc/nullable_typehints
I think it makes sense to keep syntax consistent with subset of Facebook's
Hack to not make troubles to each other.
I mainly interested in this feature from JIT compiler point of view,
because once compiler knows primitive types of functions arguments and
return values, it may generate much better code. So the solution must
guarantee the types of arguments at function entry point, not the types of
actual parameters (they may be auto-converted if possible).
Thanks. Dmitry.
What do you think about merging the following proposals into a single and consistent one:
https://wiki.php.net/rfc/scalar_type_hinting_with_cast
https://wiki.php.net/rfc/returntypehinting
https://wiki.php.net/rfc/nullable_typehints
No, please let’s not merge them. First off, the scalar hints proposal is basically dead, I’ll have a replacement at some point, but I have actually abandoned it.
Secondly, merging these together might be the death of all the RFCs. While one might be uncontroversial on its own, bundling it together with other changes might make it unpassable.
Andrea Faulds
http://ajf.me/
I see your point. For me they just don't have a lot of sense without each
other.
Thanks. Dmitry.
What do you think about merging the following proposals into a single
and consistent one:https://wiki.php.net/rfc/scalar_type_hinting_with_cast
https://wiki.php.net/rfc/returntypehinting
https://wiki.php.net/rfc/nullable_typehintsNo, please let’s not merge them. First off, the scalar hints proposal is
basically dead, I’ll have a replacement at some point, but I have actually
abandoned it.Secondly, merging these together might be the death of all the RFCs. While
one might be uncontroversial on its own, bundling it together with other
changes might make it unpassable.Andrea Faulds
http://ajf.me/
Am 18.08.2014 um 16:21 schrieb Dmitry Stogov:
For me they just don't have a lot of sense without each other.
https://wiki.php.net/rfc/returntypehinting makes sense without
https://wiki.php.net/rfc/scalar_type_hinting_with_cast and
https://wiki.php.net/rfc/nullable_typehints IMHO.
I see your point. For me they just don't have a lot of sense without each
other.
I am the author of two of those RFCs. I've worked with several members
of the HHVM team so that any inconsistencies are planned and recorded
(or will be; I know of one inconsistency in return types that is not
currently recorded).
I also am definitely not in favor of merging them, for the reasons
Andrea outlined.
Also, Dmitry, if you have interest in working on the implementations
for these RFCs I'm sure Joe would appreciate the help (I know I
would).
Hi Levi,
The implementation is really not a problem. It must be quite simple and I
may take care about it.
The problem that we can't come to agreement on scalar type hinting for
years :(
Thanks. Dmitry.
On Mon, Aug 18, 2014 at 9:57 PM, Levi Morrison morrison.levi@gmail.com
wrote:
I see your point. For me they just don't have a lot of sense without each
other.I am the author of two of those RFCs. I've worked with several members
of the HHVM team so that any inconsistencies are planned and recorded
(or will be; I know of one inconsistency in return types that is not
currently recorded).I also am definitely not in favor of merging them, for the reasons
Andrea outlined.Also, Dmitry, if you have interest in working on the implementations
for these RFCs I'm sure Joe would appreciate the help (I know I
would).
Hi Levi,
The implementation is really not a problem. It must be quite simple and I
may take care about it.
The problem that we can't come to agreement on scalar type hinting for years
:(Thanks. Dmitry.
On Mon, Aug 18, 2014 at 9:57 PM, Levi Morrison morrison.levi@gmail.com
wrote:I see your point. For me they just don't have a lot of sense without
each
other.I am the author of two of those RFCs. I've worked with several members
of the HHVM team so that any inconsistencies are planned and recorded
(or will be; I know of one inconsistency in return types that is not
currently recorded).I also am definitely not in favor of merging them, for the reasons
Andrea outlined.Also, Dmitry, if you have interest in working on the implementations
for these RFCs I'm sure Joe would appreciate the help (I know I
would).
Joe was able to get it mostly completed in a really short period of
time, but there is some issue going on with opcache. I have forgotten
the details now, but I think it had to deal with the fact that the
types need to have delayed binding. Joe or Anthony, can you maybe give
more information here?
Additionally, the implementation was built off of master because it
was created before PHPNG; I think I probably want to target PHP 7
instead of 5.7 (again, PHP 7 was only being dreamed of then) so it
would need rebased at least. Here's the work by Joe and Anthony:
https://github.com/krakjoe/php-src/compare/returntypehinting
The patch looks good and seems to contain the necessary opcache changes.
I'm not sure if you really need zend_return_hint.used and
zend_return_hint.class_name_type (may be I just didn't analyze the patch
deep enough).
You may support "self" by setting zend_return_hint.class_name =
GC(actrive_class_entry)->name.
If return type hinting is unused then zend_function. return_hint should be
NULL
In PHP7 it may make sense to embed fields of zend_return_hint (zend_string
return_class_name and zend_uchar return_type) directly into zend_function.
It may keep the same memory usage for cases without return type hinting and
decrease it with return type hinting.
Thanks. Dmitry.
On Tue, Aug 19, 2014 at 8:23 AM, Levi Morrison morrison.levi@gmail.com
wrote:
Hi Levi,
The implementation is really not a problem. It must be quite simple and I
may take care about it.
The problem that we can't come to agreement on scalar type hinting for
years
:(Thanks. Dmitry.
On Mon, Aug 18, 2014 at 9:57 PM, Levi Morrison morrison.levi@gmail.com
wrote:I see your point. For me they just don't have a lot of sense without
each
other.I am the author of two of those RFCs. I've worked with several members
of the HHVM team so that any inconsistencies are planned and recorded
(or will be; I know of one inconsistency in return types that is not
currently recorded).I also am definitely not in favor of merging them, for the reasons
Andrea outlined.Also, Dmitry, if you have interest in working on the implementations
for these RFCs I'm sure Joe would appreciate the help (I know I
would).Joe was able to get it mostly completed in a really short period of
time, but there is some issue going on with opcache. I have forgotten
the details now, but I think it had to deal with the fact that the
types need to have delayed binding. Joe or Anthony, can you maybe give
more information here?Additionally, the implementation was built off of master because it
was created before PHPNG; I think I probably want to target PHP 7
instead of 5.7 (again, PHP 7 was only being dreamed of then) so it
would need rebased at least. Here's the work by Joe and Anthony:
https://github.com/krakjoe/php-src/compare/returntypehinting