Re: [boost] Is there any interest in a library for application : Boost.Application, new version: Boost.Application_beta_3a

Subject: Re: [boost] Is there any interest in a library for application : Boost.Application, new version: Boost.Application_beta_3a
From: Julian Gonggrijp (j.gonggrijp_at_[hidden])
Date: 2013-09-20 07:26:27

Renato Forti wrote:

> Here are the online docs to the library:
> 
> http://www.dokfile.com/appbeta3/docs/libs/application/doc/html/index.html

I had a quick look at the documentation and I certainly think your
library could be useful. I do have one concern about the API, and a
few remarks about the documentation.

My concern about the API:

In order to create an interactive application, the body of main would
be

    return application< my_application<myapp> >( args(argc, argv) )();

while for a server it would be

    return application< application_type<server_application>,
                        my_application<myapp> >( args(argc, argv) )();
.
I find this counterintuitive for three reasons. The first is that
my_application appears to be a template provided by the application
library, so it isn't "mine" at all. I only created myapp so that is
the only entity that should be allowed to have "my" in the name. 

Secondly, I need two nested templates in order to launch my
application class. There is no immediately obvious reason why it
couldn't be just a single template.

The third reason is that I need to specify the application type for a
server but not for an interactive application, and that this optional
template parameter comes before the required parameter, i.e. the
template that actually wraps my application class. 

Concluding, I would find the following interface much more natural:

    return interactive_app<myapp>(args(argc, argv))();
    
    return server_app<myapp>(args(argc, argv))();

for interactive applications and server applications, respectively.
Perhaps this isn't possible, but then at least the very start of the
documentation should give the user an understandable reason why the
interface needs to look so complicated. In any case, please let the
optional template parameters come after the required parameters.

My remarks about the documentation:

The English leaves a lot to be improved upon. There are eye-catching
typos, such as "Handlres" in one of the section titles and "avector"
in the two minute introduction, as well as many subtle ellipses and
other syntactical errors that make the text a bit unnatural and harder
to read. This may not seem important, because it doesn't make your
library any less valid and it probably wouldn't affect the outcome of
a future review (much), but it will be easier to get a review at all
if you improve the language. Potential reviewers and review managers
may get the impression they can't take your library seriously after a
first glance at the documentation, so I think it would be advisable to
give this first priority. I would recommend getting help from a
(near-)native speaker to clear up the syntax.

There are lots of exclamation marks in the text. This gives a
"screamy" and not-so-serious appearance.

I compared the Windows and Unix tutorials and the example code is
completely identical, except for a single line in the blocking stop at
the end. That difference isn't even strictly necessary as it is the
omission of a line that would be ignored in Unixy systems anyway. I
think you should merge the tutorials, both to show that your library
meets the goal to write portable applications and to illustrate how a
decision in the code affects both platforms, regardless of what
platform the user is most interested in.

Hope this helps!

-Julian