[RFC] Generalize some fallbacks #29
Conversation
Codecov Report
@@ Coverage Diff @@
## master #29 +/- ##
==========================================
- Coverage 45.25% 41.89% -3.37%
==========================================
Files 1 1
Lines 137 148 +11
==========================================
Hits 62 62
- Misses 75 86 +11
Continue to review full report at Codecov.
|
| function set_source(gc::GraphicsContext, c::Color) | ||
| rgb = convert(RGB, c) | ||
| set_source_rgb(gc, rgb.r, rgb.g, rgb.b) | ||
| c isa AbstractRGB && return set_source_rgb(gc, red(c), green(c), blue(c)) |
There was a problem hiding this comment.
Maybe slightly cleaner with dispatch but no big deal either way
There was a problem hiding this comment.
I almost forgot the original intent, but the specialization can introduce ambiguity in the backend implementations.
Of course, it is possible to dispatch "private" methods.
| """ | ||
| device_to_user!(gc::GraphicsContext, c::Vector{Float64}) = c # TODO: generalization | ||
| function device_to_user!(gc::GraphicsContext, c::AbstractVector{T}) where T <: Real | ||
| length(c) == 2 || throw(ArgumentError("Only 2-D vectors are supported.")) |
There was a problem hiding this comment.
| length(c) == 2 || throw(ArgumentError("Only 2-D vectors are supported.")) | |
| length(c) == 2 || throw(ArgumentError("Only length-2 vectors are supported.")) |
| """ | ||
| user_to_device!(gc::GraphicsContext, c::Vector{Float64}) = c # TODO: generalization | ||
| function user_to_device!(gc::GraphicsContext, c::AbstractVector{T}) where T <: Real | ||
| length(c) == 2 || throw(ArgumentError("Only 2-D vectors are supported.")) |
There was a problem hiding this comment.
| length(c) == 2 || throw(ArgumentError("Only 2-D vectors are supported.")) | |
| length(c) == 2 || throw(ArgumentError("Only length-2 vectors are supported.")) |
|
IMO, it is better to add tests before making any changes. However, implementing a new backend for testing is not very productive, and it may contain bugs. |
2 participants
When I was working on PR #22, I thought some of the fallbacks weren't pretty good.
However, as it stands, Graphics.jl does not really play a role as an abstraction layer, so I have doubts about the necessity of making these changes.