On Thursday, 29 November 2012 at 16:51:29 UTC, Max Samukha wrote:
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".
For me too much use of meta capabilities is not a better
architecture,
as quite often it leads to write only code.
If you are alreading writing code on the client side for
initialization, like your mixin definition, the client already
needs to make the reflect module of its existence, so why not
call an initialization function that avoids the static
constructors issues altogether?
--
Paulo
