You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Which could be used as Foo{:KeyFacts}(25). constructorof returns just Foo
Then the following issue occurs:
julia>constructorof(Foo{:ABC})
Foo
julia>constructorof(Foo{:ABC})(22)
ERROR: MethodError: no method matching Foo(::Int64)
Which is a problem.
That informatiuon is lost and i can't construct it anymore.
If the type param had been used it could be deduced from the type by the default constructor, but where it isn't it can not
I assume the reason for this is that uses like Setfield.jl might change the type of one of the fields and so for type-parameters that are used it wants them to removed to hit the default constructor.
I am not sure on the solution to this.
My own use case is same type in, same type out.
So one option is to expose a duplicate of setproperties and of constructorof that always has the same type.
It is a bit ugly though.
For the special case where all the type parameters are unused, we could detect that by them never occuring in fieldtypes.
And then we know that it is safe to generate the constructor that has the type parameter set.
But that doens't work for cases where some are used and some are not.
Though for many of these case that i have seen in the wild they have just one unused type parameter and the rest used, and expose a constructor FooBar{C}(a::A, b::B) where {A,B,C}
The text was updated successfully, but these errors were encountered:
Thanks, yes that is an issue that pops up every now and then.
I assume the reason for this is that uses like Setfield.jl might change the type of one of the fields and so for type-parameters that are used it wants them to removed to hit the default constructor.
yes
For the special case where all the type parameters are unused, we could detect that by them never occuring in fieldtypes.
That is certainly possible. However we decided against using any heuristics like this and instead recommend to either design types differently or overload constructorof(::Type{<:Foo}). See also #27.
Consider a type like:
Which could be used as
Foo{:KeyFacts}(25)
.constructorof
returns justFoo
Then the following issue occurs:
Which is a problem.
That informatiuon is lost and i can't construct it anymore.
If the type param had been used it could be deduced from the type by the default constructor, but where it isn't it can not
I assume the reason for this is that uses like Setfield.jl might change the type of one of the fields and so for type-parameters that are used it wants them to removed to hit the default constructor.
I am not sure on the solution to this.
My own use case is same type in, same type out.
So one option is to expose a duplicate of
setproperties
and ofconstructorof
that always has the same type.It is a bit ugly though.
For the special case where all the type parameters are unused, we could detect that by them never occuring in
fieldtypes
.And then we know that it is safe to generate the constructor that has the type parameter set.
But that doens't work for cases where some are used and some are not.
Though for many of these case that i have seen in the wild they have just one unused type parameter and the rest used, and expose a constructor
FooBar{C}(a::A, b::B) where {A,B,C}
The text was updated successfully, but these errors were encountered: