Re: What is the best way to cast integer to string in
> > There are probably two main justifications for not allowing function > arguments always to be cast to the required type. The first is error > checking - as the number of types increases, the risk increases of doing > a calculation that is different from the one the user actually intended. > The second is polymorphism. XPath 2.0 doesn't allow functions (as > distinct from operators) to be polymorphic, but some people would like > to keep the option open to allow it in future, and weak typing is not > really compatible with polymorphism. I do not advocate weak typing. It is possible to avoid unnecessary explicit casts/conversions with strong typing and still to support polymorphism to the maximum extent possible. In Haskell there are type classes. For example: > class Show a where > show :: a -> String > showsPrec :: Int -> a -> ShowS > showList :: [a] -> ShowS This defines the class of all types that have a "show" method, which will present an instance of the datatype to a string. The type "shows" is a synonym for any function from String to String > type ShowS = String -> String -- Minimal complete definition: show or showsPrec > show x = showsPrec 0 x "" > showsPrec _ x s = show x ++ s > showList  = showString "" > showList (x:xs) = showChar '[' . shows x . showl xs > where showl  = showChar ']' > showl (x:xs) = showChar ',' . shows x . showl xs As can be seen, the "showList" method can produce the string representation of any list of things whose type belongs to the Show class. This is the direct (and really precise) Haskell analog to the XSLT/XPath concat() function. As we see, in a well-designed strongly typed language, functions like concat() may be defined in such a way so that no explicit conversion of the arguments will be required. There are many other useful type classes: Eq -- a class of datatypes that have the equality operator: > class Eq a where > (==), (/=) :: a -> a -> Bool -- Minimal complete definition: (==) or (/=) > x == y = not (x/=y) > x /= y = not (x==y) Ord -- a class of all datatypes that belong to Eq and also have a total ordering relation defined: > class (Eq a) => Ord a where > compare :: a -> a -> Ordering > (<), (<=), (>=), (>) :: a -> a -> Bool > max, min :: a -> a -> a -- Minimal complete definition: (<=) or compare -- using compare can be more efficient for complex types > compare x y | x==y = EQ > | x<=y = LT > | otherwise = GT > x <= y = compare x y /= GT > x < y = compare x y == LT > x >= y = compare x y /= LT > x > y = compare x y == GT > max x y | x <= y = y > | otherwise = x > min x y | x <= y = x > | otherwise = y Class Bounded Class Num etc. This is a nice example how unnecessary casts/conversions can be avoided, while still preserving and supporting polymorphism. ===== Cheers, Dimitre Novatchev. http://fxsl.sourceforge.net/ -- the home of FXSL > > Most languages end up being a bit pragmatic about this, and XPath is no > different. In the latest draft, we changed all the functions that accept > or return URIs to use the xs:string type instead of xs:anyURI, because > it was simply too much of a pain to keep casting strings to URIs and > back (though Java makes you do just that). For numerics, we introduced a > set of promotion rules that allow arithmetic to mix the different > numeric types. > > There would be no technical difficulty in defining concat(), like > string(), to take item() rather than xs:string as its argument type. > It's just a question of persuading people that it deserves to be treated > as a special case. > > The place for such comments, of course, is the public-qt-comments list. > > Michael Kay > > > XSL-List info and archive: http://www.mulberrytech.com/xsl/xsl-list > > XSL-List info and archive: http://www.mulberrytech.com/xsl/xsl-list
PURCHASE STYLUS STUDIO ONLINE TODAY!
Purchasing Stylus Studio from our online shop is Easy, Secure and Value Priced!
Download The World's Best XML IDE!
Accelerate XML development with our award-winning XML IDE - Download a free trial today!
Subscribe in XML format