Re: [boost] RFC: Boost.XML API prototype in the sandbox

From: Phil Endecott (spam_from_boost_dev_at_[hidden])
Date: 2007-07-11 18:36:36

Felipe Magno de Almeida wrote:
> On 7/11/07, Phil Endecott <spam_from_boost_dev_at_[hidden]> wrote:
>> 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

Not with literal strings, e.g.

element("<author>"
           "<firstname>Joe</firstname>"
           "<surname>Random</surname>"
         "</author>");

> and sometimes performance.

Ideally these would be static, i.e. parsed once per program 
invokation.  But yes, this is not ideal for performance.

>> 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; ?

Well if you're generating an XML fragment with an <author> tag, it 
should mean something to you.  If you prefer, try author_element or element("author").

> then
>
> a.push_back()
> a.push_back()
> ai.push_back()

I hope that push_back() is familiar to all C++ users.

> It doesnt strike to you that this code is very error-prone?

The main types of error are creating an element and then forgetting to 
add it to its parent, and stuff like that.  Yes, this happens.  But 
it's fairly easy to debug.

>> 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?

The advantage of not using operator overloading is that it is easier to 
see what is going on; the code is less magical.  We all know what 
"OBJECT.METHOD(PARAMETER)" does, but what does X [ Y , Z ] do?  It 
looks like 2D array indexing to me.  The overloading of operator[] and 
operator, that David presented would be justified if it made a 
substantial saving in LOC and increase in clarity compared to what you 
could achieve using conventional syntax.  But my feeling (and I'm happy 
to see counter-examples) is that the syntax that I presented gets close 
to the LOC and clarity (see below), and that in some cases you can use 
inline string literals for maximum clarity.

root.push_front(                              articleinfo ai(root); {
     tag("articleinfo")[                           author a(ai); {
         tag("author")[                                firstname(a,"Joe");
             tag("firstname")["Joe"],                  surname(a,"Random");
             tag("surname")["Random"]              }
         ]                                     }
     ]
)

(The syntax on the right is pretty much what I use to build XML in 
Javascript, and I'm fairly happy with it.)
(Oh no, I confessed to writing Javascript on the Boost list, now my 
secret is out...)

Phil.