XML Operators
For a long time I wanted to use E4X's operators for XML operations, but now I changed my mind: I think it's a bad idea to use '.' for accessing child elements. One problem is that you can't tell '.' for property access from '.' for child elements. But even worse is that re-adding a property later to a class that uses '.' for child elements would break source code. So another operator for child elements is needed. I think the best alternative is '..' (used by E4X for accessing descendants). My replacement for E4X's '..' is '.~', probably. Because of typed NodeLists (see last entry) I also need another operator to narrow down a NodeList and make it typed, and '.?' looks good for that. So the list of XML operators is

• '..' + QName to get all children with the given QName
• '.~' + QName to get all decendants with the given QName
• '.@' + QName to get the value of the attribute with the given QName
• '.?' + QName to remove all nodes from a list that are not elements with the given QName
• '.()' to keep only those elements in the list, that fulfill the given conditon (filter)

written at 20:15. (0 Comments, Permalink)

Generics with Instance Parameters for XML type safety
Until this weekend I was going to allow only classes as parameters for generic classes. But, thinking more about the XML support, I am now leaning towards allowing values as well. The reason is that I want methods to be able to take a specific element as argument. E.g. A method that takes only XSL's for-each element as arguments should be declared as

class SomeXmlHandler
    namespace xslt "http://www.w3.org/1999/XSL/Transform"
    static handleForEach(Element<xslt:for-each> forEachElement)
        // do something 
end

and possibly with an optimization for elements using only

class SomeXmlHandler
    namespace xslt "http://www.w3.org/1999/XSL/Transform"
    static handleForEach(<xslt:for-each> forEachElement)
        // do something
end

to allow at least basic type-safe processing. This has some consequences: the syntax for generic class declaration needs to support this. I currently favour prefixing the class parameters with a 'class' keyword. My original example will then look like

class MyMap<class Object K, class Object V?>
end

Instance parameters look like the old syntax, without 'class' keyword, and can be accessed like constant static properties. Methods can use the instance parameters, constant static properties and all literals for type parametrization in their signatures. The bigger problem is that it is difficult to retrieve typed elements. In a traditional API this would not be possible without casting. E.g. code like

test(Element someElement)
        NodeList forEachList = someElement.getChildElements("for-each")
        handleForEach(forEachList[0])

can not compile, because the compiler does not know that forEachList contains only "for-each" elements. The NodeList needs to be typed as well. But even worse is that then the return value of getChildElements() needs to be based on the method's argument, which may not be known at compile time. There is a solution though, and it depends on the fact that most child access is done by operators with a literal QName as argument. Thus the compiler can know the QName at compile time, and it would be possible use this information for type safety. It makes the operators a little bit special though. I usually hate magic, but this may be a good cause. The '..' of Element operator would have the signature

NodeList<name> operator..(QName name)

Note that the class parameter is the parameter of the method. This magic should be limited to operators that take a QName as argument. With instance parameters, the Element and NodeList signatures are

class Element<QName element? = null> extends Node
end

and

class NodeList<QName element? = null>
end

If parameters are null they allow any type. Then the example could be written as

test(Element someElement)
        NodeList<xsl:for-each> forEachList = someElement..xsl:for-each
        handleForEach(forEachList[0])

written at 18:03. (0 Comments, Permalink)