Re: [boost] Interest in a 'Boost.property' library?

Subject: Re: [boost] Interest in a 'Boost.property' library?
From: Klaim - Joël Lamotte (mjklaim_at_[hidden])
Date: 2013-07-08 11:41:09

On Mon, Jul 8, 2013 at 11:19 AM, Evgeny Panasyuk
<evgeny.panasyuk_at_[hidden]>wrote:

> 08.07.2013 12:33, Klaim - Joël Lamotte:
>
>  This is surely a controversial feature.
>> I see some use of properties, like allowing to add checks on setting
>> values
>> to a type which was a simple struct initially
>> (which happen a lot in data-centric designs).
>>
>
> If check does not need any internals of enveloping object, or does not
> need to be overridable by enveloping class descendants - which is often the
> case - then in C++ - it should be done just like normal concrete class,
> with invariants established in constructors.

That is not at all the point I was making, my point is that code evolve.
While it's ok to have naked struct in some data-centric designs, sometimes,
after use, you might realize that some of these struct still need some kind
of checks
on access (or on copy or in some other conditions) which just help getting
correct data.
IF you happen to be in this specific case where you have that naked struct
that needs to be enhanced with access checks because of evolution of design,
THEN changing access to member functions often imply a lot of changes in
the code base while it's only the internal semantic of the type that you
need to change,
not the actual interface.
I've found this case maybe 2 or 3 times in the last 10 years while working
on very big code bases and I know it can make you loose time in days, so
most of the
time you want to avoid it in the first place and learn to use memver
function only.
But then the role of function member when you see it in code is to imply
processing, while the role of property is to imply transparent checks
followed by access
or modification of a specific object. So having a specific interface to
clarify the difference and in the same time make the code easy to change is
to me a win. Not a big win but a win nonetheless.

That being clarified, for me it's a minor feature for language design, with
weak priority, but I still see some interesting use.
It's kind of like all these C++ features you use maybe once every pair of
years but makes you express your intent exactly and
help doing things fast. It's not as important as features you use everyday,
but it would be interesting nontheless.

Now as I was saying, I don't see the point in a library version of it.
If I remember correctly, works on Reflection for C++ points to a way to
implement properties as a library construct but it would require Reflection
obviously.

Joel Lamotte