On Tue, 12 Mar 2013 17:40:15 GMT, Robert wrote:

Well, depending on the use case that may be the case, or may be not (you can only consider actual module clashes as a conflict, or you can already count package clashes as conflicts). Anyway, I fail to see the problem, even when capturing all modules.

Counting package clashes as conflicts does not work. Think of "org.eclipse.swt", most certainly another package should be allowed to use the "org" package or "org.eclipse" or even "org.eclipse.swt.something.not.in.the.base.dwt.package". Not even restricting the check to leaf packages (packages containing only modules) would be ok in all cases, if we think of C libraries that are made available via a single D module. But I agree, having to capture all modules is no real problem.

You are right, modules in the root package are certainly a problem. Also the app.d file would have to be taken out of the equation.

But maybe just counting packages with actual modules + top level modules would work. I just try to get in that direction because I think that detecting just module conflicts is a bit too relaxed and it would be good to come as close as possible to the restricted system in that regard (without introducing child packages, which could of course still be done, even if just for different reasons).

I have to think a bit more about the consequences of not implementing my proposal, but with the right infrastructure and tools available, most issues should be solvable. E.g. having an IDE showing me the containing package name when I hover over an import line, having a commit hook that calls dub with some parameter that checks for conflicts with the registry, ...

Sorry, but that's a totally unrealistic case you make up there. Please, show me where such conflicts happen in reality and we can talk about it, but constructing cases like this is just... after all we have concrete issues with the restricted case but still not one concrete example of issues with the unrestricted case (and there is a sheer unlimited set of examples in the world).

I don't exactly know what you are referring to? To the commit hook thing? I am just saying that one can set up something like that, if he wants to be on the safe side. But never mind, it is quite possible that I am taking this conflict stuff a bit to serious. If you refer to the first sentence about consequences, I was not thinking about conflicts in this case, but rather whether my original goals for a package manager can still be met. "Consequences" might have been a bit of a too hard word, what I wanted to say was: "I have to think everything through again on top of the changed semantics".

I think I got your sentence mixed up a bit. Rereading it, I really don't know what I was talking about exactly and need to apologize for the slightly rude tone. I just think the commit hook is not any more or less needed than for the restricted case - just that the restricted case could just check the package name instead + verify locally that no forbidden name space is used.

Sorry, I can observe myself loosing track of the message while still reading it sometimes as my head is spinning with loads of other things (things like a HDD crash of my mail server didn't help there either). I severely need to get some things done to get my head free...