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

remove duplicate code for collocation #180

Open
wants to merge 1 commit into
base: master
Choose a base branch
from

Conversation

ArnoStrouwen
Copy link
Member

DiffEqFlux has copy pastes of some of the functions here.
They should be removed in one of the two.
SciML/DiffEqFlux.jl#773

I would also suggest deprecating passing the kernel as a symbol, to make it more uniform with the rest of the SciML interfaces, e.g. Tsit5() is used, not :Tsit5.

kernel_function,
tpoints)
if kernel isa Symbol
@warn "Passing kernels as Symbols will be deprecated"
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

You can use @deprecate here

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I wanted to do it like that at first, but I ran into issues because Julia cannot dispatch on a keyword argument, i.e. it is impossible to have two methods, one with kernel restricted to Symbol types and one with kernel restricted to CollocationKernel, and then @deprecate the Symbol method.

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I don't think you can @depreacate here, it needs this special handling. But I also don't think we should be merging deprecations to this repo: it's somewhat in freeze mode because its interface does not extend well to more cases. In that case, major dependency changes and deprecations for an old repo not getting any major benefits is not a great feel. I think this PR should just hold until there's a good reason found for it.

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Yeah without kwarg handling it's not obvious, I think the way to do it with @deprecate would be
(though it's not relevant anymore since we won't go ahead with the PR, but it might be useful later)

my_func(args...; kwarg_to_deprecate::Union{T1,T2}, kwargs...) = my_func(args..., kwarg_to_deprecate; kwargs...)

my_func(args..., kwarg_to_deprecate::T1; kwargs....) = do something...

@deprecate my_func(args..., kwarg_to_deprecate::T2; kwargs...) = do something....

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

Successfully merging this pull request may close these issues.

None yet

3 participants