Re: [XML::XSLT] patch ignored, why?

[Marc L. <pc...@go...>]

On Sun, Jul 30, 2000 at 02:43:19PM -0500, Mike808 <mi...@ne...> wrote:
> > Any reason why my patch has been ignored twice?
> 
> I don't think it's been ignored Mark. The line endings have been
> fixed (at least in the maint tree). I've removed the extraneous /i
> on matches - I left in questionable ones (or ones I don't understand 
> yet) just in case.

Hmm, sorry, I didn't see it in the ChangeLog and didn't receive a comment
like "hey, you S.O.B., we already did that!" ;)

> I can't speak to Mark H's speed on getting them into his 0.30 dev tree.

No problem... you have to understand that my patch was applied a long
time ago, and was missing in CVS, so I was wondering. And since I didn't
receive any complaints I even doubted wether my e-mail was received at
all!

> We've been discussing how to handle the constant issue, but it's not

Oh, I didn't want to touch the constant issue.

> cut and dry, since older versions of perl didn't inline things, and
> function calls are slower than scalars which are a tad slower than 
> lexicals. I know you don't care, 'cuz you're on 5.6, but there

I don't care even on 5.005 (since that version inlines as well). Are you
sure 5.004 doesn't inline? (I'm 20% convinced that it does).

However, while we are at the topic: It is nice to support stone-age perls
like 5.004, but there shouldn't be speed penalties for everybody else "just"
because 5.004 is slower.

In Gimp, for example, 5.004 _works_, for those people who need it, but
when there is a choice I always go for "works best with latest perl".

IMHO this is very reasonable ;) Although I admit more people might be
forced to use XML::XSLT in "hostile" environments (no control over perl
version, and bofh's administrating the server ;)

> using mod_perl and XML::XSLT, and last I heard, mod_perl and 5.6
> aren't stable yet.

Never found a problem. But mod_perl *is* stable with 5.005.

> And just for bitching, you go in the CREDITS file. :)

*grumble* :() I'd rather like to contribute something with more
substance... hmm..

> filtering the line ending cruft - yes that was a mess. I don't know
> what they were thinking)

They were going for portability, no doubt ;)

> functional. But, that's the beauty of Perl in that you can be as OO
> as you want to be.

Well, I am astonished that it works that well. Together with *very*
aggressive caching it is even useful.

However, the biggest uglyness IMHO is the DOM concept, which just does not
fit nicely into perl. And trees also do not fit nicely into perl.

Maybe speeding up XML::DOM (by writing key routines in XS, or even put
part of the data structures into XS) might be more worthwhile, since, ugly
as it might be, DOM is the standard and used by most xml processors since
it is a standardized internal representation.

Ah, and adding convinience methods (that could be even fast) into XML::DOM
or some superclass might also be interesting, since DOM requires a lot of
method calls, and method calls are a performance penalty.

But I'm drifting away. Maybe I should bithc some other developers
elsewhere...

-- 
      -----==-                                             |
      ----==-- _                                           |
      ---==---(_)__  __ ____  __       Marc Lehmann      +--
      --==---/ / _ \/ // /\ \/ /       pc...@op... |e|
      -=====/_/_//_/\_,_/ /_/\_\       XX11-RIPE         --+
    The choice of a GNU generation                       |
                                                         |