I just wanted to put forth that I really could use an offline code generator for my work on the OOTL. I only want a handful of interfaces for the library which won't change often. The benefits for me are: a) I won't have extra boost dependencies for meta-programming b) have the fastest possible compile times for my library Christopher Diggins Object Oriented Template Library (OOTL) http://www.ootl.org
christopher diggins wrote:
I just wanted to put forth that I really could use an offline code generator for my work on the OOTL. I only want a handful of interfaces for the library which won't change often. The benefits for me are:
a) I won't have extra boost dependencies for meta-programming b) have the fastest possible compile times for my library
I'm laying the foundation for this right now. Now that there are going to be several ways to generate classes representing interfaces, I have to write a detailed specification of interface internals so that the various mechanisms will be compatible. For instance, you should be able to derive an interface from two base interfaces, one of which was generated by an IDL compiler and the other of which was generated by macros. I think I've developed an adaquate specification; I'm in the process of modifying the current implementatin so that it satisfies the specification. Jonathan p.s. BIL is no longer an acronym, it's an ordinary word -- just like OLE was for a while. Or, maybe I should say it stands for "BIL Isn't Legit (yet)"
----- Original Message ----- From: "Jonathan Turkanis" <technews@kangaroologic.com>
I think I've developed an adaquate specification; I'm in the process of modifying the current implementatin so that it satisfies the specification.
Great, I am really looking forward to it. I just wanted to go on the record as saying I am now just as happy with hand-written interfaces as machine written, at least for the forseeable future.
Jonathan
p.s. BIL is no longer an acronym, it's an ordinary word -- just like OLE was for a while. Or, maybe I should say it stands for "BIL Isn't Legit (yet)"
In light of recent (valid) concerns brought up by David, I would like to have the next version of the BIL outside of the Boost namespace and not in a folder named Boost. I hope this isn't too much to ask? This might in fact be a good practice for all new proposed and experimental libraries. Christopher Diggins Object Oriented Template Library (OOTL) http://www.ootl.org
christopher diggins wrote:
----- Original Message ----- From: "Jonathan Turkanis" <technews@kangaroologic.com>
I think I've developed an adaquate specification; I'm in the process of modifying the current implementatin so that it satisfies the specification.
Great, I am really looking forward to it.
I just wanted to go on the record as saying I am now just as happy with hand-written interfaces as machine written, at least for the forseeable future.
Okay.
Jonathan
p.s. BIL is no longer an acronym, it's an ordinary word -- just like OLE was for a while. Or, maybe I should say it stands for "BIL Isn't Legit (yet)"
In light of recent (valid) concerns brought up by David, I would like to have the next version of the BIL outside of the Boost namespace and not in a folder named Boost. I hope this isn't too much to ask? This might in fact be a good practice for all new proposed and experimental libraries.
I hope this is not necessary: 1. It will make it harder for me to look at old revisions of files, since I am using CVS locally 2. It may hide potential naming conflicts 3. It will make the regression tests harder to run 4. It will mean I can no longer make the code available in the sandbox CVS, except perhaps as a zip. (I added the library to the sandbox a few feeks ago) I believe Dave was mostly concerned with people getting the wrong impression about the Boost submission process by observing casual conversions. People who are actually using the library will know it's unofficial because of all the disclaimers. I think the correct time to change the directory structure and namespaces would be if the library is reviewed and rejected. Jonathan
----- Original Message ----- From: "Jonathan Turkanis" <technews@kangaroologic.com>
In light of recent (valid) concerns brought up by David, I would like to have the next version of the BIL outside of the Boost namespace and not in a folder named Boost. I hope this isn't too much to ask? This might in fact be a good practice for all new proposed and experimental libraries.
I hope this is not necessary:
1. It will make it harder for me to look at old revisions of files, since I am using CVS locally 2. It may hide potential naming conflicts 3. It will make the regression tests harder to run 4. It will mean I can no longer make the code available in the sandbox CVS, except perhaps as a zip. (I added the library to the sandbox a few feeks ago)
Then it would be clearly too inconvenient. It is in my best interest to see development on BIL continue as fast as possible.
I believe Dave was mostly concerned with people getting the wrong impression about the Boost submission process by observing casual conversions. People who are actually using the library will know it's unofficial because of all the disclaimers.
I think the correct time to change the directory structure and namespaces would be if the library is reviewed and rejected.
That is reasonable. Christopher Diggins Object Oriented Template Library (OOTL) http://www.ootl.org
christopher diggins <cdiggins@videotron.ca> writes:
----- Original Message ----- From: "Jonathan Turkanis" <technews@kangaroologic.com>
I think I've developed an adaquate specification; I'm in the process of modifying the current implementatin so that it satisfies the specification.
Great, I am really looking forward to it.
I just wanted to go on the record as saying I am now just as happy with hand-written interfaces as machine written, at least for the forseeable future.
Jonathan
p.s. BIL is no longer an acronym, it's an ordinary word -- just like OLE was for a while. Or, maybe I should say it stands for "BIL Isn't Legit (yet)"
In light of recent (valid) concerns brought up by David, I would like to have the next version of the BIL outside of the Boost namespace and not in a folder named Boost. I hope this isn't too much to ask? This might in fact be a good practice for all new proposed and experimental libraries.
I have been trying to say that I really think this is overkill. For a large library fixing the namespace could be problematic, and we won't discover potential integration problems and naming conflicts until much later. You're free to do whatever you want, of course, but I oppose adopting this as a Boost convention. -- Dave Abrahams Boost Consulting www.boost-consulting.com
participants (3)
-
christopher diggins -
David Abrahams -
Jonathan Turkanis