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
As mentioned in the tour Legolas 0.5 will ignore additional fields passed into the constructor and does not propagate these fields to the resulting record. Something the tour fails to mention however is that only the Record(row) constructor will ignore these extra fields and the keyword constructor will throw an exception when additional fields are passed to it:
julia>using Legolas:@schema, @version
julia>@schema"example.foo" Foo
julia>@version FooV1 begin
a::Real
b::String
c
d::AbstractVectorend
julia> fields = (a=1.0, b="hi", c=π, d=[1, 2, 3], e=true)
(a =1.0, b ="hi", c = π, d = [1, 2, 3], e =true)
julia>FooV1(fields)
FooV1: (a =1.0, b ="hi", c = π, d = [1, 2, 3])
julia>FooV1(; fields...)
ERROR: MethodError: no method matching FooV1(; a=1.0, b="hi", c=π, d=[1, 2, 3], e=true)
Closest candidates are:FooV1(; a, b, c, d) at ~/.julia/packages/Legolas/C9kX7/src/schemas.jl:500 got unsupported keyword argument "e"FooV1(::Any) at ~/.julia/packages/Legolas/C9kX7/src/schemas.jl:497 got unsupported keyword arguments "a", "b", "c", "d", "e"
Stacktrace:
[1] kwerr(kw::NamedTuple{(:a, :b, :c, :d, :e), Tuple{Float64, String, Irrational{:π}, Vector{Int64}, Bool}}, args::Type)
@ Base ./error.jl:165
[2] top-level scope
@ REPL[20]:1
I can see us making a distinction in the behaviour between these two constructors however we should document this difference.
Originally noticed this when reviewing some Beacon-internal generic record construction code where I thought the intermediate construction of a NamedTuple could be eliminated.
The text was updated successfully, but these errors were encountered:
As mentioned in the tour Legolas 0.5 will ignore additional fields passed into the constructor and does not propagate these fields to the resulting record. Something the tour fails to mention however is that only the
Record(row)
constructor will ignore these extra fields and the keyword constructor will throw an exception when additional fields are passed to it:I can see us making a distinction in the behaviour between these two constructors however we should document this difference.
Originally noticed this when reviewing some Beacon-internal generic record construction code where I thought the intermediate construction of a
NamedTuple
could be eliminated.The text was updated successfully, but these errors were encountered: