Skip to content

Rename the Taffy struct #449

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

Closed
nicoburns opened this issue Apr 18, 2023 · 4 comments · Fixed by #580
Closed

Rename the Taffy struct #449

nicoburns opened this issue Apr 18, 2023 · 4 comments · Fixed by #580
Labels
breaking-change A change that breaks our public interface documentation Improvements or additions to documentation usability Make the library more comfortable to use
Milestone

Comments

@nicoburns
Copy link
Collaborator

What problem does this solve or what need does it fill?

The Taffy struct is not particularly descriptively named, especially now that taffy also has a low-level API and the Taffy struct doesn't represent the only API

What solution would you like?

Give the Taffy struct a better name. Suggestions:

  • DefaultTree / DefaultLayoutTree
  • SimpleTree / SimpleLayoutTree
  • TaffyTree / TaffyLayoutTree

We could also consider renaming the LayoutTree trait at the same time if that would help.

Additional context

We may also want to make the Taffy struct generic in future for two purposes:

  • To allow for both Send + Sync and non-Send + Sync measure functions. The former is required to allow Taffy instances to be moved between threads, but the latter is necessary in contexts like WASM where measure functions from JS typically won't be Send.
  • To allow a context to be provided for passing into measure functions (which would effectively allow them to borrow from their environment.
@nicoburns nicoburns added documentation Improvements or additions to documentation usability Make the library more comfortable to use breaking-change A change that breaks our public interface labels Apr 18, 2023
@nicoburns
Copy link
Collaborator Author

@alice-i-cecile @TimJentzsch @Weibye thoughts?

@TimJentzsch
Copy link
Collaborator

I agree that the name should be changed as the current one is not descriptive enough.
But I am not sure which one would be the best alternative.

Maybe TaffyLayoutTree as it implements the LayoutTree trait and is specific to taffy... but maybe other options would be better.

@alice-i-cecile
Copy link
Collaborator

TaffyLayoutTree seems like a solid improvement.

@nicoburns
Copy link
Collaborator Author

#490 brings a new dimension to this issue by introducing a type parameter to the Taffy struct. As things stand, this means that you have to do something like let mut taffy: Taffy<MeasureFunc<()>> = Taffy::new(); or let mut taffy: Taffy<SyncMeasureFunc<()>> = Taffy::new(); (if you want the Send+Sync bound) to initiate a Taffy instance. I'm wondering if we ought to do something like:

  • Rename Taffy<Measure> to GenericTree<Measure>
  • Add type DefaultTree = Taffy<MeasureFunc<()>>
  • Add type SyncTree = Taffy<SyncMeasureFunc<()>>

and perhaps:

  • Add type DefaultTreeWithContext<Context> = Taffy<MeasureFunc<Context>>
  • Add type SyncTreeWithContext<Context> = Taffy<SyncMeasureFunc<Context>>

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
breaking-change A change that breaks our public interface documentation Improvements or additions to documentation usability Make the library more comfortable to use
Projects
None yet
Development

Successfully merging a pull request may close this issue.

3 participants