JuliaGeometry / JuliaGeometry/CoordinateTransformations.jl

Functor overloading for custom types?

Open
#65 13 comments 1 reaction 0 assignees View on GitHub

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

  1. Read the whole issue, then the project's contributing guide.
  2. Comment on the issue to say you are picking it up — it saves two people doing the same work.
  3. Fork the repository and make your change on a branch.
  4. 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

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.