On Thursday, 29 November 2012 at 15:18:11 UTC, Paulo Pinto wrote:
On Thursday, 29 November 2012 at 12:04:28 UTC, Max Samukha
wrote:
On Thursday, 29 November 2012 at 11:39:20 UTC, 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.
Show me please how to solve that problem easily with
acceptable results, would you?
You just need to have a better architecture.
In 20 years of software development experience I never found a
case were this wasn't possible.
That's an argument from authority, sorry.
Maybe you care to provide an example?
The general problem is constructing global data structures based
on data introspected at compile-time.
My specific problem is extending scarce runtime type information
provided by the language with something usable for runtime
reflection. With lots of detail omitted:
module reflect;
Meta[string] metas;
mixin template Reflect(alias object) {
static this()
{
auto m = meta!(object);
metas[m.fullName] ~= m;
}
}
module a;
import reflect;
struct S
{
}
mixin Reflect!S;
The meta-object for S is automatically made available at runtime
through the global metas array. Note that we do not want to force
the user to register the meta-object manually because then it
would not be a "better architecture".
The important (Andrei somehow thinks it is not) requirement is
there must not be circular dependency issues for the users of the
"reflect" module.
