Boost logo

Boost :

Subject: Re: [boost] Interest in a 'Boost.property' library?
From: Evgeny Panasyuk (evgeny.panasyuk_at_[hidden])
Date: 2013-07-08 12:49:10


08.07.2013 19:41, Klaim - Joël Lamotte:
>>> 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.

IF all that you need is to move from basic data types to something with
checks, while keeping same syntax THEN properties (as well as getters
and setters) are not needed at all - just use concrete classes with
invariants established by constructors: http://ideone.com/frui7Z - this
example doesn't have any properties-like stuff, while it have checks in
second case and same syntax.

I think need for properties-like things may arise IFF: "property"'s
set/get need access to enveloping object or set/get should be
overridable by enveloping class descendants, while keeping same syntax.

-- 
Evgeny Panasyuk

Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk