Hi Jeni,
Do any examples exist when such implicit casting would be
dangerous/counter-intuitive? If not, then it would be very useful to
allow implicit casting to string.
I agree, but then I think that it would be useful to allow implicit
casting to a required type, whatever it is, if such a cast is
permitted.
Absolutely -- this is logical, intuitive and will be a time saver.
Those that support strong typing in XPath 2.0, on the other
hand, believe that it's useful to be told that you can't use an
integer where a string is expected.
Yes, so an XSLT processor could issue a warning. Only in the "weird" cases this
warning will
really be useful to help find the reason of the "weirdness".
There are lots of cases where there *is* implicit casting (of
xdt:untypedAtomic values) in XPath 2.0 and that casting is
counter-intuitive (to XPath 1.0 users). For example:
@height > @weight
Sigh... nothing can be done here, since ">" has now been defined for strings.
This is the case
when casting is possible to more than one type and nobody knows what is
"correct" for the current
programmer. In this case explicit casting is necessary.
To formulate it more precisely, when there's no ambiguity, implicit casting to
the type of an
argument should be performed. We agree that this is a job for the XSLT
processor (no ambiguity and
perfect knowledge of type signatures) that will significantly help the
programmer (prone to
forgetting and commiting errors).
while:
current-dateTime() + @delay
(where @delay is "PT30M", for example) will give you a type error
because the delay attribute is cast to an xs:double (even though you
can't actually add an xs:double to an xs:dateTime) and "PT30M" isn't a
valid double value.
The same case again -- the implicit cast must be to the only known correct type
for the operation.
Similarly:
24 idiv (@indent + 3)
will give you a type error because the indent attribute is cast to an
xs:double, which means the result of (@indent + 3) is an xs:double,
which isn't a valid type for an operand to idiv.
Again the same case as above. Someone would argue that the decision to what
type to cast will
depend on the order of evaluation (,which in an FP language is not strictly
defined). However,
human beings tend to write expressions in a predefined way (e.g. from left to
write), so the same
should be used in the casting of types of operands -- of course, after the
casting decisions are
made the expression can still be evaluated in any possible order.
Which I guess goes to show that implicit casting coupled with
polymorphic operators will always give some weird results.
Not in the cases where there's no ambiguity. And warnings will be helpful if a
few weird cases
still remain.
In cases like the current one I think such "conversion constructors"
should be specified in the XPath data model. This makes writing and
understanding a program much more easier.
The rules for casting between types are specified in the XPath/XQuery
Functions & Operators document (http://www.w3.org/TR/xpath-functions).
As I said above, personally I don't see why these rules can't be used
for implicit casting,
Agreed. What can be done to have this in the spec?
but this seems to go against the strong typing
ethos of XPath 2.0.
And there can be warnings to that effect.
=====
Cheers,
Dimitre Novatchev.
http://fxsl.sourceforge.net/ -- the home of FXSL
__________________________________
Do you Yahoo!?
The New Yahoo! Search - Faster. Easier. Bingo.
http://search.yahoo.com
XSL-List info and archive: http://www.mulberrytech.com/xsl/xsl-list