On Wed, 23 Aug 2000, Benjamin Stuhl wrote:
> While I approve of this RFC, there are a few places where
> it proposes (unnecessary) new primatives. Most of these
> already  exist or have planned names (in perl5).
> 
> > The Thread module should add a C<global> keyword or
> > function that explicitly
> > accesses a variable in the program-global stash.
> 
> in perl5, this would (or should) be written as
> 
> our $foo : shared;

Noted.  (Although an issue similar to C<local> arises, where
a thread-global may hide a program-global, as demonstrated
below.  I realize that Perl is heading towards attributes, but I felt
that "global" (or its syntactical equivalent) was more in line with
C<my>, C<local>, and C<our> than, say, C<:read_only>.  Regardless, I'm
not really making an attempt (well, not really) to define the language
of threads, but need a temporary language to demonstrate the
implementation, which is, after all, the subject of my RFC.  :-)

Either way, I'll make a note one way or another in v4.  In the
meantime, I don't particularly care what the semantics are.

 > 
> > 
> >     C<global $main::foo = $foo;  # Let another thread
> > know what my $foo is.>
> >     C<global $main::foo = \$foo; # Share my local foo. 
> > Dangerous!>
> >     C<$foo = global $main::foo;  # Localize this instance
> > of $main::foo.>
> > 
> > Rationale: There needs to be some way to distinguish
> > between the program-
> > global stash and the thread-global stashes.  It should
> > undeniably mark the
> > data that is being shared.
> > 
> perl5-speak:
> 
> require Foo;

Well, duh on me.  Thanks.  Hadn't even considered that.

-- 
Bryan C. Warnock
([EMAIL PROTECTED])

Reply via email to