This is the mail archive of the
xsl-list@mulberrytech.com
mailing list .
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