Skip to content

[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

Open
wants to merge 3 commits into
base: experiment/static-fields
Choose a base branch
from

Conversation

lemz1
Copy link

@lemz1 lemz1 commented Mar 1, 2025

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:

  • use macro 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 the project.xml, build.hxml, or whatever build system you use.
  • ability to extend scripted classes
  • abitily to create classes that dont extend anything
  • no more scriptCall, scriptSet, etc.
  • custom constructors
  • static variables and functions

@: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
import flixel.group.FlxTypedSpriteGroup;
import flixel.FlxSprite;

class CoolObject extends FlxSprite
{
  public function new()
  {
    super();
  }
}

class CoolGroup extends FlxTypedSpriteGroup
{
  public function new()
  {
    super();
    var obj = new CoolObject();
    add(obj); // obj will be auto casted to FlxSprite

    print(obj) // won't be auto casted, since this is purely a scripted function (it doesn't override a function from FlxTypedSpriteGroup)

    trace(obj); // trace doesnt auto cast: "PolymodScriptClass(CoolObject)"
  }
  
  public function print(o)
  {
  
  }
}

EXAMPLE

CoolObject.hxc
package mod1;

import flixel.FlxSprite;

class CoolObject extends FlxSprite
{
  var time:Float = 0;

  public function new(color:Int)
  {
    super();
    makeGraphic(1280, 720, color);
  }

  public function update(elapsed:Float):Void
  {
    super.update(elapsed);
    time += elapsed;

    y = (360 - height / 2) + Math.cos(2 * time) * 60;
  }

  public function offsetTime(value:Float):Void
  {
    time += value;
  }
}
CoolerObject.hxc
package mod2;

import mod1.CoolObject;
import flixel.group.FlxTypedSpriteGroup;
import flixel.FlxSprite;

class CoolerObject extends CoolObject 
{
  var offsetTimer:Float = 0.0;

  public function new()
  {
    super(0xff00ff00);
    setGraphicSize(640, 360);
    screenCenter();
  }

  public function update(elapsed:Float):Void
  {
    offsetTimer += elapsed;

    if (offsetTimer >= 1.0)
    {
      offsetTimer = 0;
      offsetTime(1.25);
    }

    super.update(elapsed);

    x = (640 - width / 2) + Math.sin(2 * time) * 120;
  }

  public function offsetTime(value:Float)
  {
    super.offsetTime(2.0 * value);
  }
}

class CoolGroup extends FlxTypedSpriteGroup
{
  var obj:CoolerObject;
  public function new()
  {
    super();
    obj = new CoolerObject();
    add(obj);
  }
}

@lemz1 lemz1 marked this pull request as draft March 1, 2025 20:16
@TheRealJake12
Copy link

really cool stuff

@lemz1 lemz1 force-pushed the feature/new-polymod-script-class-implementation branch from 659bb9e to a10e448 Compare March 9, 2025 19:16
@lemz1 lemz1 marked this pull request as ready for review March 9, 2025 19:16
@lemz1 lemz1 force-pushed the feature/new-polymod-script-class-implementation branch from f303727 to 3ad243c Compare March 9, 2025 19:20
@AbnormalPoof
Copy link

AbnormalPoof commented Mar 9, 2025

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?

@lemz1
Copy link
Author

lemz1 commented Mar 9, 2025

is it possible to use classes that don't extend anything?

yes

@lemz1 lemz1 force-pushed the feature/new-polymod-script-class-implementation branch from bb091fa to 989b2b8 Compare March 11, 2025 18:29
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
@T5mpler
Copy link

T5mpler commented Mar 27, 2025

Holy good PR

@EliteMasterEric
Copy link
Collaborator

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.

@lemz1
Copy link
Author

lemz1 commented Apr 7, 2025

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.

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.

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.

noted, will work on re-adding them for backwards compatibilty Finished

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

6 participants