I want to add a Phobos module with template mixins for common idioms.

[Idan Arye]

On Tuesday, 21 May 2013 at 06:44:02 UTC, Dmitry Olshansky wrote:
> A-ha. That's it and it's totally wrong. Exposing as much 
> interface as possible is a disaster. Libraries (esp standard) 
> take great deal of deliberation in picking what to expose. 
> Exposing less is a common theme in interfaces. "Doing more" is 
> a common theme in wrappers, helpers and has a proverbial 
> "kitchen sink" effect.
>
>> ...
>
> Message passing, queues, condition variables. Singleton pattern 
> assumes you have an object with unknown initialization order 
> and who ever touches it first gets to create it.
>
>> ...
>
> And your are falling into a trap I decidedly put in my example 
> - this is a no use case for singletons. Want to wait on smth to 
> happen? - use *separate* condition var, event pump etc. Want to 
> check on some external state? - same answer.

The user of a library usually knows what they want to do with the 
library much more than the designer of the library. I see no 
reason to force the user to hack around trying to get information 
that the library could easily provide them without breaking 
anything or exposing the implementation.

> Though you might provide separate class for waitable singleton 
> that incorporates
> condition variable. Could be useful sometimes(?) in case there 
> is no other logic
> to define order of initialization.
>
> BTW Why not just make a template Singleton!T instead of mixin?

Something like that is possible, but I believe it's place is in 
`std.idioms` but in `std.parallelism`, since it is very similar 
to `Task` - a structure that represents a calculation(in this 
case - the initialization) that will be performed sooner or 
later, and provides synchronization on the invocation, 
synchronized access to the result and information whether it 
happened already or not.

> It would make people do something about it - shared allows only 
> calling shared methods of a class and prohibits all basic 
> operations on the fields. Points of race become fairly obvious 
> - they need casts and lack of locks in the vicinity.
>
> Every time I see __gshared I think "lazy, old and broken" and 
> usually at least one of these is true.

D provides 3 types of global - `shared`, `__gshared` and 
`static`(which is only global in the same thread). Since a 
singleton is a lazy global, I'm gonna provide a implementation an 
implementation for each type of global D has and let the users 
choose, like they do with regular globals.

Though, it might be a good idea to rename it to 
`__GSharedSingleton`. On one hand, the double underline prefix 
represents an implementation detail. On the other hand, using 
just `GSharedSingleton` will be too similar to `SharedSingleton` 
and might confuse even more.

>> Is there a point in using the TLS Low Lock method for shared
>> singletons?
>
> Good question. Yes, it is as it will allow you to have lazy 
> initialization from any thread on any multicores w/o always 
> taking a lock. If you can't figure out how to make order of 
> initialization deterministic (or who creates what and when) 
> then these lazy-init singletons are good idea.

Is it possible to save a thread local copy of the lock though? I 
can't use `static`, because it'll have to be `static shared` to 
keep the `shared`ness of the instance, which will not be thread 
local.

Ofcourse, using a boolean is always possible, it'll just be 
slower.

> I personally despise singletons and the code patterns they 
> introduce. IMHO lazy initialization (not to mistake with lazy 
> loading/caching) is so rarely *required* that you may as well 
> avoid it, and in D we have static this/shared static this.

Even if you think singletons are bad, you have to agree that some 
ways to implement them are far worse than others. My library 
implementation would be better than most project local 
implementations because I have put in it much more time and 
effort than the what's dedicated to such a common pattern in a 
large project, and because it is being peer reviewed here.