std.log version 2

[Jose Armando Garcia]

I filed a bug. I wasn't able to reproduce the problem I was having
with the class' shared static this ctr.

http://d.puremagic.com/issues/show_bug.cgi?id=6113

On Sun, Jun 5, 2011 at 8:38 PM, Jonathan M Davis <jmdavisProg at gmx.com> wrote:
> On 2011-06-05 10:24, Jose Armando Garcia wrote:
>> The problem is that std.log is using the UTC() (indirectly) in shared
>> static this() for the module. At that point the static ctr for UTC
>> didn't get to execute. I first changed std.datetime to instantiate UTC
>> in a shared static ctr for UTC but that still didn't work (I assume
>> that is a bug in dmd). So I had to move the instantiation to a share
>> static ctr for the module.
>>
>> In my branch the follow code doesn't assert. Note that I was selfish
>> and only fixed UTC but std.datetime has this problem in all the
>> singletons.
>>
>> import std.datetime;
>>
>> shared static this()
>> {
>>    assert(UTC() !is null); // this is with my fix.
>>    assert(LocalTime() is null); // I didn't fix LocalTime!
>> }
>>
>> Having said that what is D's idiom/recommended way of constructing
>> singletons? Maybe phobos should create shared/global singleton with
>> the following idiom:
>>
>> shared(T) singleton(T)() if(is(T == class))
>> {
>>    shared static T one;
>>    if(one is null) cas(&one, null, new shared(T));
>>
>>    return one;
>> }
>
> Phobos has no idiom or policies for dealing with singletons. In, fact I think
> that std.datetime is probably the only module that even has any at this point
> (most Phobos modules have functions primarily rather than types which may or
> may not be singletons).
>
> In this particular case, because the singletons are immutable, changing them
> to shared makes a lot of sense, but in the general case, it probably wouldn't
> (at which point it would be a singleton per thread rather than globally). So,
> I'll take a look at making the approriate changes in std.datetime for all of
> its singletons.
>
> But if you could, I'd really appreciate it if you could create a small test
> case (which has nothing to do with std.datetime), which shows the bug with
> regards to the shared module constructor, since that needs to be fixed. Having
> to move the variable into the module's scope like that is ugly and shouldn't
> be necessary at all. I guess that std.datetime will be stuck for the moment,
> but the bug does need to be properly reported and fixed.
>
> - Jonathan M Davis
>