components(::ProductDomain) -> factors(::ProductDomain)?

[dlfivefifty]

I think using components for ProductDomain is a mistake, as it means something completely different. I propose calling it factors

[daanhb]

The intended purpose of components was to create a generic interface for "composite" objects which is different from getindex, and which does not depend on the nature of the composition. That does not prevent objects from using additional names (as in factors(d::ProductDomain) = components(d) or the other way around), but using different names for different composite objects makes it less useful.

[daanhb]

In other words, `components' does not mean anything specific to me, it is just a generic way to discover that an object somehow depends on other objects - regardless of what the relation is.

[dlfivefifty]

Using different names makes it more reliable and avoids bugs

[daanhb]

But you'd have to come up with lots of names, one for each type of composite object, and remember them :-) You can still implement factors for a ProductDomain, separately from having components. As long as you know you're working with a product domain, calling factors will catch cases where the domain is not like expected (if that's the type of bugs you're thinking of).

The main use case for components so far has been display. The fact that all composite objects implement components mean that I can display everything with the same generic code. Like this:

julia> using DomainSets: ×

julia> ((0..1)^2 ∪ (2..3) × (3..4.0)) × UnitDisk()
D × UnitDisk()

D = ((0.0..1.0) × (0.0..1.0)) ∪ ((2.0..3.0) × (3.0..4.0))

The only difference between a product domain and a union is × versus ∪.

[daanhb]

I agree that it a good idea to define factors for product domains, even if it is functionally equivalent to components. How about:

nfactors(d::ProductDomain) = ncomponents(d)
factors(d::ProductDomain) = components(d)
factor(d::ProductDomain, I...) = component(d, I...)

[daanhb]

closed by #93