This is an omnibus response to those who've commented on RFC17 (v1).
The version I'm about to submit to the librarian is now available
as html at <https://www.nnaf.net/~scs/Perl6/RFC17.html>.
General note -- please look over the abstract. Some folks have made
really good sugge
At 10:55 PM 8/6/00 -0400, Ken Fox wrote:
>Dan Sugalski wrote:
> > But, if we toss refcounts, and split GC cleanup and
> > end of scope actions anyway, we need to have a mechanism to hoist things
> > out of the current scope.
>
>Why say hoist when we can say return? I can think of several ways of
>
Dan Sugalski wrote:
> But, if we toss refcounts, and split GC cleanup and
> end of scope actions anyway, we need to have a mechanism to hoist things
> out of the current scope.
Why say hoist when we can say return? I can think of several ways of
returning values that don't require the caller to a
At 03:30 PM 8/6/00 -0400, Ken Fox wrote:
>Dan Sugalski wrote:
> > At 02:09 AM 8/6/00 -0400, Chaim Frenkel wrote:
> > > uplevel 0, $Perl:Warnings=1;# Hit everyone
> > > uplevel -1, $Perl:Warnings=0; # Hit my wrapper
> > Yeah, I can see that. We're going to need a mechanism to
Dan Sugalski wrote:
> At 02:09 AM 8/6/00 -0400, Chaim Frenkel wrote:
> > uplevel 0, $Perl:Warnings=1;# Hit everyone
> > uplevel -1, $Perl:Warnings=0; # Hit my wrapper
> Yeah, I can see that. We're going to need a mechanism to hoist things to
> outer scope levels internally (f
At 02:09 AM 8/6/00 -0400, Chaim Frenkel wrote:
>Then a mechanism for uplevel manipulation of variables should be used.
>
> uplevel 0, $Perl:Warnings=1;# Hit everyone
> uplevel -1, $Perl:Warnings=0; # Hit my wrapper
>
>(I think something better was proposed, but I don't recall
On Sun, 6 Aug 2000, Dan Sugalski wrote:
> At 01:21 AM 8/6/00 -0400, Chaim Frenkel wrote:
> >I think there are two problems. One is the naming convention, the
> >second, the global effects.
> >
> >Why not split them. The names could be improved.
> >
> >And the global nature (of the name) abolished
Then a mechanism for uplevel manipulation of variables should be used.
uplevel 0, $Perl:Warnings=1;# Hit everyone
uplevel -1, $Perl:Warnings=0; # Hit my wrapper
(I think something better was proposed, but I don't recall what it was.)
> "DS" == Dan Sugalski <[EMAIL PR
At 01:21 AM 8/6/00 -0400, Chaim Frenkel wrote:
>I think there are two problems. One is the naming convention, the
>second, the global effects.
>
>Why not split them. The names could be improved.
>
>And the global nature (of the name) abolished.
I'm not entirely sure that tossing the global nature
e-shot manifesto.
MD> I agree with the goal of RFC17:
MD> Organization and Rationalization of Perl State Variables
MD> but I think the implementation ideas are making a terrible mistake.
MD> Specifically:
>> =head1 IMPLEMENTATION
>> =head3 Well-Named Global Hashe
> Summary of manifesto: Global variables must be expunged.
>
> Replacing the old rotten global variables with new rotten global
> variables is not enough of an improvement.
Hurrah! http://www.iki.fi/jhi/
# There is this special biologist word we use for 'stable'.
# It is 'dead'
I don't want to join the discussion in general, and I'm not on the
language list. So this is a one-shot manifesto.
I agree with the goal of RFC17:
Organization and Rationalization of Perl State Variables
but I think the implementation ideas are making a terrible mistake.
Sp
At 01:10 PM 8/5/00 -0400, Mark-Jason Dominus wrote:
>Summary of manifesto: Global variables must be expunged.
>
>Replacing the old rotten global variables with new rotten global
>variables is not enough of an improvement.
Works for me. Globals should be for things that truly are global. ($^O, for
13 matches
Mail list logo
