Re: [boost] [review] Formal review period for VMD library begins today, Aug 21, and ends Sat, Aug 30

Subject: Re: [boost] [review] Formal review period for VMD library begins today, Aug 21, and ends Sat, Aug 30
From: Niall Douglas (s_sourceforge_at_[hidden])
Date: 2014-08-22 09:43:47

On 22 Aug 2014 at 9:21, Edward Diener wrote:

> >> OTOH if you choose to clone the library in your modularboost/libs/vmd
> >> the top-level index.html link should work perfectly.
> >
> > That involves more work than I wish to do right now. Right now I
> > merely wish to find out if I could contribute a meaningful review.
> 
> The library is on Github and I am following the modular-boost format so 
> I do not know what else I can do to make it easy for others to use and 
> review the library. I do not think that asking reviewers to clone a 
> library and follow instructions in a readme file in order to use it, is 
> asking an awful lot of reviewers.

Equally you want us to give you our time for free to look at your 
stuff. Some would say that putting the documentation onto its own 
website - like every other library in the review queue does by the 
way - isn't asking much of you. For you it's literally a git push to 
github pages and it saves all of us the hassle of cloning your repo 
and patching it into boost just to see if it's interesting at all to 
us.

> >>> However from what I read I ask this: why is this library useful?
> >>
> >> The introduction explains in general the functionality in the library
> >> that would make it useful. Did you read the introduction ?
> >
> > Yes. I get what it does. Not why would anyone need this.
> 
> It is a library for writing C++ macros, like Boost PP. If you do not see 
> any use for Boost PP then naturally you would not see any use for the 
> VMD library.

I see a use for Boost PP in interfaces, mainly to emulate variadic 
templates in 03. With C++ 11 I see little use for Boost PP in 
interfaces, but I can see it might be handy to have occasionally in 
internal source code away from public interfaces.

I struggle to see how variadic macros add to Boost PP in such a 
limited use case. This is the source of my difficulty.

> > The answer is no, but to enter Boost yes. It's very hard for me or I
> > suspect anyone to vote on this if I have no idea what it's useful
> > for. Otherwise someone could submit a randomly generated library and
> > claim it should enter Boost, and we couldn't refuse.
> 
> I can't make you see any use for the library other than writing the 
> documentation to explain how it is used and what it offers for macro 
> creation.

It is you who wants the library to enter Boost. It is therefore you 
and only you who must argue in favour. We default to a reject answer, 
it is you who must persuade beyond a reasonable doubt to not reject.

> > I get this is all very clever. And if this library were being
> > proposed for a suite of C libraries, I'd be all over this like no
> > tomorrow.
> >
> > I don't get how this is useful, or wise for C++ however. If you can
> > show me something it can do which is a pain point for many which
> > cannot be achieved using C++ 14, you get my vote. Otherwise I don't
> > see the use case given the much superior alternatives.
> 
> I do not know what the superior alternatives of C++ 14 are which you 
> see.

Neither do I. I think it is up to you as the presenter of the library 
to tell me why your library is useful to me. I'm not going to decide 
if it's useful to me on my own. I don't have the time. I suspect 
neither do most people here.

> I can only guess that you do not feel that the creation of macros 
> as part of the interface to a library should ever be necessary. But for 
> a number of Boost libraries they still are, and for future libraries 
> they still will be until C++ has built-in support for things which the 
> macro prerprocessor can still do.

I think this is evading the question. You are equivocating here 
Edward.

For reference, I do believe that in C++ 14 code there has to be a 
high bar set on the use of macros in public interfaces, especially as 
C++ 17 Modules will deprecate that. For that reason, macros in 
interfaces is a bad idea.

But I'm giving you out here Edward: give me a use case where your 
library solves a hard problem for others which C++ 14 cannot and you 
get my yes vote because I trust you to have made a good technical 
solution, my problem is in why it is useful. I don't think I am being 
unreasonable or unfair here, if your library is useful we need to see 
proof.

I equally don't mind if anybody else chimes in here with a concrete 
example of where this variadic macro library solved a real problem 
for them. I assume that if this library got a review manager, it must 
have solved something for somebody somewhere. Equally, if no one 
chimes in, I must assume that this library has not met the popularity 
test and therefore has not been suffiiciently tested in real world 
use. And that would affect my vote for obvious reasons.

Niall

-- 
ned Productions Limited Consulting
http://www.nedproductions.biz/ 
http://ie.linkedin.com/in/nialldouglas/