[XML-DEV Mailing List Archive Home] [By Thread] [By Date] [Recent Entries] [Reply To This Message] Re: [xquery-talk] Mistakes made in the design of XQuery 3.1
> > I think the array constructor was the biggest mistake. (I believe arrays more frequently used than null) > I doubt it would be possible to make a worse definition. > > Three constructors, map { ... }, array { ... }, [ ... ] > > Only [ ... ] looks out of place. > > Every other constructor in XQuery uses { }. Even node constructors. > > There is no reason to add [ .. ] for arrays, if you want to make a consistent language. I agree with you, I’m not happy with this aspect of the design. But the decision was reached after lengthy arguments at a F2F meeting which I didn’t attend, so I couldn’t complain. The problem is that neither construct does the whole job. [a,b,c] can only be used to create an array whose size is statically known, whereas array{X,Y,Z} can only be used to create an array whose members are single items. But the underlying problem is really that arrays are second-class citizens in the language. FLWOR expressions, filter expressions, even the comma operator, work on sequences but not on arrays. We tried many different design approaches for arrays in attempting to tackle this problem, but this was the best we could do. > > So the only reasonable definition is to concat sequences in [ ] and not concatenate them in array { } > > > But no, you do the complete opposite! > Yes. I tried to get it changed to be the other way around, and failed. Just in case Daniela thinks I got everything my way. Michael Kay Saxonica
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] |
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
|