[
Lists Home |
Date Index |
Thread Index
]
> Hi Uche,
>
> > But I could also go with a compromise: use two different functions:
> >
> > expanded-name(node)
> >
> > expand-qname(string[, ns-context-node])
> >
> > Actually, I like this best, now.
>
> Agreed.
>
> > I think that the added verbosity of the function call is a fine
> > price to pay compared to the prospect of overloading "+" to death. I
> > will say that even in OO languages, I've always looked on operator
> > overloading with much caution. Symbols, carefully chosen, can be a
> > powerful tool for expressivity, and they can also become a powerful
> > tool for confusioon. C++ iostreams is my favorite example. IMO, they
> > were an abomination. I and many others I know preferred to stick to
> > printf even though it provided a bit less formatting support. (But,
> > of course, not scanf ;-) ). Even better was to provide a polymorphic
> > pprint() method on relevant opjects that provided formatting
> > constructs *that made sense for that particular object*.
>
> What I'm worried about is that if we adopt the kind of proposal that
> you're talking about then W3C XML Schema users would have to use
> function calls pretty much *everywhere*. For example, they would have
> to do:
>
> compare-decimals($num1, $num2) = 1
>
> or:
>
> decimal-greater-than($num1, $num2)
>
> rather than:
>
> $num1 > $num2
>
> I can understand that you have to use functions in order to shoe-horn
> extended data type support into XPath 1.0, but thinking in terms of
> XPath 2.0 I'd like to see a natural way of making the '>' operator,
> for example, a shorthand for a function call. I don't think that the
> proponents of W3C XML Schema data types in XPath 2.0 will go for a
> solution that requires the user to write a function call to compare
> two decimals.
I still prefer cauution over oprator overloading, but I guess if the overload
definition mechanism can at least be made transparent, as in the other
suggestions,...
> Oh, I've just realised that I'm making the assumption that the XPath
> 2.0 data model would be used for this -- that values would be
> "labelled" with their type, such that when I pass around $num1 it is a
> value labelled as being an xs:decimal rather than being natively a
> string or a number and being converted to a particular type when a
> particular function has to be carried out on it. Do you think that's a
> bad idea?
From an implementor's POV, it makes dealing with variables in XPath a royal
pain. And Python is even more flexible in these matters than Java. I do
think that certainly it is an idea that should give great pause, and my
initial reaction is quite negative.
> > I also don't like the fact that for some folks, RGB values will
> > always be far more ueful than dates. And yet they can use = for one,
> > and must use an entirely different syntax for another.
>
> What I'm suggesting is that in the data type definition for the RGB
> value, such a user could specify a comparison (returning 1, 0 or -1).
> Whenever the XPath processor found:
>
> $colour1 = $colour2
>
> (where both $colour1 and $colour2 are of the type colour) it would
> translate that into:
>
> compare-colours($colour1, $colour2)
>
> This would enable users to use the whole range of XPath operators --
> =, !=, >, <, and, or, +, -, *, div, mod -- for their user-defined data
> types, without being burdened with function syntax.
I see that now.
--
Uche Ogbuji Fourthought, Inc.
http://uche.ogbuji.net http://4Suite.org http://fourthought.com
Apache 2.0 API - http://www-106.ibm.com/developerworks/linux/library/l-apache/
Python&XML column: Tour of Python/XML - http://www.xml.com/pub/a/2002/09/18/py.
html
Python/Web Services column: xmlrpclib - http://www-106.ibm.com/developerworks/w
ebservices/library/ws-pyth10.html
|
