Romain Canon
Gina Peter BanyardI've written about the recent #PHP #RFC to add bound erased generic types to PHP: https://gpb.moe/blog/opinion-bound-erased-generics.html
Not used to writing article, even less so articles clocking in at 2.3k words.
Thanks to my gf and @edorian for proofreading and editorial guidance :)
Not sure that this will become something regular, as writing really isn't something I enjoy most of the time.
MrMeshok
Dan Leech@Girgias I totally agree with the core argument of the article, but I don't think transpilation is an option.
If you were to use such a transpiled language you'd need to reinvent/augment lots of tooling _for each dialect_: language servers, PHP parsers, static analyzers, CS-fixers etc. and you can guarantee any particular variant will be abandonned in N years.
Transpilation is a "necessary" evil for JS and not having a transpilation/compilation step in PHP is one of the reasons I like it 😆
@dantleech any tool would need to be augmented if we had native syntax anyway. So I don't see how that's a blocker.
But if you are using static analysis you are having a "build" step anyway somewhere before you run your code for the first time.
@Girgias the difference is that toolls would be _updated_ for the official version of PHP vs. tools having to decide which transpilers to support. For SA you'd run it on the transpiled code, but you'd want to map the line numbers / positiions back to the "source" code. Basically it adds a _huge_ amount of complexity on the whole tooling stack.
@dantleech The transpiler I'm talking about would literally just be about converting a native syntax to do comments, nothing more.
Which if we add basic runtime generic type checks would means PHP-Parser would already have the syntax support.
@dantleech the whole point is that some people want both their cake and eat it. Because they want native syntax that does nothing, which wouldn't even mean you'd no longer need doc comments, and not need to have dedicated tooling that does so, instead pushing the language in a direction that affects millions of people which won't see any benefit and might even see it as detrimental.
If you so badly hate writing doc comments, then write and use the tool that allows you that.
Rubén Rubio@Girgias II love reading someone that works at PHP's core explaining the though process. So, thank you for writing this post and sharing it!
I can not really weigh in, because I do not know the internals that much. But a gradual and incremental implementation sounds like a good idea: it allows improving step by step, and seeing how it will work in real applications. Not that many people think about new features until they start using them.
@rubenrubiob Glad you enjoyed it :) a lot of it was based on notes I took discussing this with a multitude of people offline and online.
Loïc Faugeron@Girgias Adding features to PHP is great, but it shouldn't be done at the cost of core maintainers' time and sanity
Bastian Waidelich@Girgias thanks for the elaborate post.
I used to be in the camp "I do need generics in almost all of my projects, but PHPStan + some best practices on the type level already solves this". However, I changed my mind due to a fact that I think is missing from your post: The RFC suggests to expose generics to Reflection. That is a game changer for me.
Personally, I also don't share the fear that this creates massive confusion or incoherence, but I might be missing some details
@bastian those types would also be exposed in Reflection in any other generics proposal.
I'm curious to hear why you think that makes it so much more valuable as tooling will still continue to require types in doc comments for more "powerful" atomic types or function types.
@Girgias this was a counter argument towards
> one of the main arguments in favour of this RFC is that it is “nicer” to use a native syntax than doc comments
I can't really judge any of the proposals..
From a PHP users perspective I would love to see the remaining cases for types in doc comments being replaced eventually, but to me the syntax is not that important.
Reflection will allow for dynamic schema generation, meta programming, type-driven UIs, ...
@Girgias Those tools are certainly impressive, but the same argument could have been made towards doc comment annotations vs attributes and I am very happy that we do have the latter in the meantime