Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Syntax class for all targets #9502

Closed
4 tasks
markknol opened this issue May 28, 2020 · 4 comments
Closed
4 tasks

Syntax class for all targets #9502

markknol opened this issue May 28, 2020 · 4 comments
Labels
platform-cpp Everything related to CPP / C++ platform-cs Everything related to c# platform-java Everything related to Java platform-lua Everything related to Lua

Comments

@markknol
Copy link
Member

Was reading this page and looks like the nice type-safe and analyzer-friendly Syntax class isn't available for all targets and people still use "target magic".

I think this targets might need a Syntax class:

  • C++
  • C#
  • Java
  • Lua
@markknol markknol added platform-cpp Everything related to CPP / C++ platform-cs Everything related to c# platform-java Everything related to Java platform-lua Everything related to Lua labels May 28, 2020
@nanjizal
Copy link
Contributor

Also there does not seem to be any official polyfill provided?
I suggested something like this for Lime but instead Joshua added a complier switch in every required place, I guess simpler than checking how backwards compatible this might be, expect it would need more changes.

import haxe.extern.Rest;
@:access( js.Syntax.code )
extern class Syntax {
    #if( haxe >= "4.0.0" ) 
    public inline static function code(code:String, args:Rest<Dynamic>):Dynamic {
       return untyped js.Syntax.code( code, args );
    }
    #else
    public inline static function code(code:String):Dynamic {
        return untyped  __js__( code );
    }
    #end
}

I would expect changing C++ target without providing a polyfill that can be used for code that is required to be fairly haxe version intolerant is vital especially in the case of toolkits?

@nadako
Copy link
Member

nadako commented May 28, 2020

Note that the name Syntax doesn't make sense for bytecode targets, but we still might want to generate instructions directly.

@Aurel300
Copy link
Member

We might call it Syntax for consistency, but a Syntax.code that takes a string makes no sense indeed. For something like HashLink we might make the "code" function consume a kind of assembly, but it seems like overkill.

@Simn
Copy link
Member

Simn commented Feb 22, 2022

I'm closing this issue because it's been inactive for a long time. I'm not against such a feature, but somebody would have to look into implementing it.

@Simn Simn closed this as completed Feb 22, 2022
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
platform-cpp Everything related to CPP / C++ platform-cs Everything related to c# platform-java Everything related to Java platform-lua Everything related to Lua
Projects
None yet
Development

No branches or pull requests

6 participants