On Wednesday, 26 February 2014 at 14:54:05 UTC, Ali Çehreli wrote:
On 02/26/2014 03:24 AM, bearophile wrote:
> Ali Çehreli:
>
>> Improve at will! :p
>
> I will mostly just uniform its formatting to all the other
Rosettacode
> entries, shorten the lines to 72 chars, etc.
>
>
>> synchronized {
>> // Switch to the next printer
>> printers = printers[1..$];
>> }
>
> This doesn't work:
>
> printers.popFront();
I've noticed that too. ;) And I am not sure why the slicing
syntax works because the 'printers' member is still shared then.
It fails to deduce argument types due to popFront() taking its
argument by ref.
That's actually good it caught that, because I don't think that
slicing should be allowed either.
> It it a good idea to define Printer.print like this to remove
that cast?
>
> void print(string line) shared
I had that at one point but then I could not convince myself
that Printer.print should be a shared member function. How do
we know at design time that every Printer would be shared? I
thought that Printer should be as simple as possible and that
shared should be handled by a higher-level code. Then the code
became ugly like that. :)
Indeed it shouldn't really be shared in this case, since it's
used exclusively in the terms of lock-based synchronization.
Ideally, it could be made entirely private to RendezvoudPrinter.
But the transitivity of "shared" keyword still forces us to apply
casts.
It has little to do with experience. The whole 'shared' concept
being incomplete in the language is a shame. Hopefully things
will get better in the near future.
As for slicing syntax for shared arrays, personally I think it
should be disallowed, just like operators for shared scalars. But
that would mean that calling front() would be illegal too, thus
forcing the cast on the whole array when it's safe to do so...
Oh, there is still much to discuss on this matter.
