synchronized (this[.classinfo]) in druntime and phobos

[Dmitry Olshansky]

On 30.05.2012 3:02, Andrei Alexandrescu wrote:
> On 5/29/12 3:06 PM, Dmitry Olshansky wrote:
>> Again strictly speaking I'm of an opinion that having mutex together
>> with object guarded by it is at least better then 2 separate entities
>> bound together by virtue of code comments :)
>
> Absolutely. I hope you agree that this essentially means you're
> advocating a Java-style approach in which the mutex is implicitly
> present...
>
>> In any case if mutex is desired, object could have had some other base
>> type say SyncObject.
>
> ... albeit not in all objects, only a subhierarchy thereof. I posted the
> same thing. Nice :o).

Great.

>
>> Or use "synchronized class" to that end, what it does now by the way
>> - locks on each method?
>
> TDPL's design of synchronized still hasn't been implemented. The design
> indeed prescribes that all public access to the resource is synchronized.
>

So sad, I recall when I was reading about it it made a lot of sense.

>> More about the actual point is that I've come to believe that there is
>> satisfactory way to implement whatever scheme of polymorphism* we want
>> within the language on top of structs without 'class' and 'interface'
>> keywords, special "flawed" pointer type (i.e. tail-const anyone?), and
>> last but not least without new/delete/finalizes (new/delete are still
>> overridable, hint-hint) madness.
>>
>> Ideally I think it should be possible to lower the whole
>> interface/object/class infrastructure to code that uses structs with
>> direct function pointer tables, etc. Multiple alias this is the key,
>> sadly so, otherwise subtyping to multiple interfaces seem not likely.
>> Then some future compiler may even chose to not provide OOP as built-in
>> but lower to this manual implementation on top of struct(!).
>
> Well all of these are nice thoughts but at some point we must
> acknowledge we're operating within the confines of an already-defined
> language.
>
>> *I like the one in Smalltalk or Obj-C. Also I think exposing type-tag as
>> ordinal (index inside one global master v-table) instead of pointless
>> _hidden_ v-table pointer could be interesting in certain designs.
>> Another idea is to try tackling multi-methods via some form of
>> compressed 2-stage v-table. (my recent work on generalized tries in D
>> sparked some ideas)
>
> Any post that starts with taking an issue against the waste of one word
> and ends advocating Smalltalk and Obj-C is... ho-hum.
>

Well going from practical matters to personal dreams is remarkably easy 
at 2 AM :)


-- 
Dmitry Olshansky