[boost] [impl_ptr] Endorsement Request

Subject: [boost] [impl_ptr] Endorsement Request
From: Vladimir Batov (Vladimir.Batov_at_[hidden])
Date: 2017-08-17 03:42:19

It turns out my Review Request was somewhat premature as the submission 
procedures changed quite a bit. Now it says that to just have "library 
added to the review queue" I "need to find at least one member (but 
preferably several) of the Boost community who is willing to publicly 
endorse your library for entry into Boost". So, to enter the review 
queue, I need the lib already reviewed... and approved/endorsed. Hmm, 
feels like a chicken-n-egg situation... but who am I to judge?

So, I was told I

1) should first have a review manager,
2) some candidate review dates,
3) and "seconded" support from the mailing list.

So, I guess, it is the time when I humbly request if I can find anyone 
to step forward for No.1 and No.3 of the list? Please?.. Pretty 
please?.. Jeez, that surely feels awkward.

On 2017-08-15 10:51, Vladimir Batov via Boost wrote:
> After much procrastination I would like to request a formal review for
> the pimpl library... once and for all :-) (given it's been through a
> few almost-reviews and discussions)... to get some kind of a
> resolution one way or the other. :-)
> 
> On one hand it is embarrassingly simple and no match to a string of
> late TMP submissions. On the other hand it seems quite handy for
> ordinary s/w folk (like me) as it formalizes, streamlines and
> noticeably simplifies (IMO) pimpl-based deployments and makes
> code-review process quite simple and straightforward. Its benefits are
> more visible for pimpls with exclusive-ownership proxy-implementation
> relationships (value-semantics pimpls) as it uses internally an
> incomplete-type management smart pointer instead of std:unique_ptr.
> 
> Given that it is policy-based I am hoping others might get interested
> writing additional policies within that framework such as COW or
> stack-based.
> 
> The major oddity/peculiarity (that caused a stir before and Gavin
> mentioned about a year ago) is that the main class -- impl_ptr -- is
> declared in the global namespace. That might happen to be a deal
> breaker but that's the best I could come up with to get it to work. If
> anyone has a better working solution, I am all ears.
> 
> That "oddity" is an "implementation detail" and does not affect the
> user -- from the user side it appears inside boost. Like
> boost::impl_ptr... Internally to address that we might think of
> striking a compromise. For ex., instead of the traditional
> 
> namespace boost { template<> class impl_ptr }
> 
> have
> 
> template<> class _boost_impl_ptr_
> 
> Again, that is an implementation nit, wrinkle, niggle (IMO anyway).
> From the outside it all looks kosher -- boost::impl_ptr<...> and such.
> 
> The code and the docs are at https://github.com/yet-another-user/pimpl
> <https://github.com/yet-another-user/pimpl>.
> 
> Due to personal circumstances Glen -- Pimpl's original manager -- had
> to bail out. So, if anyone kindly steps forward to manage the review,
> that'd be immensely appreciated.
> 
> ​Thank you,
> Vladimir.​
> 
> 
> P.S. Ron, I am only CCing you so that you'd put it to the schedule... 
> Tnx.
> 
> 
> _______________________________________________
> Unsubscribe & other changes: 
> http://lists.boost.org/mailman/listinfo.cgi/boost