On 7/11/07, Phil Endecott <spam_from_boost_dev@chezphil.org> wrote:
[snip]
I would like to see a more declarative syntax for much of this stuff.
I prefer to read any constant fragments from files or from literal strings, which is about as declarative as you can get.
But you lose locality and sometimes performance. What if you have lots of little xml snippets that must be added in parts of a xml document. Does saving them in files is really a good option? Wouldn't be better to just have four or five lines more of code inside the function? There you can see both the code logic *and* what it is adding. I wouldn't want to have some kind of j2ee directory structure with god-knows how many xmls files all over the place. [snip]
But I think that using subclasses is the key to making this sort of code easier on the eye:
struct firstname: public element { firstname(n): element("firstname",n) {}; };
etc.
articleinfo ai; if (title) ai.push_back(comment("This title was moved")); author a; a.push_back(firstname("Joe")); a.push_back(surname("Random")); ai.push_back(a); root.push_back(ai);
Wow! I can't understand how this can be any closer to as readable as the interface david proposed. There are a lot of names which just mean nothing to anybody reading this code. author a; ? then a.push_back() a.push_back() ai.push_back() It doesnt strike to you that this code is very error-prone?
Just adding some non-standard indentation to that makes it almost as clear as I need. You don't need the {}, but it keeps your editor's auto-indent happy:
articleinfo ai; { if (title) ai.push_back(comment("This title was moved")); author a; { a.push_back(firstname("Joe")); a.push_back(surname("Random")); ai.push_back(a); } root.push_back(ai); }
Instantiating every node you have to add is just too much unnecessary burden. I can't see how the user gains with this, instead of the declarative approach. [snip]
Of course there is a question of the lifespan of these apparently-temporary objects to resolve. Anyway, I think that nice-looking XML-generating code can be possible without "resorting to" operator overloading.
What is the advantage of not resorting to operator overloading? What exactly anybody wins not using it?
Regards,
Phil.
Best regards, -- Felipe Magno de Almeida