Re: [boost] Adding polymorphic_value to boost

21 Nov 2017

      On 20 November 2017 at 22:51, Richard Hodges  wrote:
...
...
It will take me some time to digest and come back with questions.
This is a subject close to my heart, so please feel free to question as
much as you wish.
...
Pleasingly we seem to be debating how useful this type can be rather
than whether it’s useful at all.
As far as I am concerned, cloned_ptr was the missing piece to the puzzle
of consistent handling of handle/body objects - particularly when
polymorphic. It allowed value-semantic coding to be a reality in a
consistent way. Have no fears over utility.
While pointers provide the power behind c++, I am strongly of the view
that building user code around value types is preferable from the points of
view of maintainability, elegance and provable correctness. With a little
tweak this class could spell the end for pointer-based paranoia in user
code forever. That's a wonderful thing.
What strikes me as the masterstroke in the proposed implementation is the
type-erased copy/deletion which eliminates the need for clone. I wish I'd
thought of it. In that respect your implementation is beautiful.
On 20 November 2017 at 23:37, Jonathan  wrote:
...
...
On 20 Nov 2017, at 22:11, Richard Hodges via Boost <
boost@lists.boost.org> wrote:
sent direct to Jonathan in error - reproduced here:
...
polymorphic_value solves a very real problem and allows deletion of a
large amount of error-prone boiler-plate code.
completely agree. It would allow deletion of even more code if it didn't
propagate_const.
...
Without the second category, the first is just an implementation
detail.
Fine. Let's make it a policy. Then everyone's happy. The truth will out.
...
I’d really like to see real examples
Sometimes (in a comms-based system, often) even though the handle
object's
interface is const, and accessor will do some internal work which may
need
to mutate the implementation (even on another thread). I spend a lot of
time writing comms/protocol code which I normally implement as asio
services. Database access, websockets, AMQP messaging, http, etc.
If you've spent any time with asio you'll know all about the handle-body
idiom and all the nasty boilerplate required to correctly implement
move/copy/sharing of io objects bound to an executor.
Sometimes I'll want the concept of an object and I may decide to give it
shared-body semantics. But then I realise I can get a
performance/correctness win by providing the same interface but with
different copy/move behaviour.
Sometimes I realise I need such an object which will just clone itself
when
copied.
It is useful to write these objects in terms of:
template class Pointer>
struct basic_foo
{
 // ..
Pointer impl_;
};
now I can specialise:
struct unique_foo : basic_foostd:unique_ptr { };
struct shared_foo : basic_foostd:shared_ptr { };
struct value_foo : basic_fooboost::polymorphic_value { };
struct foo_observer : basic_foostd::reference_wrapper { };
I have implemented both the interface and the implementation only once
and
am now afforded complete flexibility in how I manage my foos.
With a tiny bit more templatery I can even automatically get:
auto a = unique_foo(...);
auto b = shared_foo(std::move(a));
or
auto a = value_foo(...);
auto b = a;
auto c = shared_foo(std::move(a));
and I can always get:
auto o1 = foo_observer(b), o2 = foo_observer(c);
The consistency is important (at least to me) because it affords perfect
composability.
...
On 20 November 2017 at 22:36, Jonathan Coe 
wrote:
On 20 Nov 2017, at 21:12, Richard Hodges via Boost <
boost@lists.boost.org>
wrote:
...
...
None of these make copies.  polymorphic_value is
not called XXX_ptr precisely because its semantics
are different from a pointer.
shared_ptr, unique_ptr and reference_wrapper are all "different" from
a
pointer, but they all share 4 common traits:
1. The all manage/observe lifetime of another _single_ object in some
defined but distinct way.
2. They all allow access to that object through operator*
3. They don't propagate const.
4. they don't have any pointery arithmetic behaviour
Looking at the design history of polymorphic_value it seems that it
originally came from a desire to complete the circle by providing
another
XXX_ptr which supported copying.
This aim is _eminently useful_ as is evidenced by the numerous
implementations of things like it on github (and in my own code).
I also have an interest is such an object as standard because I always
seem
to end up needing one.
I do not have a use case for a const-propagating one. Never have. I
can
specify const in the angle-brackets. I've done that probably once.
...
This situation doesn't make sense for polymorphic_value.
To you perhaps. However I have 3 projects on the go right now which
could
use polymorphic_value immediately as a retro-fit for home-made
solutions
*if it did not propagate const*.
The concept of propagating const I can deal with trivially. To
incorporate
it into this class mixes concerns to the detriment of its usefulness
(to
me).
So If it came to a vote and my voice had any weight, I would say:
* with implicit const-propagation - NO
* remove the const propagation - absolute YES
additionally, ideally rename it back to cloned_ptr, (or indirect if
you
must). Because what it is absolutely not is a value.
It is logically the same as the other 4 non-pointers listed above,
it's
just that it have different owned-object lifetime behaviour.
I completely understand the value-centric argument. I am a strong
proponent
of it.
My argument is that this is (or ought to be) a tool for *building*
value
types. It is not in of itself a value type, and neither can it ever
be.
It
does not exhibit any "value" behaviour (equality and the like).
R
On 20 November 2017 at 21:35, Steven Watanabe via Boost <
boost@lists.boost.org> wrote:
...
AMDG
> On 11/20/2017 01:11 PM, Richard Hodges via Boost wrote:
> I watched Sean Parent's talk covering what has now become
polymorphic_value.
>
> One thing that I am concerned about is Sean's insistence on
propagating
> const implicitly.
>
> This would be at odds with the behaviour shared_ptr, unique_ptr, and
> reference_wrapper.
>
None of these make copies.  polymorphic_value is
not called XXX_ptr precisely because its semantics
are different from a pointer.
> Sometimes I want a const pointer to a mutable thing, and sometimes I
want a
> mutable pointer to a const thing (and sometimes I want to be able to
> observe a thing without affecting its lifetime).
>
This situation doesn't make sense for polymorphic_value.
> So my 2-pence would be that propagate_const should not be implicit
in
this
> class.
>
> My rationale is that an obvious use case for me would be
manufacturing
> specialisations on pointer_type allowing a consistent interface
leading
to
> an inner implementation while simply changing ownership behaviour.
>
> In that sense I am strongly of the view that the return type of
> polymorphic_value<Foo>::operator*() const should be Foo& and not
const
Foo&.
>
> If I want a polymorphic cloning pointer to const Foo I can declare
it
with
> polymorphic_value<const Foo>.
>
> I have never had reason to quibble with Sean's thinking before now,
but
on
> this he is dead wrong.
>
> If I want const propagation, it's simple enough to wrap any pointer
in
> propagate_const<>
>
> This feels to me like idealists overriding pragmatists.
>
> Or have I missed something obvious?
>
In Christ,
Steven Watanabe
_______________________________________________
Unsubscribe & other changes: http://lists.boost.org/
mailman/listinfo.cgi/boost
_______________________________________________
Unsubscribe & other changes: http://lists.boost.org/
mailman/listinfo.cgi/boost
It’s interesting how quickly people become polarised on this. One
thing to
note is that polymorphic_value<const T> is not the same as a
const-propagating polymorphic_value<T>; I hope that puts us all on the
same
page.
polymorphic_value is designed so that compiler-generated special member
functions for objects with polymorphic components (sub-objects) are
generated correctly. As such it needs to propagate const. There’s no
sense
in part of an object being mutable in a context where the object
itself is
immutable.
polymorphic_value solves a very real problem and allows deletion of a
large amount of error-prone boiler-plate code.
Some people don’t want const-propagation because they favour a
composable
deep-copy + deep-const combination type. Some people have a use case
for a
deep-copying non const-propagating pointer-like hybrid type. Without
the
second category, the first is just an implementation detail. I’d really
like to see real examples (not thought-experiments) that are solved by
a
type like cloned_ptr. I have never encountered one but my experience
is not
so broad and I’m well aware that absence of evidence is not evidence of
absence.
_______________________________________________
Unsubscribe & other changes: http://lists.boost.org/mailman
/listinfo.cgi/boost
I have no experience with ASIO, thanks for taking the time to put some
examples together. It will take me some time to digest and come back with
questions. Pleasingly we seem to be debating how useful this type can be
rather than whether it’s useful at all.
Regards,
Jon
Do you have sample code you might be able to share to illustrate this
point: "Sometimes (in a comms-based system, often) even though the handle
object's
interface is const, and accessor will do some internal work which may
need to mutate the implementation (even on another thread)." I'm afraid
this example is sufficiently removed from my day-to-day experience that I
struggle to see what you mean without code. An utterly unambiguous example
that's not driven by a theoretical desire for type consistency will
motivate adding `cloned_ptr`.

`polymorphic_value` should probably stay as it is, I would add `cloned_ptr`
too as they serve rather different purposes.

regards,

Jon

PS There may be considerable to-and-fro in putting an example together,
would it be wise to take this discussion off list?