> 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 _______________________________________________ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
