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...

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.

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 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?").

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

On Friday, May 24, 2013 17:42:59 Dmitry Olshansky wrote:
> 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.

Lacking a proper language solution, we could create something similar to Rebindable but for shared.

- Jonathan M Davis

24-May-2013 22:13, Jonathan M Davis пишет:
> On Friday, May 24, 2013 17:42:59 Dmitry Olshansky wrote:
>> 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.
>
> Lacking a proper language solution, we could create something similar to
> Rebindable but for shared.
>

Then in my vision built-in OOP has failed if we need at least 2 wrapper types implemented as structs on top of built-in refs. Then recall (to be implemented) RefCounted!ClassType and we have yet another library land solution to make OOP types with ref-counting.

On occasion I've been enumerating the amount of special casing class references require and truth be told I fail to see the benefit of having them as built-in outweigh the cost. With multiple alias this I could have implemented the OOP in library just fine as Ref!T struct. Then
Ref!(const(T)) is ConstRef!T
Ref!(shared(T)) is SharedRef!T

And now UDAs can serve for override/virtual, inheritance etc.
> - Jonathan M Davis


-- 
Dmitry Olshansky

On Friday, 24 May 2013 at 13:43:02 UTC, Dmitry Olshansky wrote:
> I've found github pages to be just fine.

Then GitHub pages it is - http://someboddy.github.io/phobos/ddocs/for-idioms/idioms.html

I've also added this link to the pull request and to the review queue.

> 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.

Like Jonathan M Davis said, it could easily be added as a class. This is another example to D's flexibility - the ability to implement such things without changing the compiler. But still - a thing like this should be part of the language itself.

Anyways, since the implementation is so easy and short I could tweet it, I see no reason why not to make a pull request. It's gonna be in `std.typecons`, not in `std.idioms`, so I'll wait with using it in `std.idioms` until it gets pulled - or gets rejected in favor of a better(dmd) solution.

And here is the Phobos solution:

http://d.puremagic.com/issues/show_bug.cgi?id=10165
https://github.com/D-Programming-Language/phobos/pull/1302

On Saturday, May 25, 2013 00:08:37 Dmitry Olshansky wrote:
> 24-May-2013 22:13, Jonathan M Davis пишет:
> > Lacking a proper language solution, we could create something similar to Rebindable but for shared.
> 
> Then in my vision built-in OOP has failed if we need at least 2 wrapper types implemented as structs on top of built-in refs. Then recall (to be implemented) RefCounted!ClassType and we have yet another library land solution to make OOP types with ref-counting.
> 
> On occasion I've been enumerating the amount of special casing class
> references require and truth be told I fail to see the benefit of having
> them as built-in outweigh the cost. With multiple alias this I could
> have implemented the OOP in library just fine as Ref!T struct. Then
> Ref!(const(T)) is ConstRef!T
> Ref!(shared(T)) is SharedRef!T
> 
> And now UDAs can serve for override/virtual, inheritance etc.

Overall, I think that OOP in D works fine, but we have some definite issues with const due to how Object is currently set up, and the fact that the type system can't distinguish between a reference to a class object and the class object itself is definitely annoying, and I have no idea why it works that way (though my guess would be that it's simply the side effect of making it so that they have to live on the heap). We would definitely be better off if we could fix that. I do think that the remaining issues with OOP in D are quite fixable though. It just takes time and effort, and doing stuff like removing unnecessary functions from Object are probably blocked by the AA mess. So, we definitely have problems, but they're not insurmountable.

On the other hand, with regards to this particular problem, as Walter inquires in the bug report for not being able to have local references to shared objects, I have no idea what the use case for such would even be.

- Jonathan M Davis