Re: [boost] Reflection Framework [was Serialization and Reflection]

From: craigp_at_[hidden]
Date: 2002-12-18 15:59:33

> 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' 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. It won't be very useful for
persistence otherwise. This may break encapsulation, but that's the nature
of the beast.

WRT fields, at one point you asked the question: why save the use-count in
a reference counted string? Say you're creating a debugging/profiling tool
which monitors objects: it may be very useful to know what the current
use-count of a particular object is. I would like to see, if possible,
*all* objects and types exposed; there could be further filtering and/or
higher level abstractions built on top of this framework.

--craig