Parse actual haxe code files into scripts on the fly

[NicoM1]

I'd like to implement a way for the script parser to take a full haxe file, and parse it into a script. I don't mean it would handle everything for you, you would still have to ensure your script has access to everything you need, but you would at least have code-completion that way. It would also require some extra comment syntax (I'm not smart enough to determine where a function ends, without a direct ending character) IE: public function update() {

}//|

That way they could be cleanly parsed. I could also add comment codes to allow you to have your variable declarations just get glued to the start of the @init function. (but not all of them, that way you can still get code completion for things that you are getting at runtime using request tags, by just specifying empty private variables of the right type, with the same name).

[NicoM1]

Imports could be parsed in fairly easily too (I think?) which might be nice, but I would still only load them at startup, it would really just be an alias for expose tags

[NicoM1]

Well imports are put in for regular scripts, that should pave the way for the above

[Ohmnivore]

I took a look at the entire scripting feature ,and it's awesome. I have always thought that hscript's weakness was the fact that you had to manually "share" classes with the script. The idea of adding a layer of scripting atop of hscript never occurred to me. Really cool solution. I know it might be early for that sort of stuff, but I'm gonna point it out anyways; you gotta restrict some imports like classes dealing with the filesystem, or you can end up running arbitrary code with complete filesystem access.

I know it's paranoid, but I know it's possible to hide an exe's content as a string. Let's imagine someone decides to write a script that patches the game's exe, replacing it by a malicious version of the old exe. Next time the unsuspecting user runs the game, bam he gets keylogged. Maybe the anti-virus issues a warning or not, but the user ignores it: "It's just a game right? I ran it before and it didn't seem malicious...".

Some games might need filesystem access, but most games don't require that so I think it would make sense to add an option somewhere to disable imports of classes dealing with the filesystem when parsing the expose tags.

[NicoM1]

@Ohmnivore great minds think alike;) check the documentation, features to do that stuff have been in since I added scripting:D you can full on stop access to expose tags, only allowing classes you add directly to the pool, or you can "blacklist" specific class paths, and the game will throw an error if a script attempts access:) Glad I'm not the only one who thought this would be useful!:D

[NicoM1]

btw, just so you know, the "imports" I mention above are not new, its just a different syntax, before you had to handle them in your main xml file, now they can be live-scripted like everything else:)

[NicoM1]

I'm starting to think this idea is too hacky, yes, completion would be nice, but it would make ugly, weird code files that neither conform to proper haxe, or IceEntity scripts, if completion is really needed, you can always code the larger parts in a component, and then copy it out to a script, most syntax should be the same, e.g: "owner" still references the entity... (closing this)

[Ohmnivore]

Okay, so here's how I wanna parse a .hx file.

Imports: First off, split the file's content at every ";" character. Iterate over the results, if an item's first 6 characters are "import", then retrieve the class name with substring and load that.

Although I do have an idea for retrieving function content "directly", I think it can be done easier if you replace the current way of doing it (@function_name) by //function_name. That way the IDE/syntax highlighter considers it as a comment. Of course that means that there shouldn't be more than one //update in the file, for example, but if you explicitly state that in the README it's not much of a problem.

Oh just noticed you were closing the functions with "|". I have an idea for that too, I'll write it in the next comment.

[Ohmnivore]

BTW I forked this repo so I'll try implementing all of this today.

Okay so for determining where a function ends:

Let's say we know where the function starts. Now we iterate over the next characters. For every "{" found we add 1 to a counter initialized to 0. For every "}" found we subtract 1 to the counter. When the counter reaches 0 again, we know that we just found the closing brace.

[Ohmnivore]

Oh and for request we can once again use comments, like "//request something"

[NicoM1]

@Ohmnivore really glad you thought about how to close functions, I was pretty sure if I thought about it for a while I could figure it out, but I just hadn't got around to it and likely wouldn't have, your solution is really nice and clean:)

[gamedevsam]

I recommend using Haxe metadata syntax to implement requests, instead of using comment syntax. Something like @requires("something") before the class declaration. It's cleaner, fits better with the Haxe language spec, and less error prone, for example, here's a legitimate comment that would cause issues: //requires more work

[NicoM1]

hmm, interesting idea, I wish it could be just like imports, but with a different keyword:/ one other way actually: we could make request just be imports that start with pool.MyRequest (pool is probably a rare package name), but idk if thats a very elegant solution...

[Ohmnivore]

I think gamedevsam is right. At least it's the most syntactically correct way to do things, and we're not fooling the user by transforming "that" into "this". I know zero about haxe metadata though, so I'll read about it.

[NicoM1]

can we use haxe metadata when the class isn't actually getting compiled though? These "classes" are really just a way of organizing sections of hscript...

[Ohmnivore]

Oh wait I forgot we were going to use @requires("something") just to keep the auto-completion happy. We don't actually need to implement it xD

[NicoM1]

wow....so did I....this gets way more confusing than you would think.... btw, just cloned your fork, (annoyingly github wont let me fork it...) I'm gonna try and change some of the things I noted, then I'll add it as a branch and create a pull so we can discuss it...

[NicoM1]

hmm, just tested, typeing request Player; does not screw up completion at all, and since it doesn't have to be compiled, that seems like the cleanest syntax to me at least...

[NicoM1]

oh also, I never mentioned why I used "expose" instead of "import", at least in my opinion, its a way of differentiating the two, because there is one big difference: If a class is not already "imported" someone in your actual compiled code, you are unable to "expose" it to your script....

[NicoM1]

closing, discussion can be moved to #13