<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">
<HTML><HEAD>
<META http-equiv=Content-Type content="text/html; charset=us-ascii">
<META content="MSHTML 6.00.6001.18183" name=GENERATOR></HEAD>
<BODY
style="WORD-WRAP: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space">
<DIV dir=ltr align=left><FONT face=Arial color=#0000ff
size=2></FONT> </DIV>
<BLOCKQUOTE dir=ltr
style="PADDING-LEFT: 5px; MARGIN-LEFT: 5px; BORDER-LEFT: #0000ff 2px solid; MARGIN-RIGHT: 0px">
<DIV>
<DIV>In my research group, we are actually working on a project about object
orientation in XQuery, called Unity. We did not go into dynamic binding or
polymorphism, but basically, we simply tried to introduce code in the schema
to allow constructs like, following your idea:</DIV></DIV>
<DIV><BR></DIV>
<DIV>$triangle/rotate()</DIV>
<DIV><BR></DIV>
<DIV>where the context item is passed as a hidden parameter to the method
rotate. The method rotate is defined in the schema for the static type of
$triangle.<SPAN class=477003517-20012009><FONT face=Arial color=#0000ff
size=2> </FONT></SPAN></DIV>
<DIV><SPAN class=477003517-20012009></SPAN> </DIV>
<DIV><SPAN class=477003517-20012009><FONT face=Arial color=#0000ff size=2>I
don't think static polymorphism (overloading based on the static type of the
arguments - here the implicit first argument) - is a particularly useful step
forwards. It gives a minor syntactic convenience for the kind of highly
structured data where static typing works, but the real need is for something
more dynamic.</FONT></SPAN></DIV><SPAN class=477003517-20012009><FONT
face=Arial color=#0000ff size=2></FONT></SPAN></BLOCKQUOTE>
<BLOCKQUOTE dir=ltr
style="PADDING-LEFT: 5px; MARGIN-LEFT: 5px; BORDER-LEFT: #0000ff 2px solid; MARGIN-RIGHT: 0px"><SPAN
class=477003517-20012009></SPAN>
<DIV><SPAN class=477003517-20012009></SPAN><FONT face=Arial><FONT
color=#0000ff><FONT size=2>I<SPAN class=477003517-20012009>'m all in favour of
allowing a function to declare that it takes the context item as an implicit
parameter, but that's just a bit of syntactic
sugar. </SPAN></FONT></FONT></FONT><BR></DIV>
<DIV>We have implemented a cross-compiler which compiles Unity code to
XQuery+XML Schema, and could test the output successfully with Saxon SA on
several examples. We did not encounter any major issues during the
implementation. One issue could be a name collision between a method and a
function, which can be solved by looking at methods for the static type of the
context item first, and then at functions.</DIV>
<DIV><BR><SPAN class=477003517-20012009><FONT face=Arial color=#0000ff
size=2>I think that if you are despatching different methods based on the
results of static type inferencing, then the static type rules need to
be visible to, and comprehensible to, the users of the language. That
isn't the case with Saxon's current static typing, which is designed for
optimization and diagnostics only - it shouldn't affect the result of the
query, so it's done as intelligently as Saxon considers appropriate. I
would be very concerned about "freezing" the static typing rules in such a way
that a change to make it more clever could affect the results of user
queries.</FONT></SPAN></DIV>
<DIV><SPAN class=477003517-20012009><FONT face=Arial color=#0000ff
size=2></FONT></SPAN> </DIV>
<DIV><SPAN class=477003517-20012009><FONT face=Arial color=#0000ff
size=2>Michael Kay</FONT></SPAN></DIV>
<DIV><SPAN class=477003517-20012009><FONT face=Arial color=#0000ff size=2><A
href="http://www.saxonica.com/">http://www.saxonica.com/</A></FONT></SPAN></DIV></BLOCKQUOTE></BODY></HTML>