Skip to content
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

Add typed Tileset and Layer_Tiles #35

Open
wants to merge 4 commits into
base: master
Choose a base branch
from

Conversation

Geokureli
Copy link

@Geokureli Geokureli commented Jun 19, 2024

I don't know if this is something you're interested in, but it's the direction in which I plan to take my personal fork of ldtk-haxe-api

The Problem

I find it oddly hard to write generic code for ldtk, that is useful in multiple projects or for multiple types that are built via macros. The use of macros are - I'll admit - a fucking lifesaver and make starting new projects a breeze, but I find myself copying and pasting the same utilizing code from project to project (and sometimes multiple times in the same project) and changing the class names just to get the same fields that are in every tileset or tile layer but not in the respective base classes

The Solution

Put those fields and functions in the base classes and use type params to make it easy to pass them around to generic utils without needing to know the specific generated class for each project.

The Changes

  • Rename Tileset to TypedTileset<TTag:EnumValue>, and add a untyped Tileset typedef
  • Add hasTag and getAllTags to the base class, override getAllTags in the built types, (I could also make Tileset an abstract class, but that seemed more risky, as it's a recent haxe feature, and maybe not a backward compatible change)
  • Rename Layer_Tiles to TypedLayer_Tiles<TTag:EnumValue> and add a untyped Layer_Tiles typedef. In my tools I'm using this for `@:privateAccess layer.untypedTileset
  • Add tileset field to Layer_Tiles
  • Built extensions of Tileset and Layer_Tiles now extend their typed versions

Another option, rather than having the old type as a typedef of the new typed class, we could have the typed class extend the untyped version with the newly added typed fields (just thought of this, might explore as it may resolve some covariance issues)

The future

I think there many other places that would benefit from having more generic type options, I can make an issue listing them out if there's any interest

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.

1 participant