Hi list !
As someone who wants generics in PHP, please make the generics opt-in
(via INI setting or declare()) - PHP is slow enough as it stands now -
and adding reified generics will just make it even slower.
I was very sad to see that the only feasable kind of generics (type
erased) in PHP had its RFC declined.
By making the reified generics opt-in, extension authors may still
implement type erased generics and thus avoid the performance penalty -
altough as extension cannot change PHP parsing - their would rely on two
small changes to PHP itself (please see below)
Imagine two ways forward (to type-erased generics):
-
By wrapping generic "expressions" in comments ie.: $x = new
Collection/<int>/();
all IDEs would have no problems with generics - The community
might even make plugins for all popular IDEs that check such generic
expression against the codebase from inside the IDE (the place where it
actually matters) - I did one as an expieriment a while back for VSCode
myself -
We might of course also imagine the slighty more troublesome path
forward:
Two new tokens were added to PHP:
|< (interpreted as /*)
and
| (interpreted as */)
This option would of course need IDE plugins to be updated to understand
the new syntax
Regardless of going with 1 or 2, at compile time, all PHP would have to
do was to substitute generic function/method parameters (such as T, K or
V) with mixed
ie (in a class Collection/<T>/ :
.
public function add(T $item) : T {
}
T would be replaced by mixed - PHP would have to have a known list of
such generic type parameter names (T, K, V - but it might be
configurable as an INI setting)
A declare() at the top of a file could hint the compiler if this file
needs the replace / if it uses generics
This approach would then leave the actual checking of the validity of
any generic expressions/code to an extension (written in C) for instance
via a method such as:
/* {{{ proto int myextension_check_generics(string $dir)
Verify usage of generics in $dir recursively */
PHP_FUNCTION(myextension_check_generics)
{
....
RETURN_TRUE
}
This extension function would basically do what Psalm etc. do today -
just in C for much better performance
I am well aware that the internals list is set on reified generics, but
I still think that that would be another wrong turn by PHP (just like
the pipe operator and more)
I do agree that the wrapping |< and >| appears ugly but just wanted
something that required as few changes as possible.
Just my 5 cents...
/Henrik
--
Med venlig hilsen
Henrik Skov
/HSK Consulting/
Blegdamsvej 128B, 4
DK-2100 Copenhagen O
Tel.: +45 27 62 83 01
Email: henry.wood.dk@gmail.com
Have you heard the good word of Monomorphized Generics? Performance matches standard typed code.
In general, all talk about generics is held until September or October to not distract or bury important 8.6 release discussions. Feel free to message me directly if you’d like to talk about them.
Holly
Hi list !
As someone who wants generics in PHP, please make the generics opt-in (via INI setting or declare()) - PHP is slow enough as it stands now - and adding reified generics will just make it even slower.
I was very sad to see that the only feasable kind of generics (type erased) in PHP had its RFC declined.
By making the reified generics opt-in, extension authors may still implement type erased generics and thus avoid the performance penalty - altough as extension cannot change PHP parsing - their would rely on two small changes to PHP itself (please see below)
Imagine two ways forward (to type-erased generics):
-
By wrapping generic "expressions" in comments ie.: $x = new Collection/<int>/();
all IDEs would have no problems with generics - The community might even make plugins for all popular IDEs that check such generic expression against the codebase from inside the IDE (the place where it actually matters) - I did one as an expieriment a while back for VSCode myself -
We might of course also imagine the slighty more troublesome path forward:
Two new tokens were added to PHP:
|< (interpreted as /*)
and
| (interpreted as */)
This option would of course need IDE plugins to be updated to understand the new syntax
Regardless of going with 1 or 2, at compile time, all PHP would have to do was to substitute generic function/method parameters (such as T, K or V) with mixed
ie (in a class Collection/<T>/ :
.
public function add(T $item) : T {
}
T would be replaced by mixed - PHP would have to have a known list of such generic type parameter names (T, K, V - but it might be configurable as an INI setting)
A declare() at the top of a file could hint the compiler if this file needs the replace / if it uses generics
This approach would then leave the actual checking of the validity of any generic expressions/code to an extension (written in C) for instance via a method such as:
/* {{{ proto int myextension_check_generics(string $dir)
Verify usage of generics in $dir recursively */
PHP_FUNCTION(myextension_check_generics)
{
....
RETURN_TRUE
}
This extension function would basically do what Psalm etc. do today - just in C for much better performance
I am well aware that the internals list is set on reified generics, but I still think that that would be another wrong turn by PHP (just like the pipe operator and more)
I do agree that the wrapping |< and >| appears ugly but just wanted something that required as few changes as possible.
Just my 5 cents...
/Henrik
--
Med venlig hilsen
Henrik Skov
HSK Consulting
Blegdamsvej 128B, 4
DK-2100 Copenhagen O
Tel.: +45 27 62 83 01
Email: henry.wood.dk@gmail.com<mailto:henry.wood.dk@gmail.com