proposal: lazy compilation model for compiling binaries

[JS]

On Tuesday, 25 June 2013 at 09:35:52 UTC, Jacob Carlborg wrote:
> On 2013-06-24 23:33, JS wrote:
>
>> Having one file to share is better than many. It makes it 
>> easier to
>> version, easier to maintain, and easier to distribute.
>>
>> It is better than just zipping the collection of files, e.g. 
>> jar's,
>> because it allows for better structural encoding but is 
>> effectively the
>> same. Utilities can be used to extract/view specific 
>> information if needed.
>>
>> The main benefit is versioning. One never has to worry about 
>> different
>> parts of the library being out of sync because *everything* is 
>> compiled
>> to one file. There is nothing to maintain except the source 
>> code.
>
> Are you meaning we should put all the source code/.di files 
> into the libraries? The library will then both provide the API 
> and the implementation.

While one could do that it generally isn't necessary or even 
desirable.

The compile time constructs I mentioned are required to use the 
library(e.g., interfaces) or useful for debugging/testing(generic 
unit tests and contracts).

One could add the ability to include the source code for 
debugging purpose if desired.

The idea is rather simple. Suppose you are writing a library. You 
design some code, some unit tests and contracts. Suppose you have 
to pass around delegates/functions between your library and user 
code.

Do you require the user to implement the unit tests and 
contracts? Does he have to copy and paste? Why not just have some 
type of generic unit test and contract that the user can call on 
his functions to make sure they pass *your* tests? If you can 
include them in your library then they can act like normal meta 
functions that can be used without requiring the user to see the 
guts.