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
@:native
for structure fields
#32
Conversation
I can work on implementing this, but I need some review and approval of the idea by @ncannasse and/or @Simn first. |
I think an easier version would be to allow In that case it might still be escaped as _enum or $enum or something else if |
That would also require some field access syntax like What should we do? |
Uhm right, I didn't took field access into account, and we don't want to
allow either value."enum" or value["enum"]
…On Thu, Oct 5, 2017 at 11:10 AM, Dan Korostelev ***@***.***> wrote:
I think an easier version would be to allow { "enum" : 5 } and have it
typed as { "enum" : Int } (both would be allowed in terms of Haxe syntax).
That would also require some field access syntax like schema."enum", but
yes that would also do the job. Althought I thought you were against
exactly this in HaxeFoundation/haxe#2185
<HaxeFoundation/haxe#2185> and asked for the
@:native proposal.
What should we do?
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
<#32 (comment)>,
or mute the thread
<https://github.com/notifications/unsubscribe-auth/AA-bwC6fntHsUG07GeneBtRCiwTgoEb5ks5spJzwgaJpZM4PuQSV>
.
|
While I can see why we don't want the general Btw, I think C# has |
Anyway, I'm waiting for directions on what to do next: proceed with the proposed |
While I think it would be nice to be able to use |
@Simn what do you think about us allowing |
Well, let's talk about consistency here:
That doesn't strike me as good design. Allowing |
I am bringing this up again: #22. I suppose in some other languages there are concepts of contextual keywords (e.g. IMO, we could implement that step by step. As starter, |
@Simn Ultimately, I think it would make sense to allow |
can we go with |
I fail to see how that would even work, for instance with this: typedef Args = { var x : Int; @:native("new") var y : Int; };
class Test {
static function foo() return { x : 0, y : 0 };
static function main() {
var v : Args = foo();
}
} If it's just to allow assigning literals I think it's not good enough. |
The fun fact is that on js you can use keywords as object field:
|
@ncannasse well |
Seriously, people? I covered this exact case in the proposal... |
Sorry I misunderstood Nicolas's comment. Yeah, the example case makes sense. |
I think the keyword stuff is a bit off-topic here, sorry for bring that out at first place. (but I still hope it could be re-considered) |
Ok, I forgot that you have dealt with it in the proposal, sorry. Reading again the whole thing, while I'm still not 100% satisfied with the solution, I don't have either a better proposal to make at this point, so feel free to move forward with the change. |
Any news on this? |
I also need this for dealing with externs for various projects, most lately: Blender externs. |
I have a branch somewhere... Will try to find, revive it and get into Haxe 4 |
It bothers me that this affects unification... It shouldn't be necessary to have typing jump through hoops because the syntax is insufficient to express what you want to express. It's not even strictly related: The shortcoming here is in the field-access syntax, and our solution is to meddle with the struct declaration and its unification behavior. I don't know if we're still voting, but this one would get a "meh" from me. I acknowledge the problem, but I don't think this is the best solution. |
Well, but the problem is severe and the fix like this, even temporary would be appreciated, also I don't think the change in the code base will be that intrusive. Anyway, suggestions are always welcome :) |
I still think |
I don't know anything about the compiler or unification, but I can add from a user's perspective the original proposal matches exactly what I expect to happen based on how I think the |
I'm in favor of allowing |
…in a context * still there are weird errors but code is less complex * noticed when using typedefs, everything is broken. Give your vote HaxeFoundation/haxe-evolution#32
It seems like we will need some sort of solution to this problem in the near future for haxe js (well, react): React will most probably drop I'm not even sure |
How would Anyway, it feels like I'm on a different planet than everybody else here. So if you want to go ahead with |
It also solves the
We'd just need an error stating that single quotes are not allowed for quoting field names. Or allow string interpolation here..? As for |
You can't interpolate in field names in ObjectDecl already And it is quite consistent as well. I mean |
Yep 👍 What about typing this with typedefs? Would it be |
I'm gonna close this proposal as it's clear that we don't have consensus. As I mentioned before, I think |
Do you have a strong opinion against |
just thinking more on induction: and more idea (mostly a general identifier quote):
oopsi think i found something good? any cons please?
examples: typedef JsonSchema = {
var \enum:Array<JsonValue>;
}
schema.\enum = [1,2,3];
print(schema.\enum);
var \var = 1;
const { \class, \for } = prop;
// maybe allow omitting \ on "xxx" when possible?
someHaxeDiv.style.\"background-color" = rgb(234,130,32); // just demo
{\"background-color": rgb(234, 130, 32)} |
FWIW I implemented |
So this issue can only be tackled at the call side and not at the definition side? |
With |
Ah that sounds great! |
I can't wait for this. |
Rendered version
See HaxeFoundation/haxe#5105 and HaxeFoundation/haxe#2185