A little of coordination for Rosettacode
Stanislav Blinov
stanislav.blinov at gmail.com
Wed Feb 26 07:36:53 PST 2014
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.
More information about the Digitalmars-d-learn
mailing list