Re: A good representation of XML in Java?
On 9/19/2010 7:26 PM, Arne Vajh?j wrote:
On 05-09-2010 23:29, BGB / cr88192 wrote:
"Daniel Pitts"<newsgroup.spamfilter@virtualinfinity.net> wrote in message
The real benefit of not writing your own wheel is this: You come to your
boss and say "You wanted something round: Here it is!" and present him
with an existing wheel. He then is grateful that this didn't turn into
one of those long, expensive, buggy, failed projects, and you are
kept on.
Then, when your boss asks you to "integrate this wheel with an axle",
you
look at the wheel you chose. It happens to have that integration built
in, because that is a common thing that needs to be done. You show your
boss how fortuitous your thinking was when you originally presented the
wheel, and you get a promotion.
Also, you got all of that benefit WITHOUT the extra work of having to
prove how "clever" you were by reinventing the wheel.
"Can we add brakes too?" "Already done sir!"
there are reasons when and when not to reinvent.
sometimes, there are cases where a small and specific piece of code to
solve
a problem is preferable to a large and complex 3rd party library, as
dragging along a library can be more of a problem than simply having a
piece
of code to get the job done.
If the library is well documented and well supported, then does it
matter how big it is?
Yes, if the dependencies are unmanageable. You'd like to use
WizardXML, a nice, svelte, open-source, virtuous, pacifist library
with a low carbon footprint; fine. WizardXML in turn uses MagicBuzz
dispatching framework, which makes heavy use of OccultObject, which
itself inherits from IncantationInstantiator. Version 3, naturally,
since Version 4 introduced an API incompatibility in order to permit
the use of an advanced spell-spelling package (spelling a spell wrong
can get you in *enormous* trouble ...).
Unfortunately, you also need PsychicPsimulator. PsychicPsimulator
relies on Pseeress, which also uses IncantationInstantiator -- version
5, since there's just no hope of implementing the advanced capabilities
of Pseeress with the antiquated pre-V4 API ...
Componentized architectures have many advantages, but there's a
trade-off: They exacerbate the problems of "version skew" and make them
much nastier than they usually are in monolithic schemes. Which is not
to say that the monolith is somehow "superior," just to say that there
are trade-offs, and that TANSTAAFL.
--
Eric Sosman
esosman@ieee-dot-org.invalid