CTFE and DI: The Crossroads of D

[Nick Sabalausky]

"Adam Wilson" <flyboynw at gmail.com> wrote in message 
news:op.wd2prcc4707hn8 at invictus.skynet.com...
>
> I actually agree with you, im just telling you what I hear from PHB's.
>

I was just kinda rambling anyway ;) Not directed at any particular poster.


> We need some way to export the symbols without the underlying code, it 
> makes for faster compile times and having the API handy can be useful to 
> development tools.
> However, my experience with PHB's is that as long as you don't send out 
> the actual source files but some form of sanitized header, the PHB's don't 
> really care beyond that.
> That'd why I think embedding a version of the source D files that has been 
> semantically analyzed could be helpful, you can pull in the source for 
> CTFE as needed, but the only thing you have to actually ship out is the 
> library file itself, it just happens to have source files inside. In my 
> experience in the .NET world, this is good enough for the PHB's. Out of 
> sight, out of mind as they say. So what if it's trickery, we developers 
> get a benefit to, we don't have to wrangle include files.
>

Well, if that works for the PHBs, then it works for me (Hmm...Never thought 
I'd say something like that ;) )

Thinking about it more, I suppose it's debatable whether a PHB-comlpiant 
obfuscator or a lib-with-embedded-source would be easier to implement and 
deal with.