dxml 0.2.0 released

H. S. Teoh hsteoh at quickfur.ath.cx
Mon Feb 12 22:02:04 UTC 2018


On Mon, Feb 12, 2018 at 02:54:48PM +0000, rikki cattermole via Digitalmars-d-announce wrote:
[...]
> Everything you have mentioned is not in Phobos. Just because something
> is 'good enough' does not make it 'good enough' for Phobos. In the
> words of Andrei "Good enough is not good enough", we need to aim
> higher to show what we actually can do.

And thus Phobos continues to let the perfect be the enemy of the good,
and 10 years later std.xml will still be around, and we will still be
arguing over how to replace it.


> Personally I find J.M.D. arguments quite reasonable for a third-party
> library, since yes it does cover 90% of the use cases.

As I have just said in another post, dxml itself does not need to be
changed to implement DTD support.  It's perfectly possible to write a
wrapper on top of it that *does* implement DTD support.  In fact, I dare
say it might be possible to lazily switch from a thin wrapper over dxml
to full DTD mode, so that end users don't even need to care about the
difference if they don't care to.

As far as API is concerned, it could be as simple as something like:

	auto parseXml(R, DtdSupport = dtdSupport.true)(R input) if (...)
	{
		static if (DtdSupport)
			return dtdWrapper(dxmlParse(input));
		else
			return dxmlParse(input);
	}

Then just note in the documentation that turning off DTD support would
provide extra features X, Y, and Z (speed, slices, whatever). Then let
the user choose.

Seriously, I would have thought something like this would be obvious to
programmers of the calibre found on these forums.  I'm a little
astonished that this would even be such a point of contention in the
first place, since the solution is so simple.


T

-- 
Many open minds should be closed for repairs. -- K5 user


More information about the Digitalmars-d-announce mailing list