Email or username:

Password:

Forgot your password?
Ben's posts Post Back to profile
Top-level
Ben Ramsey

@gmazzap @cabbey I see a lot of libraries written in TS but distributed already transpiled. How does that enforce anything?

In the case of PHP, there would not be a transpile step. The erased types would mainly be fancy syntax as hints to tools like IDEs.

7 December at 17:36 | Open on phpc.social
5 comments
Giuseppe Mazzapica

@ramsey @cabbey TS libs shared transpiled is not TS fault.

For PHP, my point is that erased types could be useful if they would be only usable in a different format that would require "check + erasure" before being consumed by the engine. People could still distribuite "already erased" version of their code, but that's on them. Those who distribuite the non-erased version would force consumers to do that step. And if Composer could do it on install, that would require no change on devs workflow

7 December at 17:53 | Open on phpc.social
Ben Ramsey

@gmazzap @cabbey The problem right now is that many users already don’t use the tools that will enforce these things. I don’t think adding an extra transpile step will help at all. It’ll just annoy developers.

7 December at 18:00 | Open on phpc.social
Giuseppe Mazzapica

@ramsey @cabbey Imagine the scenario. There's a new .phps format that allows advanced types, generics, etc. The engine can *not* consume it. Composer recognizes it and do erasure (the engine provides means to do it). If composer.json requires a library that "provides" types checks, Composer will use that library to check the code before erasure. This would have no impact on people who do not want to type-check, but would empower a lot people who want to use advanced types, etc.

7 December at 18:17 | Open on phpc.social
Ben Ramsey

@gmazzap @cabbey > This would have no impact on people who do not want to type-check

This is the problem.

7 December at 18:51 | Open on phpc.social
Go Up