Open Luashine opened 10 months ago
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.
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
See d9817c4d699ce6aa4b177e677218894e2a85b6bb.
If you've a ghc/cabal setup you should be able to run cabal run jass2json -- input.j
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 handy3) 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 asEndGame
used to betakes 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:
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: