Hello Julian,
Thank you for your consideration, are very important!
About the interface, in the first version (release 1) , the interface of the
lib are exactly what you proposed. But this bring so problems to extend lib
in the future, then I resolved to use a more complex interface, but that
are more flexible, using Boost.Parameter (iten 2 of change list)!
However, is easy to provide both interfaces, and I will think in a way to
create a wrapper class, and provide the both interfaces.
I will wait for more consideration on this subject to have a more clear
perception, about what is desirable by boosters!
About Documentation!
I agree with you that documentation is very bad writing!
I have "dyslexia", and even in my native language (which is Portuguese), I
don't write well! I want to take and ask for help, if any native speaker of
English can help me with the documentation! Contact: re.tf@acm.org
Again, thanks for the comments! They will be considered for the next
version!
Renato
-----Mensagem original-----
De: Boost [mailto:boost-bounces@lists.boost.org] Em nome de Julian Gonggrijp
Enviada em: sexta-feira, 20 de setembro de 2013 08:26
Para: boost@lists.boost.org
Assunto: Re: [boost] Is there any interest in a library for application :
Boost.Application, new version: Boost.Application_beta_3a
Renato Forti wrote:
Here are the online docs to the library:
http://www.dokfile.com/appbeta3/docs/libs/application/doc/html/index.h
tml
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,
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
_______________________________________________
Unsubscribe & other changes:
http://lists.boost.org/mailman/listinfo.cgi/boost
