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])
