On Mon, Apr 23, 2012 at 6:21 PM, Nathan Ridge <zeratul976@hotmail.com> wrote:
- I think you are neglecting the aspect on how the user can choose the types that are going to be reflected. I believe not all types should have their metadata generated, at least to save on compile time on large projects. The way I did it in my preprocessor was using a pragma directive but it was much simpler than Mirror since it was only intended for classes. There migth be other ways, though, but it should be made more explicit. If reflection makes it into the standard, there shouldn't be any tools to generate the metadata besides the compiler. For the standard library, I guess that including a given header or using reflect operator would bring in the metadata.
Actually, this is one of my primary concerns. I also think that the way to go is not to reflect everything automatically, but to let the user to (somehow) choose what should be reflected. But i think that the process of "marking" namespaces, classes, etc. that should be reflected, should be decoupled from the declaration of the namespace, class, etc. because that would allow greater flexibility and also would allow to cherry-pick, what parts of 3rd-party libraries should be reflected in concrete applications based on their needs.
Since this is compile-time reflection, can't the compiler generate reflection metadata "on demand" (that is, whenever it is being queried) rather than the user having to explicitly mark classes as reflected, without any loss of efficiency?
This is actually mentioned in the "Implementation hints" section, and yes the compiler should generate meta-data lazily, but the problem is that I would like to be able to traverse the members of a scope (namespace, class, ...). You can imagine what would happen if such operation instantiated for example ALL members of the boost or std namespace. There are some ideas on how to solve this in the "Unresolved issues" section but it is rather complicated: - If we allow everything to be reflected the compile-times would be horrible, even worse if a run-time reflection facility was based on this meta-data so would be the resulting executable size. - If we allow some sort of "white-listing" (i.e. specify what you want) or "black-listing" (specify what you don't want) it would be inconvenient for some use-cases. I'm a fan of the "white-list" approach, but I would like to hear your opinions on this issue. BR, Matus