On 12/05/14 20:58, Francesco Cattoglio wrote:
Error messages!
If your code is not compiled, you can't know whether it is valid or not.
I must say that since we have unittests, this is somewhat less relevant,
but still...
One nice thing would be stripping the executable of unneeded code.
One
Given that...
1. importing a module makes it compile the entirety of it, as
well as whatever it may be importing in turn
2. templates are only compiled if instantiated
3. the new package.d functionality
...is there a reason *not* to make every single
function/struct/class separate submodules
On Mon, 12 May 2014 08:37:42 +
JR via Digitalmars-d-learn digitalmars-d-learn@puremagic.com wrote:
Given that...
1. importing a module makes it compile the entirety of it, as
well as whatever it may be importing in turn
2. templates are only compiled if instantiated
3. the new package.d
On 5/12/14, 5:37 AM, JR wrote:
Given that...
1. importing a module makes it compile the entirety of it, as well as
whatever it may be importing in turn
2. templates are only compiled if instantiated
3. the new package.d functionality
...is there a reason *not* to make every single
On Monday, 12 May 2014 at 09:16:53 UTC, Jonathan M Davis via
Digitalmars-d-learn wrote:
Well, that would be a lot of extraneous files, which would be
very messy IMHO.
It also makes it much harder to share private functionality,
because
everything is scattered across modules - you'd be force to
On Monday, 12 May 2014 at 08:37:43 UTC, JR wrote:
What am I missing?
Error messages!
If your code is not compiled, you can't know whether it is valid
or not.
I must say that since we have unittests, this is somewhat less
relevant, but still...
One nice thing would be stripping the
You can write a tool, which will construct an amalgamation build
of your code.
