JuliaGeometry / JuliaGeometry/CoordinateTransformations.jl
Functor overloading for custom types?
Nobody has claimed this yet.
- Dominant language
- Julia
- Stars
- 185
- Forks
- 24
- PR merge metrics
- No merged PRs in 30d
Description
I am trying to figure out what is the correct way to overload the transformation functors for custom types? For example, if I want to be able to transform something like GeometryBasics.Line then I can not simply implement:
function (tform::CoordinateTransformations.Transformation)(l::Line)
Line((tform.(l))...)
end
since the call to the functor then becomes ambiguous (There are methods with a more specific Transformation subtype but a less specific argument type (input to the transformation)). So instead I would overload the functor for concrete subtypes of Transformation, e.g.:
function (tform::CoordinateTransformations.AffineMap)(l::Line)
Line((tform.(l))...)
end
function (tform::CoordinateTransformations.LinearMap)(l::Line)
Line((tform.(l))...)
end
But this does not seem very clean since it leads to a lot of code duplication.
Is there some kind of best practice for this? Should I not be overloading these functors at all (since it may be considered type piracy) but instead define my own thin wrapper like apply_transformation(tform, x)?
It may be good to have some brief documentation on this somewhere in the README.
Contributor guide
No contributing guide indexed for this repository
First steps
- Read the whole issue, then the project's contributing guide.
- Comment on the issue to say you are picking it up — it saves two people doing the same work.
- Fork the repository and make your change on a branch.
- Open a pull request that references the issue number.
Research direction
Start by reviewing the existing transformation functor methods and the README, focusing on how custom types such as GeometryBasics.Line can extend transformations without ambiguous dispatch. Document the established recommendation, including whether direct functor methods or a wrapper is preferred, with a concise custom-type example; the README should make the extension path clear.
Written by the indexing model from the issue text.
Assessment
- Tech stack
- julia
- Domain
- documentation
- Issue type
- Documentation
- Difficulty
- 4/5
- Estimated time
- 3-5 days
- Activity status
- Stale
- Clarity
- Mostly clear
- Newbie friendliness
- 35/100