Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Should there be a Domain{T} supertype? #3

Closed
daanhb opened this issue Nov 28, 2023 · 0 comments
Closed

Should there be a Domain{T} supertype? #3

daanhb opened this issue Nov 28, 2023 · 0 comments

Comments

@daanhb
Copy link
Member

daanhb commented Nov 28, 2023

cfr JuliaMath/IntervalSets.jl#170 (comment)

I'd argue the contract is different for types inheriting from Domain and types implementing the domain interface.

One difference is ownership. The DomainSets package can't provide untyped fallback definitions, even if they make sense, for functions defined elsewhere. It can define untyped fallback definitions for functions specifically defined for domains (which, currently, is typically reflected in the name of the function). In the latter case, specifying the type of an object expected to be a domain to be ::Domain can be replaced by a call to checkdomain on the argument to catch any user errors.

In general it can define fallbacks only for arguments of type DomainRef, since we own that type. By inheriting from Domain{T}, a type opts-in to such fallback behaviour, without requiring its users to sprinkle their codes with DomainRef for statements that make complete sense without.

Unless I missed some kind of mechanism, not having an optional common supertype implies DomainRef's all over the place or being restricted to functions that are used only specifically in the context of DomainSets (i.e. being less generic).

@daanhb daanhb closed this as completed Jan 25, 2025
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

1 participant