Hello Internals!
My friend Grigory has cooked up an exciting package implementing generics
with full runtime type checking in userland.
I honestly believe it can be surpassed only by doing a full native
implementation (which we know is fairly unfeasible from Nikita's previous
research), it's transparent to the PHP code (if disabled, the code will
still run just fine), is pretty light performance impact wise and requires
zero pre and post processing (aka "compiling") of the code. It's as
transparent for the developers as possible.
https://packagist.org/packages/grikdotnet/generics
https://github.com/grikdotnet/generics
List on what's implemented and what is possible:
https://github.com/grikdotnet/generics/blob/master/documentation/story.md#implemented
The documentation folder contains quite a bit of information :)
I'm posting this to internals for the following reasons:
-
- Seeking advice and know-how on how to improve performance
-
- Ideas on making the syntax better
-
- Explore the possibility of making changes to the PHP engine
- Improve performance
- Support extended syntax in the attributes
like #[\Generics\T(Collection<int><float>)] so it doesn't have to be a
string that needs to be parsed as it's now - Return type attributes?
- How about having a built in generics empowering attribute that
userland libraries can take advantage off and do implementations?
- Having an extended discussion of the feature and where it can be taken
going forward - Seeking help with implementing missing features, code review, etc
Grigory has signed up to the list, so you can direct all the questions in
the thread to him :)
Sincerely,
Arvīds Godjuks
+371 26 851 664
arvids.godjuks@gmail.com
Telegram: @psihius https://t.me/psihius
Grigori Kochanov grigori@grik.net
11:25 (32 минуты назад)
кому: Arvids
Hello Internals!
My friend Grigory has cooked up an exciting package implementing generics
with full runtime type checking in userland.
I honestly believe it can be surpassed only by doing a full native
implementation (which we know is fairly unfeasible from Nikita's previous
research), it's transparent to the PHP code (if disabled, the code will
still run just fine), is pretty light performance impact wise and requires
zero pre and post processing (aka "compiling") of the code. It's as
transparent for the developers as possible.https://packagist.org/packages/grikdotnet/generics
https://github.com/grikdotnet/genericsList on what's implemented and what is possible:
https://github.com/grikdotnet/generics/blob/master/documentation/story.md#implemented
The documentation folder contains quite a bit of information :)I'm posting this to internals for the following reasons:
- Seeking advice and know-how on how to improve performance
- Ideas on making the syntax better
- Explore the possibility of making changes to the PHP engine
- Improve performance
- Support extended syntax in the attributes
like #[\Generics\T(Collection<int><float>)] so it doesn't have to be a
string that needs to be parsed as it's now- Return type attributes?
- How about having a built in generics empowering attribute that
userland libraries can take advantage off and do implementations?- Having an extended discussion of the feature and where it can be
taken going forward- Seeking help with implementing missing features, code review, etc
Grigory has signed up to the list, so you can direct all the questions in
the thread to him :)
Thank you Arvid!
My intention is to attract attention to generic programming, to prove that
it's partially possible, and eventually see the implementation in the
engine.
What is missing for the system-type solutions is a way to break the
encapsulation of objects a legal way, rather than with a known hack with
unserialize()
, and to override the "final" statements in the non-userland
code like a testing suit or a system-level library.
The return type attributes would help implement generic types for return
declarations.
Quoting the basic types in attributes is actually the limitation of Nikik's
parser, not the PHP engine itself. I believe it can be done if there is a
demand for it, as well as the performance improvement.
The feedback and questions are more than welcome!
WBR, Grigori