[Dev] Avoid generic types in struct

[ocots]

See #271 (comment).

This

struct CallableType{U}
    f::Function
end

should be replaced by

struct CallableType{T<:Function, U}
    f::T
end

[amontoison]

Abstract vs concrete type:
https://gensoft.pasteur.fr/docs/julia/1.4.1/manual/performance-tips.html#Avoid-fields-with-abstract-type-1

[ocots]

julia> mutable struct MyType{T<:AbstractFloat}
           a::T
       end

is better choice than

julia> mutable struct MyStillAmbiguousType
           a::AbstractFloat
       end

[ocots]

The same best practices also work for container types:

julia> struct MySimpleContainer{A<:AbstractVector}
           a::A
       end

julia> struct MyAmbiguousContainer{T}
           a::AbstractVector{T}
       end

[amontoison]

@ocots

help?> isconcretetype
search: isconcretetype

  isconcretetype(T)

  Determine whether type T is a concrete type, meaning it could have direct instances (values x
  such that typeof(x) === T).

  See also: isbits, isabstracttype, issingletontype.

  Examples
  ≡≡≡≡≡≡≡≡

  julia> isconcretetype(Complex)
  false
  
  julia> isconcretetype(Complex{Float32})
  true
  
  julia> isconcretetype(Vector{Complex})
  true
  
  julia> isconcretetype(Vector{Complex{Float32}})
  true
  
  julia> isconcretetype(Union{})
  false
  
  julia> isconcretetype(Union{Int,String})
  false

Union{...} is not a concrete type, which is why I recommended adding more parameters to your structure.

[ocots]

Thanks. But our model can be constructed incrementally and it may not be so costly since it is transcribed when we solve it. But the callable type are called many times so I think this is more crucial. I am updating these types.

[ocots]

@ocots Replace

CTBase.jl/src/functions.jl

Line 38 in 3275d6b

function BoundaryConstraint(f::Function, dependencies::DataType...)

by

function BoundaryConstraint(f::Function, VD::Type{<:VariableDependence})