On Saturday 04 September 2010 12:06:23 Era Scarecrow wrote:
> > I'm currently porting a D1 code base to D2 which has the
> > following class
> > hierarchy:
> > 
> > interface Map
> > {
> >       void clear ();
> > }
> > 
> > class Hashtable : Map
> > {
> >      synchronized void clear () {};
> > }
> > 
> > class HashMap : Map
> > {
> >      void clear () {};
> > }
> > 
> > When I compiler the code I get an error about the "clear"
> > method in
> > Hashtable not being covariant with the "clear" method in
> > Map. Any
> > suggestions how I could solve this, preferable working in
> > D1 as well?
> 
>   I remember reading about this; The signatures have to match EXACTLY for
> it to work. The interface is a declaration of a contract, of what it
> expects. If a part of the contract is broken, an error tells you where to
> fix it.
> 
>  Even if technically it would be compatible, the compiler and type checking
> won't allow it. So either synchronize your interface as well, or drop it
> from the implementation.
> 
>  A third option, is to match the declaration, and have a private function
> that is synchronized that is called from clear. At least, i believe this
> is right.
> 
>  Era

Also, according to TDPL, either your _entire class_ is synchronized, or none of it is. So, synchronized really belongs on the class, not the function, and I wouldn't expect it to compile if only a portion of your functions are synchronized (though I don't know how close the current dmd is to TPDL with regards to synchronized).

- Jonathan M Davis

On 2010-09-05 02:18, Jonathan M Davis wrote:
> On Saturday 04 September 2010 12:06:23 Era Scarecrow wrote:
>>> I'm currently porting a D1 code base to D2 which has the
>>> following class
>>> hierarchy:
>>>
>>> interface Map
>>> {
>>>        void clear ();
>>> }
>>>
>>> class Hashtable : Map
>>> {
>>>       synchronized void clear () {};
>>> }
>>>
>>> class HashMap : Map
>>> {
>>>       void clear () {};
>>> }
>>>
>>> When I compiler the code I get an error about the "clear"
>>> method in
>>> Hashtable not being covariant with the "clear" method in
>>> Map. Any
>>> suggestions how I could solve this, preferable working in
>>> D1 as well?
>>
>>    I remember reading about this; The signatures have to match EXACTLY for
>> it to work. The interface is a declaration of a contract, of what it
>> expects. If a part of the contract is broken, an error tells you where to
>> fix it.
>>
>>   Even if technically it would be compatible, the compiler and type checking
>> won't allow it. So either synchronize your interface as well, or drop it
>> from the implementation.
>>
>>   A third option, is to match the declaration, and have a private function
>> that is synchronized that is called from clear. At least, i believe this
>> is right.
>>
>>   Era
>
> Also, according to TDPL, either your _entire class_ is synchronized, or none of
> it is. So, synchronized really belongs on the class, not the function, and I
> wouldn't expect it to compile if only a portion of your functions are
> synchronized (though I don't know how close the current dmd is to TPDL with
> regards to synchronized).
>
> - Jonathan M Davis

Ok, that is good to know.


-- 
/Jacob Carlborg

Jonathan M Davis:
> Also, according to TDPL, either your _entire class_ is synchronized, or none of it is. So, synchronized really belongs on the class, not the function, and I wouldn't expect it to compile if only a portion of your functions are synchronized (though I don't know how close the current dmd is to TPDL with regards to synchronized).

If not already present, I suggest to add this to Bugzilla.

Bye,
bearophile

> Jonathan M Davis:
> > Also, according to TDPL, either your _entire class_ is synchronized, or none of it is. So, synchronized really belongs on the class, not the function, and I wouldn't expect it to compile if only a portion of your functions are synchronized (though I don't know how close the current dmd is to TPDL with regards to synchronized).

  *smacks forehead* Of course. i forgot that detail. I don't work with
multi-threads or synchronized much yet.