Hi Christian,
Good news, I hope. The problem with the dynamic typecasting is not as much a typecasting-issue but an issue with recognizing derived functions. The problem is that derived functions are treated as functioncalls where it shouldn't. I can remenber that once there was an issue with the parity of derived functions. It is something like that.
attached some demos: [referentialDemo.xq] shows that dynamic and strict typing works within version-11.9 [buggyDemo.xq] shows that dynamic and strict typing fails in case of derived functions. [workingDemo,xq] show the workaround.
Thought you would like to know what the issue is.
Rob
---------- Oorspronkelijk Bericht ---------- Van: Rob Stapper r.stapper@lijbrandt.nl Aan: Christian Grün christian.gruen@gmail.com Datum: 14-05-2025 18:43 CEST Onderwerp: Re: [basex-talk] functionParameterTyping issue
As can be seen, case "a" can never work if $p is a string.
correct, the error triggered by the system when calling this function is part of the validation mechanisme. Once correctly validated the data wil be stored as XML and wil be garanteed to be a string (in this case). It is not a hidden dependency as such but a managed dependency.
Thanx for your time, Rob
Op 14-05-2025 18:01 CEST schreef Christian Grün christian.gruen@gmail.com:
It is more like: let $n := "b" let $p := "test" return switch($n) case "a" return fn( $n, $p as map(*) ) { }( ?, $p) case "b" return fn( $n, $p as xs:string ) { }( ?, $p) default return ()
As can be seen, case "a" can never work if $p is a string. If there is a (hidden) dependency in the semantics in your code that $p will always be a map if $n is "a", it is something the complete cannot »guess«. In those cases, it is better to omit type declarations in your code. The reason is that the optimizer will also rewrite and simplify those parts of your code that may not be evaluated at runtime.
Hope this helps, Christian
mvgr.
Rob Stapper
mvgr.
Rob Stapper