Fixing cyclic import static construction problems

[Paulo Pinto]

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