How to integrate historical Jass data?

[Luashine]

Hey I finally finished the extraction of Jass for different game versions: https://github.com/Luashine/jass-history/

How to deal with these?

1) Old Deleted functions: I think to put them in a separate file, there aren't many 2) Renamed functions: ??? very few if any, I'd probably put them in a different file yet, for easier copy-pasting during doc updates ... but it begs the question if @alias would be worth it, there are also swapped BJ functions where it could come in handy

3) Functions with changed signatures: this is tricky. For example, when the widget type was added, some functions changed their input variable type. Other functions expanded by an argument, such as EndGame used to be takes nothing, now it takes a boolean 4) Tracking initial version: most functions have never changed since the first ROC Beta. On one hand if this was blindly added to every function, it'd create unnecessary clutter. On the other hand, if you dont add it then later you cant be certain if that's because the func was always there or the version info was never added?

Finally I don't know it it all belongs inside a @patch. I'd rather see the @since tag added just for that info and keep @patch for any changes in behavior/removal.

---

I don't have anything to do code-level comparisons with, will your perl parser cut it? I dont think so because I thought of these:

1. track variable types for variables
2. track values for variables
3. track function signatures for natives and funcs
4. track function content for regular functions (can be text-based, that isn't much)

I had looked at actboy's totally undocumented and messy parser, AST and all that stuff... if the above requirements are too much for your perl script I guess I will go the noob route and regex my way through Jass again. Like I dont think AST would be worth it really or learning how to run ANTLR or writing my own even if Jass is really easy :sweat_smile:

[lep]

First of all i would say all this historic data should be put into one (or multiple) new files, not common.j. And until i make the web interface more advanced with possible different filters i probably wont include the historic data into the DB/web interface. And especially for a function with the same name but different signatures i will definitively need to adapt the web interface and probably the database schema aswell. Re tags: you can basically invent and use whatever tags you want. If the historic data ever makes it into the webview and there are annoying annotations wrt. to the web interface we can always just not show the annotations or process them specifically. Also maybe we don't even want to show this historic data in the "canonical" web view and just make a second one?

I don't have anything to do code-level comparisons with, will your perl parser cut it?

Depends but probably not. But the Haskell parser is a real parser though. If you don't want to work with Haskell i could maybe add a JSON output, like representing the jass AST in json format. I don't know what your specific requirements are.

[Luashine]

Not exposing these in the web interface sounds great, I didn't think of it... like if ever. That'd be more of a bragging right to play with old versions and their API.

I will prototype a regex script and if like 30min aren't enough I will consider gain

[lep]

See d9817c4d699ce6aa4b177e677218894e2a85b6bb. If you've a ghc/cabal setup you should be able to run cabal run jass2json -- input.j