DIP11

[Jacob Carlborg]

On 2011-08-12 15:49, Steven Schveighoffer wrote:
> Note that the pragmas are specific to that file only. So you don't have
> an import file which defines pragmas. This is to prevent conflicts
> between two files that declare the same package override.

Now I'm not quite sure I understand. Are you saying that every file 
needs to have these pragma imports ?

>> In addition to that as soon as you need to pass flags to the compiler
>> you will most likely to put that in a file of some kind. In that case
>> you can just as easily put them in a build script and use a build tool.
>
> a batch files/shell script should suffice, no need for a "special" tool.

Yeah, but you would need to duplicate the shell script, one for Posix 
and one for Windows. As far as I know there is no scripting like file 
that both Windows and Posix can read out of the box.

>>> Essentially, the import statements become your "build file". I think
>>> dsss worked like this, but I don't remember completely.
>>
>> Yes, this is similar how DSSS worked. The difference is that you
>> didn't need a pragma to link a package to an URL you just wrote the
>> import declarations as you do now.
>
> IIRC, dsss still had a global config file that defined where to import
> things from. The DIP defines that -I switches can also define internet
> resources along with pragmas, so sticking those in the dmd.conf would
> probably be the equivalent.

Ok, I see.

>> One problem I think DSSS has, is, as far as I know, it can't handle
>> top level packages with same name. Or at least not in any good way. If
>> you go with the Java package naming scheme and name your top level
>> package after your domain, example:
>>
>> module com.foo.bar;
>> module com.foo.foobar;
>>
>> And another project does the same:
>>
>> module com.abc.defg;
>>
>> Then these two projects will both end up in the "com" folder. Not very
>> good in my opinion. In my solution every package has a name
>> independent of the packages it contains an all packages are placed in
>> a folder named after the package, including the version number.
>
> These all seem like implementation details. I don't care how the tool
> caches the files.

Well yes, but that is how DSSS works and that's what I'm explaining.

> Or instructions on the web site "use 'dmd -O -inline -release
> -version=SpecificVersion project.d' to compile"
>
> Or build.sh (build.bat) Note that dcollections has no makefile,
> everything is built from shell scripts. I almost never have to edit the
> build file, because the line's like:

You would need to shell script files, one for Windows and one for Posix, 
see above.

> dmd -lib -O -release -inline dcollections/*.d dcollections/model/*.d
>
> Any new files get included automatically. And it takes a second to
> build, so who cares if you rebuild every file every time?
>
> Interestingly, libraries would still need to specify all the files since
> they may not import eachother :) I don't know if there's a "good"
> solution that isn't too coarse for that.

That's what a build tool can handle. I think you should read this: 
http://dsource.org/projects/dsss/wiki/DSSSByExample and hopefully you'll 
understand why a built tool is a good thing.

> All of this discussion is good to determine the viability, and clarify
> some misinterpretations of DIP11, but I think unless someone steps up
> and tries to implement it, it's a moot conversation. I certainly don't
> have the time or knowledge to implement it. So is there anyone who is
> interested, or has tried (to re-ask the original question)?
>
> -Steve

I guess that's right.

-- 
/Jacob Carlborg