Update haxe.display #8610
Update haxe.display #8610
Conversation
| var TypeParameter = "TTypeParameter"; | ||
| } | ||
|
|
||
| enum abstract Platform(String) { |
There was a problem hiding this comment.
Shouldn't this be Target? Also related to other "platform" symbols here
There was a problem hiding this comment.
Actually we should sync the entire metadata section with the new src-json/meta.json content.
There was a problem hiding this comment.
The problem is that metadata already has a target, but with a different meaning.
There was a problem hiding this comment.
We can rename that one to appliesTo maybe?
There was a problem hiding this comment.
compilationTarget, metaTarget
Not sure it's a good idea to split them up, they kind of belong together. I think it would just come down to making |
|
I'm not sure. The type definitions can exist without the json-rpc methods, which are built on top of them. In that sense it's fair that the type definitions are in std, while the json-rpc parts are not. Not sure what you mean regarding abstracts. |
|
Well, So the |
|
Right, but they still belong to jsonrpc more than they belong to haxe.display. But maybe I'm overthinking this. |
|
It's really just a trick to attach some type parameters to a String. And that String definitely belongs to haxe.display, because you need to know what the identifier of the method you want to call is. What you're doing instead right now is hardcoding that string in the test ( |
|
Ok I misunderstood what you meant. We can turn |
|
done |
#8610 must have been based on a slightly outdated version of Display.hx
Have to sync this with vshaxe. This PR doesn't include the json-rpc protocol definitions because those depend on jsonrpc.Types. I suppose they can remain in vshaxe for now and maybe be externalized later.
PR also includes some adjustments to the server tests to demonstrate a use-case for these type structures.