On 2011-07-14 21:15, Nick Sabalausky wrote:
I assume you meant "mixin" instead of "writeln".
Doesn't matter. It's the import statement I'm referring to.
What I meant is that, suppose wr have this:
// internal_to_drake.d:
void main()
{
mixin(import("main.d"));
}
// main.d:
import blah;
// rest of buildscript...
Then that becomes:
void main()
{
import blah;
// rest of buildscript...
}
And *that's* a brand-new feature. And I think there may be some other
things, too, that might still be a little buggy if they're stuck inside a
function like that.
Ah, now I see. I'm hoping the user never needs to write import
statements in the build script. It's just these little things that I
don't like about using D for the build scripts. Imports and no top level
code.
- I wasn't sure if a D file that isn't strictly a proper D file would be
too
weird, too confusing, too magical, or would confuse the fuck out of
advanced
IDE's.
I have no idea how an IDE would behave with an incomplete file like that.
I pretty sure this only matters if the IDE does some semantic processing,
i.e. something more than just syntax highlighting. Textmate, which
basically only does syntax highlighting, has no problem with an incomplete
D file.
Right, but a lot of people use fancy IDE's like Eclipse and Visual Studio.
Exactly.
Maybe you're thinking D1? I *think* the thread-local-by-default is D2-only
(though I'm not certain).
I was thinking in Ruby, but I've already answered this in another post.
--
/Jacob Carlborg
