RE: [F&O] 15.1 zero-or-one, one-or-more, exactly-one

> > The main purpose of these functions is to raise an error if 
> > the property they name is not true for the parameter-sequence. 
> > 
> > Such functions are not necessary and useful, because, had 
> > their type been specified as:
> > 
> >    fn:zero-or-one($srcval as item?) as item?
> >    fn:one-or-more($srcval as item+) as item+
> >    fn:exactly-one($srcval as item) as item
> > 
> > then the error would be raised automatically if $srcval was 
> > not of the correct type.
> 
> The problem arises when you are using a system that does (pessimistic)
> static type checking. In this case, calling a function whose argument is
> declared as element() with the actual argument book/author can give you
> a type error even if you know that book/author will return a single
> element.
> Calling the function with exactly-one(book/author) prevents the static
> type system giving you an error (in much the same way as a treat 
> expression).
> If the type signature of exactly-one were as you suggest, then the 
> function would not serve its purpose, since the call exactly-one
> (book/author) would again give you the static type error.

I see. 

So these three functions serve as dynamic casts needed to make a static
type-checking system work at all. Then why should we pretend that we have
static type-checking? Isn't it better to say that any implementation
should defer type checking to run time in all cases when an exact decision
is not possible at compile time?

Such pessimistic type-checking systems are clearly not useful if they
require extra work in order to function properly.

Where in the requirements for F&O is it written that pessimistic
type-checking should be supported? 

Why support such inappropriate type-checking?


Dimitre Novatchev.




__________________________________
Do you Yahoo!?
Free Pop-Up Blocker - Get it now
http://companion.yahoo.com/

Received on Sunday, 23 November 2003 01:09:06 UTC