jkesselm commented on PR #125: URL: https://github.com/apache/xalan-java/pull/125#issuecomment-1817385418
Great. I was thinking of moving in that general direction, as you know. Code complexity: Historical accident. It got rattled off between other things, it worked well enough that it didn't get revisited. It's not exactly in anyone's critical path... Multiple classes: Shipping in two jarfiles (serializer and processor), we wanted to allow for the possibility of out-of-synch versions, so we needed two classes with their own constants. Plus the merge of Sun's XSLTC compiler into IBM's Xalan-J code left us with some redundancies. So at least two of the three classes make some slight sense -- though having three completely different implementations, I agree, is ugliness that should be cured. I do NOT claim this code is as clean as it should be! It's been largely unattended for a very long time, and the process of pulling IBMers off it was also not clean. (I was one of the last out...) And yes, the javadoc is erratic at best; one of the many things on my own backlog is cleaning it up, since I probably remember the overall architecture of the beast better than most. Can I suggest we open Issues to make sure we don't forget these points? I'm willing to do that for you, but I'm short on sleep right now and probably less than coherent so if I'm doing it I'd rather wait until tomorrow... -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: dev-unsubscr...@xalan.apache.org For queries about this service, please contact Infrastructure at: us...@infra.apache.org --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscr...@xalan.apache.org For additional commands, e-mail: dev-h...@xalan.apache.org
