Re: [boost] [mirror] -- RFC

Subject: Re: [boost] [mirror] -- RFC
From: Matus Chochlik (chochlik_at_[hidden])
Date: 2009-03-31 05:10:34

On Mon, Mar 30, 2009 at 8:40 PM, Edward Diener <eldiener_at_[hidden]> wrote:
> Matus Chochlik wrote:
>>
[snip]

>
> I would like to encourage you in your pursuit of compile-time/run-time
> reflection/introspection. But...

Thanks for the encouragement

>
> You need to fully document your library rather than producing examples
> and assuming that people will be able to pick up its functionality from
> them.

Yes, I guess this is not the best way to introduce a library to potential users.
I did it this way because I wanted to get some opinions before I wrote the
complete docs and have to rewrite them all over again in case there are some
major objections to the public interface of the library.

>
> In your documentation I could not see where there is a clear
> explanation of how to get a class's functions and data, along with their
> corresponding types and member names. In other words you need to present
> co-ordinated documentation which shows how and what can be introspected
> from any given level. That I can create macros, which create underlying
> templates for metadata, for C++ constructs I generally understand, but how
> they are actually used needs much better documentation and not just random
> examples.

I see .. I'm going to write some more lifelike commented examples on the
usage of the individual features.

>
> Also whatever I saw looked pretty intrusive. I could not understand if
> your library has the ability to create metadata from types in header
> files without modifying the files.

You always can separate the base-level declarations from the Mirror
registering stuff by putting them into separate headers and include them
both in the application sources. The only case when Mirror needs to be
intrusive is if you want to reflect private member attributes not accessible
from the outside and the intrusion is usually a one-line addition
to the class' declaration.

>
> I would also strongly suggest that for the first iteration of your
> library you strive to present a single way of defining or using anything
> for simplicity's sake. As an example, forget about the macros which are
> just another name for another macro and present a single macro which
> does a particular thing. Ditto for everything else. If you attract
> people to the use of your library, you can then create as many shortcuts
> as you like in order to make things more flexible, but in the beginning
> you should strive to make things as easily understandable as possible and as
> uncomplicated as possible from the end user's point of view.

Sounds reasonable, thanks for Your suggestions.

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

Best regards,

mch