Loading ...
Sorry, an error occurred while loading the content.

Encapsulation and data hidding

Expand Messages
  • Michael Stevens
    Hi Karl, H Ina, ... 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
    Message 1 of 2 , Sep 1, 2004
    • 0 Attachment
      Hi Karl, H Ina,

      > 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!

      > Karl Meerbergen wrote:
      > 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.
      Agreed

      > However, I believe it may be dangerous for other types, such as
      > 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.

      This was more of a pre-discussion. You could say I was talking of the top of
      my head!

      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
      --
      ___________________________________
      Michael Stevens Systems Engineering

      Navigation Systems, Estimation and
      Bayesian Filtering
      http://bayesclasses.sf.net
      ___________________________________
    • Karl Meerbergen
      ... I support this idea. It is more difficult to modify private data by accident. This is what we want I suppose. Using an accessor supposes you know what you
      Message 2 of 2 , Sep 1, 2004
      • 0 Attachment
        Michael Stevens wrote:

        >Hi Karl, H Ina,
        >
        >
        >
        >>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!
        >

        I support this idea. It is more difficult to modify private data by
        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 ) ;
        m_access.data() ;

        or

        matrix<T>::accessor( m ).data()


        Karl
      Your message has been successfully submitted and would be delivered to recipients shortly.