-
Notifications
You must be signed in to change notification settings - Fork 72
[FEATURE / REWORK] New Implementation For Scripted Classes #201
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
base: experiment/static-fields
Are you sure you want to change the base?
[FEATURE / REWORK] New Implementation For Scripted Classes #201
Conversation
really cool stuff |
659bb9e
to
a10e448
Compare
f303727
to
3ad243c
Compare
This PR is really interesting, I definitely want to try this out soon. The example scripts you shown have classes that extend something, is it possible to use classes that don't extend anything? |
yes |
bb091fa
to
989b2b8
Compare
there's some compilation errors in some classes if a library isn't available and polymod is the only thing that's in a project
Holy good PR |
This one seems elaborate and will probably take a lot of time to review. I want to understand everything before I merge because it seems like a major overhaul and I'm cautious of that for obvious reasons. One thing I can say, while scriptCall, scriptSet, etc are no longer needed, some scripts may use them and if it's not significant work to implement them they can stay for backwards compatibility. |
If you have any questions you can just hit me up on discord (lemz1). Of course, you can also ask them here, but i might respond a bit later, since the notifications seem to not work properly for me.
|
QUESTION
This is a question for the maintainers of this repo.
Can I also add new features like getters and setters, or maybe even scripted enums to this pr?
Currently, I am not adding them since this pr is already extremely big.
NOTE
I think everything works, but I might have missed something. So feel free to tell me about issues that have popped up.
DESCRIPTION
This pr reworks the implementation for script classes. The changes include:
buildScriptImpls
to determine which classes can be scripted (filter can either be:my.package
,my.package.Module
,my.package.Module.SpecificClass
). the macro is used inside theproject.xml
,build.hxml
, or whatever build system you use.@:noCast
@:noCast is metadata that you can attach to an argument when calling a function. Scripted classes are automatically casted to their non scripted super class (if it exists), when parsing them to a function from a non scripted class. The reason this is done, is so that it is easier to parse scripted classes into functions from regular classes (See the example where we use
add
from FlxTypedSpriteGroup, without auto casting we would need to do:add(obj.castType(FlxSprite))
).Automatic casting is only done in functions, which have a definition in a regular class. This means when we override a function from a regular class, it will do auto casting. However, if we create a function, which doesn't exist in a regular class that we extend, no auto casting will be done.
@:noCast forces polymod to use the
PolymodScriptClass
instead of casting to the super class.@:noCast is only available in function arguments.
Code
EXAMPLE
CoolObject.hxc
CoolerObject.hxc