Encapsulation and data hidding
- Hi Karl, H Ina,
> Ian McCulloch wrote:This is the big problem! How to hide the data while in fact still allowing
>Good idea, but in this case are these used by external bindings?
external access to it.
This can be done by making things private but providing a loop hole via a
friend 'accessor' class. Such a change may however only make things more
complex without really improving the data hidding!
> Karl Meerbergen wrote:Agreed
> I think the discussion should be held. I think that internal data with a
> type that always is a ublas type, for example, type_category,
> functor_type, range, etc, this is fine: they can remain private with a
> const reference to the outside world.
> However, I believe it may be dangerous for other types, such asThis was more of a pre-discussion. You could say I was talking of the top of
> value_array_type or index_array_type since these can be anything. The
> danger is a lack of freedom. The use of the non-const references is the
> responsability of the user of course.
> So, please think well before you make any decisions of this kind.
I think this is the same issue as previously discussed with the storage format
for coordinate matrices. Using existing data formats and being able to bind
with other libraries is more important then data hiding etc.
So don't worry I don't think I will be making any such changes.
Michael Stevens Systems Engineering
Navigation Systems, Estimation and
- Michael Stevens wrote:
>Hi Karl, H Ina,I support this idea. It is more difficult to modify private data by
>>Ian McCulloch wrote:
> >Good idea, but in this case are these used by external bindings?
>This is the big problem! How to hide the data while in fact still allowing
>external access to it.
>This can be done by making things private but providing a loop hole via a
>friend 'accessor' class. Such a change may however only make things more
>complex without really improving the data hidding!
accident. This is what we want I suppose. Using an accessor supposes you
know what you are doing.
I suppose you get something like:
matrix<T> m(...) ;
matrix<T>::accessor m_access( m ) ;
matrix<T>::accessor( m ).data()