23-May-2013 01:23, Idan Arye пишет:
On Tuesday, 21 May 2013 at 17:40:02 UTC, Idan Arye wrote:
On Tuesday, 21 May 2013 at 14:58:16 UTC, Idan Arye wrote:
At any rate, I am forced to admit I made a mistake about
`hasIntance()` not needing synchronization. I neglected the
possibility that the constructor(or anything else used for
initialization) can throw!
The compiler might decide that it's better to write the global
reference first, and if the initializer throws just set it back to
null. If that is the case, `hasInstance()` could see that the global
reference is not null and return true, and then the initializer will
throw and the initializing thread will set the global reference to
null again.
So yea, I'm gonna have to synchronize it too...
OK, it is done.
Next step - write the introduction. And then add the shared version of
the singleton.
OK, I've written and pushed the documentation. I'll try to find
somewhere to host the generated HTML.
I've found github pages to be just fine.
I've also added `SharedSingleton` and renamed `LowLockSingleton` to
`__GSharedSingleton` for consistency. I *did not* rename
`ThreadLocalSingleton` to `StaticSingleton` - this will be too
confusing("aren't all singletons static?").
Turns out that doing shared classes (and singletons conversely) has one
big of disadvantage: you can't have TLS reference to shared class
instance (ditto with mutable reference to const object).
It's a well-known problem of the way OOP is done in D - object and
reference to it are tightly coupled and qualifier applies transitively
to both.
There was a pull that allowed to separate qualifier of instance from
reference (handle) looking like this:
ref const(Object) refToConst;
ref Object mutableTlsRef;
Object mutableTlsRef; //same as above
ref const Object constRefToConst;
const Object constRefToConst; //ditto
The fact that we don't have it is part of the reason I don't like doing
OOP in D at all.
--
Dmitry Olshansky
