"[EMAIL PROTECTED]" <[EMAIL PROTECTED]> 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;
    private:
       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
   [EMAIL PROTECTED] * http://www.boost-consulting.com
Boost support, enhancements, training, and commercial distribution

_______________________________________________
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost

Reply via email to