11/29/2012 4:17 PM, Jonathan M Davis пишет:
On Thursday, November 29, 2012 12:39:19 Paulo Pinto wrote:
On Thursday, 29 November 2012 at 03:19:55 UTC, Andrei
Alexandrescu wrote:
On 11/28/12 9:34 PM, Walter Bright wrote:
For discussion:
[snip]
I'd say we better finish const, immutable, and shared first.
Andrei
+1
Fully agree.
Cyclic imports are a minor nuisance that can be easily solvable
with better code architecture.
Turbo Pascal/Delphi is the only language that I know fully allows
cyclic dependencies between modules. So this is not that
important for most people.
Basic features in the language require static constructors (e.g. static
variables frequently do), and some things just can't be done without them.
Andrei's std.benchmark proposal actually doesn't work, because in order to do
what it does, in needs to mixin in a static constructor and static destructor
(to set up the benchmarking and record it at the end, I believe). That
completely falls apart due to cyclical imports.
I do suspect it could be healed by inverting the control flow (or rather
bringing it back).
Basically there is this pattern:
module a;
...
mixin ScheduleForBenchmark;
Same for module b, c, d...
And then compiling all of this with -version benchmark should run the
benchmarks.
It already has another problem: there has to be D main stuffed in there
somehow. It can't be in std.benchmark as it then will have to be
included in phobos(.lib|.a) and it can't be magically turned on/off with
-version switch either unless std.benchmark is passed directly to the
compiler.
The other solution would be: make a separate my_benchmark.d module that
contains:
import a,b,c,d...;
void main(){
runBenchmarks!(a,b,c,d...)();
}
And that's it.
In any case I usually like having some separation between different sets
of modules to benchmark so that I can start them in a 'clean room' scenario.
It doesn't actually cause any
true circular dependencies, but it's treated as such anyway. A _lot_ of us
have run into this problem and a number of us consider it to be a huge design
problem in the language. Personally, I'd put it towards the top of design
mistakes at this point, and I'm very glad to see Walter actually finally being
willing to do something about this. In the past when I've brought up similar
solutions, he's been completely opposed to them.
Yes, we have other major issues that need to be resolved, and those may very
well be of a higher priority, but this is still a very import issue, and it's
the sort of issue that can probably be implemented with minimal effort. The
main thing is getting Walter to agree to it and how it will be done. Once a
decision is made, it wouldn't surprise me if someone like Kenji were able to
get it done very quickly.
- Jonathan M Davis
--
Dmitry Olshansky
