Subject: key() Re: Saxon VS XT From: Paul Tchistopolskii <paul@xxxxxxx> Date: Sat, 05 Aug 2000 01:34:57 -0700 |
> At 05:00 5/08/2000, Paul Tchistopolskii wrote: > > > > Not using key, is like having to use Perl > > > (or any other programming language) without being allowed > > > to use hash tables for lookup purposes. > > > >Poor C, ( and Pascal ) they had no build-in hashtable support. > > Well, I'd like to see you do in C (and Pascal) what is > normally done in Perl. <OT> I'l not comment on what is *normally* done in perl with hashes. Blessing hash into object is just plain hack. Of course it is 'handy'. Global variables are also handy. Don't you agree that hashes in perl are simply abusing the language? Again - hashes are good. Sometimes. </OT> Hashes are handy, sure. I just don't understand why should XSLT "have hashtable support for lookup purposes" other than select="list-of-predicates". Should XSLT "have build-in support for SQL" ? > I use Pascal (Delphi) all the time, but its lack of good > string and list handling is often crippling. (That's what > Omnimark is for.) I wish you'l then explain to me what is the meaning of key() other than road-sign for compiler and why key() is so critical to you ( this is what I am trying to discuss) ? I understand that it was my mistake not explaining in detail that the sentence "not using key() means XSLT has no hashing" sounds like "any language should have a built-in hash support". I doubt this is true, so I said "poor C". Sorry that I have not spend more time explaining what do I mean. As it was already said : it is easy to implement a hashtable in C. I was not using the word "C++" only because I'm not sure what is the current status with RTTI and alikes. I'm not tracing C++ ... movement .... for a while. Maybe C++ have added the 'built-in' support for hashing into the core, like Java did - don't know. For a while they were OK without that built-in support. XT *has* built-in hash support ( and that support is not key() function). It is just not written with red flashing letters. The point I am discussing remains valid: "who really-really needs key() in XSLT and *why* do we need it?" The only argument sofar is 'speed'. Am I right ? Any other arguments for key() ? Like "it makes code clean and easy to maintain?" ( I'm sorry - I really don't understand why is XT so limited not supporting key() - this was the origin of this thread, if you remember. ) Rgds.Paul. PS. The Bible ( Michael's book ) has some interesting things about key() ( as usual ;-): <q Page="225"> Usage and Examples. Declaring a key has two effects: it simplifies the code ... and it is likely to make access faster. </q> Those who want to see how key() 'simplifies the code' are welcome to guess what processing is implemented in test6.xsl stylesheet by Sebastian ( without looking into .xml file, please ). <q Page="229"> Multiple Named Keys. ..... It is worth thinking twice before doing this, however. Assuming the XSLT processor implements the key by building an index rather than by searching .... </q> Worth reading. I'm wondering what we could do if Michael not write his book. XSL-List info and archive: http://www.mulberrytech.com/xsl/xsl-list
Current Thread |
---|
|
<- Previous | Index | Next -> |
---|---|---|
Re: Saxon VS XT, James Robertson | Thread | RE: Saxon VS XT, Chris Bayes |
Re: Saxon VS XT, James Robertson | Date | RE: <xsl:stylesheet xmlns..., Chris Bayes |
Month |