> Typed Clojure is one of the biggest advancements to dynamic programming languages in the last few decades. It shows that you can have the amazing flexibility of a dynamic language, while providing lightweight, optional typing.
I'm sure there have been great advances. But you are showcasing this as if it was a completely new idea, even though PHP has been using it for a long time. Correct me if I'm wrong.
OP here. This is substantially different than what exists in PHP. I tried to hint about this when referencing "nominal" vs "structural" in the piece, but you can just about say "I expect the parameter to be this type" in PHP, which is substantially less powerful than this.
I think we can go much farther in this area than we have with Hindley Milner. Of course, this is still research, but as long as you are claiming "biggest advance in the last few decades" I might as well just throw this out there.
I don't have a definition, I just use the thing. That's why I'm asking, I'm not a computer scientist. Eg:
$f = function helloAction(Http\Request $request) {
$response = new Http\Response("Hello " . $request->query->get('name'), 200);
$response->setMa // at this point the IDE will show a list of methods like 'setMaxAge($time)', because it knows its type
};
Now I can pass $f somewhere else, like this:
$someObject->someMethod($f);
And the method can accept it like this:
protected method someMethod($f) {} // no checks!
Or like this:
protected method someMethod(\Closure $f) {} // only an argument of type Closure will be accepted.
So those are types for me. If you are asking for something like this:
Response $r = new Response(...);
Then yeah, PHP doesn't have that. Though I don't know why we would want that, it's kind of redundant.
The redundancy can be alleviated by type inference, but it's also kind of nice. The 'Response' on the left is your expectation about what $r is, while the one on the right is your implementation of that expectation. The separation is very important.
Of course, in this example, it's silly and type inference would be used to ensure that you don't need to write the left side.
The advantage is that before running your code you can suss out much greater degrees of what your code "could possibly mean". The \Closure bit is a start, but it needs to fail prior to running to be statically typed. It also could potentially include much more information like (\Closure[Http\Request -> Http\Response]) and reject even more bad arguments.
The type system for typed closure is much more powerful and is build on solid PL research. For example, it handles higher order types, union types and has a nifty system for overloading.
I'm sure there have been great advances. But you are showcasing this as if it was a completely new idea, even though PHP has been using it for a long time. Correct me if I'm wrong.