Eryq wrote:
> And all that I am saying is that this syntactic complication,
> this special case where "the filehandle name *is* the object",
> should be gotten rid of. Unlike some other special Perl syntactic
> constructs (e.g., regular expressions, "here-is" documents),
> the current filehandl
Nathan Wiger wrote:
(in response to an assertion of preference for undecorated filehandles)
> Well, I think you might be overlooking a couple of important things
> about filehandles. First, having them NOT be scalars caused many
> problems:
>
>1. You must use globs to pass them in and out o
> =head1 ABSTRACT
>
> Consensus has been reached that filehandles (currently
> barewords) will be revamped to become true $scalars, to
> make them consistent with other Perl variables.
>
> C, C, C, and C should follow suit and be
> renamed C<$STDIN>, C<$STDOUT>, C<$STDERR>, and C<$DATA>, becomi
sub p{
print "Debug: @_\n";
@_;
};
Solved my problem :)
Nathan Wiger wrote:
>
> I think [a print() that returns the value of what you
> printed ] is an excellent idea independent of others and should
> probably be RFC'ed separately. Since it d
I like very much a print() that returns the value of what you
printed rather than success. I am always needing to define
littly intermediate temporaries so I can insert debugging code
inside huge, tortuous expressions.
I don't know if C(>"print me"<) is it though.
Did you take a look at RFC 6
Chaim Frenkel wrote:
>
> Sitting on a unix box, and getting to C: on a windows box?
That implies a whole pile of implementation details. Are you
suggesting a Perl Orifice to run on all participating windows
boxes?
I'd
like to call "open" with the arguments I can currently pass
to "hose" from
> >
> > I think this should be discussed a good amount. I think URIs are cool,
> > but too much trouble for simple stuff. I don't want to have to write
> > "file:///etc/motd" everytime I want to address a file. Too cumbersome.
Why not extend C to be able to take other things besides
strings of
