Closed daanhb closed 5 years ago
There are no tests yet.
I've synced and went a bit further: with this pull request any iterable set of objects that implement the domain interface (implement in
and eltype
) can be grouped into a UnionDomain
. There is no intermediate conversion to domain types anymore:
julia> d = UnionDomain(1, [3.0, 4.0, 5.0])
a union of 2 domains:
1. : 1.0
2. : [3.0, 4.0, 5.0]
julia> d.domains
(1.0, [3.0, 4.0, 5.0])
julia> typeof(d)
UnionDomain{Tuple{Float64,Array{Float64,1}},Float64}
This simplified quite a bit of the UnionDomain
constructors.
Also, convert(Domain, [1,2,3])
now no longer returns a union of Point domains. It simply returns a wrapper around the array:
julia> d = convert(Domain, [1,2,3])
DomainSets.WrappedDomain{Array{Int64,1},Int64}([1, 2, 3])
julia> d.domain
3-element Array{Int64,1}:
1
2
3
julia> 1 ∈ d
true
I added a default fallback that works for anything:
convert(::Type{Domain}, domain) = WrappedDomain(domain)
This is perhaps a bit too much. We could also restrict this to specific types, such as arrays and sets.
An error will be thrown upon construction if the given domain-like object does not implement eltype
. I don't know how to check for an implementation of in
generically.
Does this look like an interesting direction to move into?
All names can change. The main way to cope with domain-like objects, rather than d::Domain{T}
objects, is via duck typing and indirection (dispatching on the eltype
, for example). I think it follows from this that any method that should work for domain-like objects needs a name that is unique to the DomainSets
package. That is the only way to convey the user's intention, and we can't use duck typing on most functions that are also used elsewhere.
I think WrappedDomain
is a great idea, for now. We can then deprecate it when the rest of the machinery is working in a "domain-type-agnostic" way, which will give errors where the code needs to be updated.
Does this look like an interesting direction to move into?
👍
Okay, I'm merging this then. The promotion code is opt-in, so it is non-intrusive except for UnionDomain
currently.
This is a start to implement some of the changes suggested in #31