- From: Stephen Buxton <Stephen.Buxton@oracle.com>
- Date: 16 Feb 04 11:43:56
- To: public-qt-comments@w3.org
- Cc:
SECTION 2.6.2: static typing feature Section 3.7.3.1 "Computed element constructors" gives an interesting example of a way to construct an element with the same name as a given element, but with a different content. The note following the example says that the example is not portable because it will not work under the Static Typing Feature. To me, this example calls into question the utility of the feature. The note gives a workaround, using the function fn:exactly-one, and the F&O has additional functions which will overcome certain other static typing issues. The conclusion I draw is that anyone interested in portable programming will be required to use these functions as guards to explicitly disable the static typing feature, in case the application is ported to such an implementation. The purpose of the guard functions is to give the application precisely the behavior it would have had if the static typing feature were not supported. I am wondering if the problem is in an overly fastidious notion of what static typing should do for the user. To me, a function invocation fct(arg) whose sole parameter is declared to be item() or item()+ with an argument arg whose static type is item()? or item()* does not look like a static type error, because it is possible that the command will succeed at run-time. I suggest that the static typing feature should raise type errors when the static type of an actual argument or operand has empty intersection with the required type in that position. In such a case it is a certainty that there would be a run-time error, and therefore a user benefit to provide early detection of such errors. I can see this as a user benefit even if the code is unreachable, because it probably reveals a logic error on the user's part. But to raise static errors for situations that might run successfully on certain inputs seems like a disservice to the user. - Steve B.
Received on Monday, 16 February 2004 14:44:00 UTC