|
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;
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 dave_at_[hidden] * http://www.boost-consulting.com Boost support, enhancements, training, and commercial distribution
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk