Boost logo

Boost :

From: David Abrahams (dave_at_[hidden])
Date: 2002-12-19 10:27:01

"craigp_at_[hidden]" <craigp_at_[hidden]> writes:

>> For fields, I do not think it is particularly useful to provide access
>> exclusively to the actual instance variables. It seems, however, that
>> access control specifiers of public, private, and protected are not
>> useful, however, because first of all, it seems that it would be
>> nearly impossible to enforce such control, and also I do not see how
>> it would be useful. There should really be no need to publish
>> anything but public fields.
> This really depends on the application. Here's a thought: perhaps we
> should distinguish between a reflection framework based on 'types'

Do you really mean 'data' here?

> vs 'code'. Code analysis and source-to-source translation tools may
> want more information than just type metadata, and in particular, it
> may be useful for them to know the access control of members. A
> reflection framework for persistence will only need to know about
> types. At this point, I think it makes sense to focus on type
> introspection first, and perhaps later consider the more general
> case of code-level reflection. I'm game if folks really want the
> latter, tho.
> I would argue that a truly useful type introspection framework would know
> about all types, public or private.

Surely you don't mean:

    struct X
       typedef int y;
       typedef int z;


> It won't be very useful for persistence otherwise. This may break
> encapsulation, but that's the nature of the beast.

I disagree that we have to settle for broken encapsulation. Look at
Python's "pickle" persistence system. You can maintain encapsulation
by supplying an appropriate __getinitargs__ function.

I also want to reiterate that visit_each() in the signals library
shows a lot of promise as a mechanism for serializing data members.

                       David Abrahams
   dave_at_[hidden] *
Boost support, enhancements, training, and commercial distribution

Boost list run by bdawes at, gregod at, cpdaniel at, john at