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

triangular dispatch (left-to-right template parameter chaining) #3766

Closed
timholy opened this issue Jul 19, 2013 · 8 comments
Closed

triangular dispatch (left-to-right template parameter chaining) #3766

timholy opened this issue Jul 19, 2013 · 8 comments

Comments

@timholy
Copy link
Member

timholy commented Jul 19, 2013

If it wouldn't cause the very foundations of the type system to crumble, it seems like it would be nice to be able to do this:

colorspace{C<:ColorValue,A<:AbstractArray{C}}(img::A) = string(C)

Use case: given an inheritance pattern

Image{T,N,A<:AbstractArray} <: AbstractImageIndexed{T,N} <: AbstractImage{T,N} <:AbstractArray{T,N}

this:

colorspace{C<:ColorValue}(img::AbstractArray{C}) = string(C)

has problems because methods like this:

colorspace(img::AbstractImage) = get(img.properties, "colorspace", "Unknown")

take precedence. One needs to use constructs like this:

colorspace{C<:ColorValue}(img::Union(Array{C},SubArray{C},Image{C})) = string(C)

Even this:

colorspace{C<:ColorValue}(img::Union(AbstractArray{C},AbstractImage{C})) = string(C)

fails to take precedence. But I have more concrete image types defined than just Image, so it would be nice to have this work more generally without having to list all of them.

There's also an example in the FAQ that might benefit from this. In that case one could solve the problem using an inner constructor, but this type-chaining would have been more natural.

@lindahua
Copy link
Contributor

+1

@JeffBezanson
Copy link
Member

It wouldn't cause the foundations of the type system to crumble, but it would cause them to be more difficult to implement :)

True that there are lots of uses of this; I have wanted it a few times myself.

In this particular case, AbstractImage is still more specific than AbstractArray{C} even with this feature. It should work to define the method for AbstractImage{C}.

@timholy
Copy link
Member Author

timholy commented Jul 19, 2013

That's a helpful tip re AbstractImage, thanks.

@filmackay
Copy link

+typemax(Uint128)

I believe this is referred to as "triangular dispatch"? See this discussion.

@andreasnoack
Copy link
Member

Following up on #6620 here. This feature seems necessary for defining QR for arbitrary AbstractMatrix.

@andreasnoack
Copy link
Member

bump

@quinnj
Copy link
Member

quinnj commented Aug 21, 2014

Superseded by #6984? Specifically the proposal here?

@quinnj
Copy link
Member

quinnj commented Aug 29, 2014

Closing in favor of Jeff's proposal mentioned here. Feel free to reopen if that wouldn't cover the issue here.

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

6 participants