<html><body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space; "><div apple-content-edited="true"><span class="Apple-style-span" style="border-collapse: separate; color: rgb(0, 0, 0); font-family: Helvetica; font-size: 12px; font-style: normal; font-variant: normal; font-weight: normal; letter-spacing: normal; line-height: normal; orphans: 2; text-align: auto; text-indent: 0px; text-transform: none; white-space: normal; widows: 2; word-spacing: 0px; -webkit-border-horizontal-spacing: 0px; -webkit-border-vertical-spacing: 0px; -webkit-text-decorations-in-effect: none; -webkit-text-size-adjust: auto; -webkit-text-stroke-width: 0; "><span class="Apple-style-span" style="border-collapse: separate; color: rgb(0, 0, 0); font-family: Helvetica; font-size: 12px; font-style: normal; font-variant: normal; font-weight: normal; letter-spacing: normal; line-height: normal; orphans: 2; text-indent: 0px; text-transform: none; white-space: normal; widows: 2; word-spacing: 0px; -webkit-border-horizontal-spacing: 0px; -webkit-border-vertical-spacing: 0px; -webkit-text-decorations-in-effect: none; -webkit-text-size-adjust: auto; -webkit-text-stroke-width: 0px; "><span class="Apple-style-span" style="border-collapse: separate; color: rgb(0, 0, 0); font-family: Helvetica; font-size: 12px; font-style: normal; font-variant: normal; font-weight: normal; letter-spacing: normal; line-height: normal; orphans: 2; text-indent: 0px; text-transform: none; white-space: normal; widows: 2; word-spacing: 0px; -webkit-border-horizontal-spacing: 0px; -webkit-border-vertical-spacing: 0px; -webkit-text-decorations-in-effect: none; -webkit-text-size-adjust: auto; -webkit-text-stroke-width: 0px; "><span class="Apple-style-span" style="border-collapse: separate; color: rgb(0, 0, 0); font-family: Helvetica; font-size: 12px; font-style: normal; font-variant: normal; font-weight: normal; letter-spacing: normal; line-height: normal; orphans: 2; text-indent: 0px; text-transform: none; white-space: normal; widows: 2; word-spacing: 0px; -webkit-border-horizontal-spacing: 0px; -webkit-border-vertical-spacing: 0px; -webkit-text-decorations-in-effect: none; -webkit-text-size-adjust: auto; -webkit-text-stroke-width: 0px; ">Hello, </span></span></span></span></div><div apple-content-edited="true"><br></div><div apple-content-edited="true"><div apple-content-edited="true">I totally agree with you that this is a rather minor step forward, but as a programmer, I really value the possibility to have a way to structure a program in modules and classes if the data is highly structured: it makes the code easier to understand and it makes it easier to build big applications. This is one step towards encapsulation, without removing the ability of XQuery to deal with unstructured data. But this might be simply a matter of taste and of programming style, so this is somehow subjective.</div><div apple-content-edited="true"><br></div><div apple-content-edited="true">Regarding static typing and Saxon: we do not use Saxon for the static typing which determines which method is executed. Instead, we perform a very basic and well-defined static typing on complex types based on explicit type declarations and on the imported schema. Saxon SA is only used to execute the compiled output, in which the method has already been bound. So if you make changes to your optimisations, this will not affect the result of the queries.</div><div apple-content-edited="true"><br></div><div apple-content-edited="true">Kind regards,</div><div apple-content-edited="true">Ghislain Fourny</div><div apple-content-edited="true"><br></div><div></div></div><div><blockquote type="cite"> <div 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></div></blockquote></div><br></body></html>