wurstscript / WurstScript

Programming language and toolkit to create Warcraft III Maps
https://wurstlang.org
Apache License 2.0
224 stars 30 forks source link

any plan for `plugin support`? #879

Closed PhoenixZeng closed 5 years ago

PhoenixZeng commented 5 years ago

this type of plugin // by jar spi or filter provide new compiletime magic function provide new useful annotation // the custom annotation likes useless now do something with wurstcode before compile process do something with jasscode after compile process

Frotty commented 5 years ago

As before, you can simply use vscode tasks for this. Unless there is a specific reason, why would you need a "plugin support"?

PhoenixZeng commented 5 years ago

i dont know. maybe it simpler then pr. Just a sudden thought

And you can simply use vscode tasks for this. i dont think so for all requirements

Frotty commented 5 years ago

you can simply use vscode tasks for this

i dont think so for all requirements

Hence I asked what you need proper "plugin support" for. You don't have to close the issue. It would be useful if you were to provide a specific use case. You can already define custom annotations and if your external program doesn't need access to wurst java stuff, it should work fine via vscode tasks. If you do need access, explain what you're trying to do?

i dont know. maybe it simpler then pr.

I don't understand "simpler". Whether you commit to one repo or the other, it should basically be the same amount of work? Also with a "plugin" jar you would be limited by plugin API/reflection which doesn't make things simpler imo.

If you consider your feature useful for most users, a PR would be the best thing.

If you just want to make local changes to the compiler, you can simply clone the project and use the make_for_userdir task to update your local wurstscript installation.

PhoenixZeng commented 5 years ago

Just a sudden thought

well. i don't has any requirements now. Just an idea. so i say Just a sudden thought i just saw: there are too many issue with not supported futures some looks useful for most users and some not.
maybe you can let they impl it by themselves

You can already define custom annotations

yes. but useless without callFunctionsWithAnnotation (maybe my version is low. forget it if has new futures with the annotations)

access

i don't know. it may be can provide some reflection usage

simpler

for some user plugin API simpler then whole huge compiler repo (base on let they impl it by themselves)

local changes to the compiler

Not appropriate for an active repo .Frequent pull and merge will be required (Or gradually move away from the community)