Giters

RealyUniqueName / haxe

Haxe - The Cross-Platform Toolkit

Home Page:http://haxe.org

Geek Repo:Geek Repo

Github PK Tool:Github PK Tool

untyped magic

mockey opened this issue · comments

commented

As I wrote before, I remember @Simn was not so happy with untyped __php__ and the like.
@Simn: Are there better ways to handle this, maybe already implemented in the newer generators (python, lua)?

commented

JS target uses the same approach: untyped __js__('alert(1)')

commented

untyped is bad for various reasons. It would be better to hide this as Lib.code('') or something to that extent.

commented

So should new generator support untyped or implement somethind like Lib.code() instead?

commented

I guess we should still support untyped __php__ but encourage the alternative.

commented

So what's the approved alternative? )

commented

I don't really have a strong opinion about that, any normal field call will do.

commented

I think php.Lib.code is short and clear.
Can you use php as PHP namespace BTW?

commented

Additionally php.Lib.call maybe var should be done differently, physeq is not needed I think. At least it wasn't in the old phpgen, don't know how you handle equality.

commented

In python we have python.Syntax and there's stuff for generating python expressions.

commented

I don't really see how it would make much difference compared to untyped though. It can be even worse, because untyped __php__ is an unbound var, while something like php.Syntax.pythonCode is a normal function call from the analyzer POV, and it's going to make assumptions that it's a normal call, not something "magic" that is handled in the generator.

commented

Yes but this allows us to introduce some @:magic metadata for the analyzer. In the long run I would like to get rid of unbound variables entirely.

commented

Have you guys looked at the solutions used by Typescript and scala.js for this general problem of calling into untyped external code? I know they're JS rather than PHP, but it's the same basic issue. They let you define a typed interface, like this scala.js for the Google maps JS lib:

trait MapOptions extends js.Object {
  var backgroundColor: String = js.native
  var center: LatLng = js.native
  var disableDefaultUI: Boolean = js.native
  var disableDoubleClickZoom: Boolean = js.native
...
}

I know it seems a bit of a pain, but they don't take long to knock up, and Typescript has a cool shared repo of these interfaces for all kinds of JS libraries.

You can then call methods and create objects from those JS libraries in a type-safe way, and the generated code is optimal too.

commented

untyped is my biggest pain point currently (I'm writing a Wordpress plugin in Haxe and need to call into Wordpress functions loads) and I'd love to see it get a lot slicker. To take another example from how scalajs handles things, if you don't setup an interface (as above), you can just do this:

var arg2 = 3;
js.Dynamic.global.some_external_func("arg1", arg2)

Admittedly there's no more type-safety than with untyped, and scala.js has no idea whether some_external_func exists and how many args it takes, I just think it's a bit easier to read and write that than:

untyped __php__('some_external_func("arg1", $arg2)');

I can more easily see the arguments, at least. Maybe this syntactic sugar is possible?

commented

Haxe has the same concept called externs: https://haxe.org/manual/lf-externs.html

commented

Ah amazing, thank you. I'm very new to Haxe, these look great.

commented

Implemented php7.Syntax which purpose is to replace all untyped code: https://github.com/RealyUniqueName/haxe/blob/php7/std/php7/Syntax.hx