On Thu, Jun 4, 2009 at 9:57 AM, TSa <thomas.sandl...@vts-systems.de> wrote: > HaloO, > > Daniel Ruoso wrote: >> >> So the questions are: >> >> * Are there any imperative barriers in Perl 6? > > I would think that at least every method call is a barrier. > An object's lifetime is a sequence of states and methods are either > returning information about the state or calculate a new state. The > latter cannot be concurrent. Furthermore it is usually a bad idea > to have an object in several concurrent computations such that > streams of mutating method calls interleave. So objects destined > for parallel computing need some explicit locking mechanism.
Perhaps it isn't the method call that's the barrier, but rather the mutating function. If you do nothing but call a series of non-mutating methods, I don't see how it matters how quickly any given one of them gets evaluated, or even in what order they're evaluated, as long as the information is ready by the time you need it. But as soon as you call a mutating method, you'd better get all of those pending non-mutating calls taken care of before you proceed with the mutating call. Rule of thumb: if you want to be lazy, look but don't touch. -- Jonathan "Dataweaver" Lang
