At 13:11 28/08/00 -0400, Steve Simmons wrote:
>To tell the truth, this third item should probably should become
>a separate RFC, and if you'd like to simply say one is forthcoming,
>that'd be fine by me.
What I really want to do is write a summary, get some consensus and redraft
the RFC. I'll do
On Tue, Aug 29, 2000 at 09:15:35AM +0100, John McNamara wrote:
> At 13:11 28/08/00 -0400, Steve Simmons wrote:
> >To tell the truth, this third item should probably should become
> >a separate RFC, and if you'd like to simply say one is forthcoming,
> >that'd be fine by me.
>
> What I really want
At 08:19 29/08/00 -0500, Jonathan Scott Duff wrote:
> > As far as I can see the current consensus is as follows:
> > 1. Implicit variable: nice but not really worth the trouble.
> > 2. Explicit variable between foreach and the array: might conflict
> > with other proposals.
> >
Then you are back to locking everything in sight.
Consider the simple solution.
my $group_a : shared;
my $group_b : shared;
sub foo { lock $group_a; }
sub fo1 { lock $group_a; }
sub fo2 { lock $group_a; }
sub bar { lock $group_b; }
s
--On 29.08.2000 12:15 Uhr -0400 Chaim Frenkel wrote:
>
> But the grouping of related locks can most easily be done by the user
> and probably a lot more efficiently then the pessimistic locking perl
> would need to perform.
I completely agree. The only thing I'd have to add is that the lock co
On Tue, Aug 29, 2000 at 09:15:35AM +0100, John McNamara wrote:
> At 13:11 28/08/00 -0400, Steve Simmons wrote:
> >To tell the truth, this third item should probably should become
> >a separate RFC, and if you'd like to simply say one is forthcoming,
> >that'd be fine by me.
>
> What I really want
I'd like to see a last-container-key attribute included as
a possibilty; and that attribute called ":n" to match the
argument of integer functions in introductory algebra. This
approach gives us
for $a @some_list {
print "$a is located at position ${a:n}\n";
};
