On Thu, Sep 14, 2000 at 12:01:03AM -0700, Glenn Linderman wrote:
> > Once extracted, a module can deal with it
> > just as easily, and with much more flexibility, than a core patch to
> > perl can.
>
> Who cleans up all the junk files later?
Nobody does, they're not junk. They go into the t/ di
On Wed, 13 Sep 2000 22:49:14 -0700, Glenn Linderman wrote:
>So who needs a special format type? Just need a string. It becomes a
>format when you use it as such... So just
>
> my $frm = <<'.'
>@<: @
>$name, $ssn
>.
I, for one, can see two problems with this. And I'm not
Glenn Linderman wrote:
>
> I have a number of scripts that use this sort of facility, using push/shift
> to populate/read the array "file". These could be made simpler and more
> general by wrapping the array as a file.
>
> Perhaps the open "handler" stuff could be used to implement this?
> Eff
Nathan Wiger wrote:
> I think this is a definite possibility:
>
>$FH = open scalar $myvar;
>print $FH "stuff";
>
> Then the scalar handler would just have to provide the necessary print()
> et al methods to do scalar manipulation. Theoretically this can be done
> modularly, without havi
Eryq wrote:
>
> I'm weary of proposals like "lets add/extend named operator X".
> Perl needs *fewer* special cases, not *more*. I want the
> following pairs to ALWAYS be identical, and ALWAYS mean
> method invocation:
>
> open THING ARG,...,ARG
> THING->open(ARG,...,ARG)
>
>
Michael,
Thanks for the explanation. So you see, I'm one of those people that go around
looking for redundancies to eliminate. So when I hear that you want to extract
a .t file from perl source (as specified by the RFC 183), it makes me wonder
1) why extract it if it could potentially be used
Bart Lateur wrote:
> On Wed, 13 Sep 2000 22:49:14 -0700, Glenn Linderman wrote:
>
> >So who needs a special format type? Just need a string. It becomes a
> >format when you use it as such... So just
> >
> > my $frm = <<'.'
> >@<: @
> >$name, $ssn
> >.
>
> I, for one, can
This and other RFCs are available on the web at
http://dev.perl.org/rfc/
=head1 TITLE
STDIN, STDOUT, STDERR, ARGV, and DATA should become scalars
=head1 VERSION
Maintainer: Nathan Wiger <[EMAIL PROTECTED]>
Date: 04 Aug 2000
Last-Modified: 14 Sep 2000
Mailing List: [EMAIL PROTECTED]
arrays-of-scalars
Reply-To: [EMAIL PROTECTED]
This and other RFCs are available on the web at
http://dev.perl.org/rfc/
=head1 TITLE
Standard support for opening i/o handles on scalars and
arrays-of-scalars
=head1 VERSION
Maintainer: Eryq (Erik Dorfman) <[EMAIL PROTECTED]>
Date: 23 Aug 2
On Thu, Sep 14, 2000 at 12:15:28PM -0700, Glenn Linderman wrote:
> 1) why extract it if it could potentially be used in place
> 2) if it cannot be used in place, then why bundle it
>
> So I guess RFC 183 leaves me not understanding its goals. If there
> is a benefit to the bundling, then RFC 183
Glenn Linderman wrote:
>
> 1) why extract it if it could potentially be used in place
> 2) if it cannot be used in place, then why bundle it
I tend to agree. If they're stored as podified sections, and
get extracted to files, then pod has merely been (mis-)used as
some kind of shar.
If the t
John Porter wrote:
>
> Glenn Linderman wrote:
> >
> > 1) why extract it if it could potentially be used in place
> > 2) if it cannot be used in place, then why bundle it
>
> I tend to agree. If they're stored as podified sections, and
> get extracted to files, then pod has merely been (mis-)use
> Imagine a special "inline_tests.t" which goes through every
> .pm in the distribution's "lib" directory, and runs every
> in-line test it finds directly (WITHOUT extracting it to a .t).
> All we'd need is one; it would be general-purpose, and you
> could just download it from CPAN and stick it
> =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
"David L. Nicol" wrote:
>
> I don't know how large a point of view I represent, but I do not agree that
> all data should be decorated like scalars.
Well, I think you might be overlooking a couple of important things
about filehandles. First, having them NOT be scalars caused many
problems:
John Porter wrote:
> > For more flexibility, the test could look at an inline_tests.t.list
> > file in the cwd to determine *which* .pm's should be tested.
>
> This could be done now, without further ado.
>
> ##
> # testing code here...
> ...
> ##
>
> Podulation
"David L. Nicol" wrote:
> File handles work perfectly well
> right now as undecorated terms with well defined characteristics
Perfectly well?
* Have to use ugly globref syntax to pass them around reliably.
* Not first-class objects, so you can't subclass them.
* Special
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
On Thu, 14 Sep 2000 12:41:04 -0700, Glenn Linderman wrote:
>> 1) With a string, there can be no compile-time check on the variables.
>> If one isn't found, you can, at best, get a runtime error.
>
>What compile time checks are you expecting on the variables? For example:
Well, for one: "use st
"David L. Nicol" wrote:
> Nathan Wiger wrote:
> >3. There's no way to have them interpolated in strings into
> > something potentially useful.
>
> The string value of a file handle. Hmm. Is it's internal file
> descriptor number?
Umm... that's the numeric value of a file handle, ri
"David L. Nicol" wrote:
> >
> >1. You must use globs to pass them in and out of functions
>
> This could be resolved by allowing undecorated types to be passed
This is already allowed. It's called "passing in a bareword".
And barewords are just strings. Are you proposing
that "a barewor
21 matches
Mail list logo
