This is the mail archive of the xsl-list@mulberrytech.com mailing list .


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]

key() Re: Saxon VS XT



> 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

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]