At 02:03 PM 10/17/00 -0400, Ken Fox wrote:
>Nathan Wiger wrote:
> > Making STDERR into $STDERR is all hinged on fast vtable stuff in core ...
>
>Absolutely false. $STDERR does not depend on vtables in any conceivable way.
How it looks is ultimately unimportant. One way or another it'll refer to
Nathan Wiger wrote:
> Your point is assuming that STDERR retains its weirdness, and does not
> become a simple scalar object ...
sub STDERR () { $STDERR }
or am I missing something?
> Making STDERR into $STDERR is all hinged on fast vtable stuff in core ...
Absolutely false. $STDERR does not d
On Thu, 28 Sep 2000 10:16:43 +0100, Tom Christiansen wrote:
>Try thinking of it this way: it's only a bareword if
>it would make use strict whinge at you.
So every bareword would be recognized as a sub. That, is nice. For
starters, Perl parsers can more easily recognize a sub name, without a
ne
Tom Christiansen wrote:
>
> >So what's left?
> >
> >print STDERR "Foo";
> >
> >We have a proposal to turn STDERR into $STDERR, and it looks likely it'll go
> >through.
>
> It is? I certainly hope not. It makes as much sense to
> do that as to force a dollar sign on subroutines.
Your point
>So what's left?
>
>print STDERR "Foo";
>
>We have a proposal to turn STDERR into $STDERR, and it looks likely it'll go
>through.
It is? I certainly hope not. It makes as much sense to
do that as to force a dollar sign on subroutines.
sub $foo { ... }
or
sub 'foo' { ... }
Heck,
Try thinking of it this way: it's only a bareword if
it would make use strict whinge at you. Thus, the
constructs you cited are all non-uses of barewords,
such as in use Foo or require Foo or Foo => 1, or
even $x{Foo}. And I have proposed (nonRFC) that
Foo->bar() also be not a bareword. Yes, I
On 24 Sep 2000, Perl6 RFC Librarian wrote:
> Eliminate unquoted barewords from Perl entirely
Ugh, don't force me to select a One True Way, PLEASE. I don't think there
is really any unresolvable ambiguities the way it is in Perl5. Lets not
sacrifice the ability to do it the right way, just to pre
I personally have never had problems with these issues and would just as
soon that this RFC didn't do through. However, I don't feel particularly
strongly about most of it. Specifically:
As to autoquoting the lefthand side of -> (thereby making it a class
name), I don't particularly care.
The
On Mon, 25 Sep 2000, Michael Fowler wrote:
> This RFC makes no mention of what happens to the following constructs:
>
> %foo = (bar => "baz");
This actually isn't a bareword (as I understand it), since the =>
operator quotes its
LHS.
On Mon, Sep 25, 2000 at 05:49:21PM -0700, Nathan Wiger wrote:
> Michael Fowler wrote:
> > Honestly, if you're using both a stat class and a stat function in your
> > code it's up to you to keep it straight
>
> Exactly my point. So why is this
>
>stat->mode
>
> Any different? It's not.
Yes,
Michael Fowler wrote:
>
> Then say stat()->{'mode'} and stat::->mode, if it makes you feel better. Or
> better yet, always say stat()->anything when you mean the function call.
Either way is fine by me, but making Perl do one one place and the other
the other place makes no sense.
> Honestly,
On Mon, Sep 25, 2000 at 04:50:32PM -0700, Nathan Wiger wrote:
> Is just as much of a pain because of action-at-a-distance. Solving this
> problem with highly-specific solutions gains us nothing but more
> syntactic inconsistencies and ambiguities, like these:
>
>stat->{'mode'}
>stat->mode
> This is not a theoretical concern. If someone, at some point, defines sub
> CGI {} your constructor suddenly fails. If you're using something along the
> lines of Animal::Bear->new(), and the author of Animal.pm defines a Bear()
> method, your constructor suddenly fails. This is action at a d
On Mon, Sep 25, 2000 at 03:50:20PM -0700, Nathan Wiger wrote:
> So I assume you're suggesting that this:
>
> stat->{'mode'}
>
> be a call to stat(), which returns a hashref, but this:
>
> stat->mode
>
> would be a call to the method mode() in the class 'stat'
>
> That's not how I read
Michael Fowler wrote:
>
> You're beginning to blur your own fine line here. import is a class method
> call using indirect object syntax.
And, actually, per Schwern's RFC 253, require() would be too. Sometimes.
> stat->{'mode'}
>
> No ambiguity here.
So I assume you're suggesting that th
On Mon, Sep 25, 2000 at 02:17:38PM -0700, Nathan Wiger wrote:
>import Foo;
You're beginning to blur your own fine line here. import is a class method
call using indirect object syntax.
> But notice the disconnect here:
>
>package Foo;
>use base 'Bar';
>
> Seems almost that:
>
>
Michael Fowler wrote:
>
> This RFC makes no mention of what happens to the following constructs:
>
> use Foo;
> require Foo;
I don't mind a very few special cases. I would imagine that these might
have to remain special:
use Foo;
require Foo;
import Foo;
package Foo;
But n
On Sun, Sep 24, 2000 at 08:52:23PM -, Perl6 RFC Librarian wrote:
> The solution is simple: All barewords must die.
This RFC makes no mention of what happens to the following constructs:
use Foo;
require Foo;
%foo = (bar => "baz");
These are legitimate, non-ambiguous uses of bar
18 matches
Mail list logo
