David Abrahams wrote:
Joel de Guzman <[EMAIL PROTECTED]> writes:
Hmm. I'm not sure I like having to label each snippet I might want to
process with a collector.
Do you have a certain suggestion in mind?
If the collector identifier is in quotes, the collector is
assumed to be a file. Example:
[collect "test.cpp"]
A file collector will collect all successive code snippets into
the specified file.
When we have a way of labelling examples in quickbook, it would be
nice if there were an automated way to turn the example label into a
filename, e.g. chapter5/example13.cpp
? Won't [copy "chapter5/example13.cpp" label] handle that?
Ok, you say it should be:
[copy label to "chapter5/example13.cpp"]
The collect directive with a file id will
empty the file and open it for writing.
Each time the filename appears in a directive? Only the first time, I
hope!
Sure :-) Only the first time.
All open files are closed at the end of quickbook processing.
And then what?
In C++ Template Metaprogramming I have examples that I want to
compile, preprocess, build and run, or fail compilation. So far I
don't see any connection to backend processing here. In Litre writing
directives in Python means that I can embed semantics about the
treatment of these snippets, and can extend the way they are handled.
Here's my line of thinking, tell me what you think:
Separation of concerns...
I think that compiling, preprocessing, building and running, etc,
should not be the job for QuickBook. Instead, this should be a
job of the build tool, in this case, BJam. I could, for example
have a "collector" that generates a Jamfile that can be
invoked automatically after the QuickBook session, perhaps
triggered by the same Jamfile that invoked the QuickBook session.
I figured that this would amount to the same thing. No?
1) Copy src into destination. dest will have the same contents as src.
[copy dest src]
Why not [copy src dest]? (from,to) is most natural for most of us, IMO.
Sure. Agreed:
[copy src to dest]
Append
Collectors may be appended to other collectors, pushing the text from
the source collector into the destination collector. Examples:
1) Dump src to dest. dest will be appended with whatever src had.
^^^^^^^^^^^ ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
These two things seem contradictory.
Maybe "appended with" is supposed to be the opposite of "appended to?"
[append dest src]
Anyway, normal English usage is "append A to B" so I suggest you make
that mean "append dest to src." Also, src->dest is more natural for
most of us.
Ok, no problem:
[append src to dest]
2) Dump src into "file.cpp".
[append "file.cpp" src]
Ditto.
Clear
[clear x]
I don't see any facilities for results processing here. Also Litre
See above.
has a lot of less-important features you haven't addressed here; not
sure if you're intentionally leaving those out for now or it's an
oversight.
Oh, sure. Those are icings in the cake. As soon as the meat of the
facility is ironed out, it would be fun to have all these bells
and whistles :-)
Thanks for your input!
Regards,
--
Joel de Guzman
http://www.boost-consulting.com
http://spirit.sf.net
-------------------------------------------------------
SF email is sponsored by - The IT Product Guide
Read honest & candid reviews on hundreds of IT Products from real users.
Discover which products truly live up to the hype. Start reading now.
http://ads.osdn.com/?ad_id=6595&alloc_id=14396&op=click
_______________________________________________
Boost-docs mailing list
[email protected]
Unsubscribe and other administrative requests:
https://lists.sourceforge.net/lists/listinfo/boost-docs
