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.stap...@lijbrandt.nl>
> Aan: Christian Grün <christian.gr...@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.gr...@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

Attachment: referentialDemo.xq
Description: Binary data

Attachment: buggyDemo.xq
Description: Binary data

Attachment: workingDemo.xq
Description: Binary data

Reply via email to