Thus it was written in the epistle of Bart Lateur,
> On Fri, 4 Aug 2000 10:03:28 -0400, Ted Ashton wrote:
>
> >If we've decided that chomp isn't going to return the clippings, would it not
> >seem prudent to make
> > while (chomp())
> >
> >work like
> > while ()
>
> You mean, like, the -l com
On Sat, Aug 05, 2000 at 08:53:58PM +, Nick Ing-Simmons wrote:
> You loose one little thing - you have a new scalar (the handle)
>
> with
>
> open $fh,$filename
>
> one can re-use an existing thing to which someone else may have a reference.
> (Not that that is useful very often.)
Well per
Nathan Wiger <[EMAIL PROTECTED]> writes:
>> Um, what stops open returning undef on failure (and setting $!), so I could do
>>
>> $fh = open $filename or die "open $filename failed: $!\n";
>
>Exactly. You don't lose anything because open() will still return "true"
>(a handle) or "false" (
On Fri, 4 Aug 2000 10:03:28 -0400, Ted Ashton wrote:
>If we've decided that chomp isn't going to return the clippings, would it not
>seem prudent to make
> while (chomp())
>
>work like
> while ()
You mean, like, the -l command line switch? (see perlrun)
chomp() on input, append newlines on p
Tom Christiansen writes:
> perl526
Good grief, Tom! How many versions of Perl ahead of us are you?!
Nat
:-)
Thus it was written in the epistle of Tom Christiansen,
> >How often does the return value from chomp or chop get used? The confusion
> >would cleared up considerably, I think, if they didn't return a value.
>
> Seldom, I think--albeit sufficiently often that you might want the
> perl526 transla
Tom Christiansen <[EMAIL PROTECTED]> writes:
> >But that, precisely, was my point: Arrays *and* hashes. If there is more than
> >one plural whatzitz, then why can't there be more than one singular whatzitz?
> >(and don't say, "because plural *means* more than one" :-). If having a
> >filehandl
>How often does the return value from chomp or chop get used? The confusion
>would cleared up considerably, I think, if they didn't return a value.
Seldom, I think--albeit sufficiently often that you might want the
perl526 translator to have any such found be converted to some kind
of lchop/lcho
>> Some related issues:
>>
>> 1) Did Larry or did he not mention something about dealing with
>>indirect object more cleanly?
>Maybe clarify this just a little. I don't think I was present for this
>discussion.
That's just the indirect object slot ambuiguity annoyance. See the
OO c
Ted Ashton <[EMAIL PROTECTED]> writes:
> How often does the return value from chomp or chop get used?
# Remove possible trailing slash.
$file .= $possible_slash if ($possible_slash = chop($file)) ne "/";
Of course, TMTOWTDI.
-- Johan
Thus it was written in the epistle of Nathan Wiger,
> I don't know of an easy solution. I don't think we should touch chomp or
> chop. Maybe someone should write a module that offers alternate versions
> for those that want them?
How often does the return value from chomp or chop get used? The c
> I think I'd prefer that ->pid return 0 only to the child of a fork,
> but undef on a handle that were not the product of a fork, irrespective
> of direction.
Great analysis. I think this sounds like an excellent idea.
> Some related issues:
>
> 1) Did Larry or did he not mention somethin
> The suggestion was the open() return a filehandle object, so may
> I suggest
>
>$fh = open("| cat -v | sort | lpr") or die ;
>$pid = $fh->pid;
I like. I'll add it.
Version 2's gonna be *huge*...
-Nate
> I'd've written that more like
>
> $data_axed = chop($var);
> $charcount = chomp($var);
>
> Or something. People really do find those two functions confusing.
> Is this something we'd like to address by having versions that don't
> take LVALUES?
I don't know. It is true that this is s
Larry Wall wrote:
>
> Sorry, beat you to it, barely. Camel III, page 10:
>
> (If you look carefully at the % character, you can see the key
> and the value with a slash between them. It may help to squint.)
If I squint one way, I see an "H"; and if I squint another way, I see "a/a"!
If the file handle becomes an object, they'd be available via member functions
of the object for those that are curious, would they not? And if it is less
than an object, a function could be provided to obtain a pid from a handle.
Tom Christiansen wrote:
> >It seems that this issue is definitel
On Thu, Aug 03, 2000 at 07:11:00AM -0600, Tom Christiansen wrote:
> $fh = open("|-") || die "can't start pipeline: $!";
>
> if ($fh->pid) {
> print $fh "stuff\n";
> } else {
> $data = readline $fh;
> }
>
> I think I'd prefer that ->pid return 0 only to the child of
>The suggestion was the open() return a filehandle object, so may
>I suggest
> $fh = open("| cat -v | sort | lpr") or die ;
> $pid = $fh->pid;
Let's see how that plays out with pipe open:
if ($fh = open("| cat -v | sort | lpr")) {
print $fh "stuff\n";
} else {
di
On Thu, Aug 03, 2000 at 06:27:13AM -0600, Tom Christiansen wrote:
> >It seems that this issue is definitely worth a quick RFC - something
> >like "proposal to return filehandles from open/opendir rather than supply
> >as arguments".
>
> What about the pids that come back from begotten processes,
>Point taken, I did actually think of most of these. The difference is
>all of these return something still:
> $object = tie %hash, $class;
> $chopped = chop($var);
> $chomped = chomp($var);
> $ref = bless {}, $class;
I'd've written that more like
$data_axed = chop($var);
$
>It seems that this issue is definitely worth a quick RFC - something
>like "proposal to return filehandles from open/opendir rather than supply
>as arguments".
What about the pids that come back from begotten processes, as in
open(FILTER, "| cat -v | sort | lpr")
or
open(MESELF, "|-")
On Wed, 2 Aug 2000, Nathan Wiger wrote:
> Tom Christiansen wrote:
> >
> > >Not sure I agree with that. I think one point of confusion / perceived
> > >difference between filehandles, open(), and basically every other
> > >builtin is that all the others *return* what you want.
> >
> > tie and b
> Yes, but then each of those has to be explained specially. People
> *expect* assignment to "autovivify", as it were. But open() et al
> are essentially a 3rd syntax for constructors, and that's about one
> syntax too many, give or take a few.
I agree with this. I think of open() a lot more li
Tom Christiansen wrote:
>
> >Not sure I agree with that. I think one point of confusion / perceived
> >difference between filehandles, open(), and basically every other
> >builtin is that all the others *return* what you want.
>
> tie and bless and chop and chomp also all act upon their argumen
Tom Christiansen writes:
: >Not sure I agree with that. I think one point of confusion / perceived
: >difference between filehandles, open(), and basically every other
: >builtin is that all the others *return* what you want.
:
: Think of all the {file,dir}handle syscalls. They don't do that.
>Not sure I agree with that. I think one point of confusion / perceived
>difference between filehandles, open(), and basically every other
>builtin is that all the others *return* what you want.
tie and bless and chop and chomp also all act upon their argument(s).
Just to name a few. bless ha
>Not sure I agree with that. I think one point of confusion / perceived
>difference between filehandles, open(), and basically every other
>builtin is that all the others *return* what you want.
Think of all the {file,dir}handle syscalls. They don't do that.
They autoviv an object.
--tom
Tom Christiansen wrote:
>
> >Except that you can test for failure by checking to see if $fh is defined.
>
> Let your true be true and your false be false.
>
> open($fh, "<", $filename) || die;
>
> --tom
Not sure I agree with that. I think one point of confusion / perceived
difference betw
> Um, what stops open returning undef on failure (and setting $!), so I could do
>
> $fh = open $filename or die "open $filename failed: $!\n";
Exactly. You don't lose anything because open() will still return "true"
(a handle) or "false" (undef).
-Nate
> Thanks for the advice. Would "production" have been less likely to offend
>than "real-world"?
Perhaps. Or "conservative". Or "cautious". Or "paranoid". :-)
--tom
Thus it was written in the epistle of Tom Christiansen,
> >Doesn't print 'GLOB' for me, but that's because a lot of real-world systems
> ^^
> >haven't hit 5.6.0 (I'm guessing, not absolutely sure that's the cause),
>
> If you look at
On Wed, Aug 02, 2000 at 08:00:57PM -0600, Tom Christiansen wrote:
> >Doesn't print 'GLOB' for me, but that's because a lot of real-world systems
> ^^
> >haven't hit 5.6.0 (I'm guessing, not absolutely sure that's the cause),
> If you
>Doesn't print 'GLOB' for me, but that's because a lot of real-world systems
^^
>haven't hit 5.6.0 (I'm guessing, not absolutely sure that's the cause),
If you look at it, you'll notice that "real" is here being used as
something o
>Except that you can test for failure by checking to see if $fh is defined.
Let your true be true and your false be false.
open($fh, "<", $filename) || die;
--tom
At 10:36 AM 8/3/00 +0900, Simon Cozens wrote:
>On Wed, Aug 02, 2000 at 04:26:56PM -0700, Nathan Wiger wrote:
> > I tend to agree with Tom's argument here. open() is kind of funny
> > anyways. Why couldn't it work like this, similar to FileHandle:
> >
> >$fh = open $filename;
>
>Testing for fai
On Thu, 3 Aug 2000, Simon Cozens wrote:
> On Wed, Aug 02, 2000 at 04:26:56PM -0700, Nathan Wiger wrote:
> > I tend to agree with Tom's argument here. open() is kind of funny
> > anyways. Why couldn't it work like this, similar to FileHandle:
> >
> >$fh = open $filename;
>
> Testing for fail
On Wed, Aug 02, 2000 at 04:26:56PM -0700, Nathan Wiger wrote:
> I tend to agree with Tom's argument here. open() is kind of funny
> anyways. Why couldn't it work like this, similar to FileHandle:
>
>$fh = open $filename;
Testing for failure. It's a basic tenet that system calls can be
tested
> No: lists are the plural whatzitzes, containing zero or more singular
> whatzitzes. They are ordered. Arrays hold lists.
I tend to agree with Tom's argument here. open() is kind of funny
anyways. Why couldn't it work like this, similar to FileHandle:
$fh = open $filename;
print $fh "so
On Wed, Aug 02, 2000 at 06:28:47PM -0600, Tom Christiansen wrote:
> >I'd also like some 'what are you' introspection I can do on all scalars, on
> >a more formal basis than 'ref'. Either an expansion of the 'ref' functionality
> >to cover filehandles, or a more general system...
> What do you mean
Peter Scott writes:
: At 06:28 PM 8/2/00 -0600, Tom Christiansen wrote:
: >ref() has always been a de facto typeof operator, no?
: >
: > open my $fh, "< /etc/motd";
: > print ref $fh
: >GLOB
:
: Can we make that IO in P6...?
Maybe, but it might be some class derived from an IO object, de
At 06:28 PM 8/2/00 -0600, Tom Christiansen wrote:
>ref() has always been a de facto typeof operator, no?
>
> open my $fh, "< /etc/motd";
> print ref $fh
>GLOB
Can we make that IO in P6...?
--
Peter Scott
Pacific Systems Design Technologies
>I'd also like some 'what are you' introspection I can do on all scalars, on
>a more formal basis than 'ref'. Either an expansion of the 'ref' functionality
>to cover filehandles, or a more general system...
What do you mean, "formal"? ref() has always been a de facto typeof
operator, no?
o
>If the prefix-less form of filehandles was absent from Perl 6, I would be
>far less enthusiastic about my RFC. I agree; they're a kind of scalar.
>(Just occurred to me that one could view the % prefix of hashes as denoting
>a key-value pair by virtue of looking like two o's separated by a
>d
Peter Scott writes:
: If the prefix-less form of filehandles was absent from Perl 6, I would be
: far less enthusiastic about my RFC. I agree; they're a kind of scalar.
In fact, they're a kind of object.
: (Just occurred to me that one could view the % prefix of hashes as denoting
: a key-val
On Wed, Aug 02, 2000 at 02:51:20PM -0400, John Porter wrote:
> Peter Scott wrote:
> > Filehandles should use C<*> as a type prefix if typeglobs are eliminated.
> I missed previous discussion of this (if there was any),
> but it's an idea I've already thought about.
> It has my vote, fwiw.
I have
If the prefix-less form of filehandles was absent from Perl 6, I would be
far less enthusiastic about my RFC. I agree; they're a kind of scalar.
(Just occurred to me that one could view the % prefix of hashes as denoting
a key-value pair by virtue of looking like two o's separated by a
divide
Thus it was written in the epistle of Tom Christiansen,
>
> What about regexes?
>
> $foo = qr/blech/;
>
> Should that be /foo instead? :-)
>
> Notice how even objects use $, not something else.
<*chuckle*> Ok, point conceded.
Ted
--
Ted Ashton ([EMAIL PROTECTED]), Info Sys, Southern
>Scalars, hashes, arrays. There's actually more than one type of plural here,
>gramatically:
>scalars hashes arrays
>singulardualplural
>(Or am I the only one left who did Ancient Greek? :)
Nope: pudge and larry, at least.
>> (and don't say, "because plural *means* more
On Wed, Aug 02, 2000 at 05:31:06PM -0400, Ted Ashton wrote:
> But that, precisely, was my point: Arrays *and* hashes.
Scalars, hashes, arrays. There's actually more than one type of plural here,
gramatically:
scalars hashes arrays
singulardualplural
(Or am I the only one l
>> No: lists are the plural whatzitzes, containing zero or more singular
>> whatzitzes. They are ordered. Arrays hold lists.
>I tend to agree with Tom's argument here. open() is kind of funny
>anyways. Why couldn't it work like this, similar to FileHandle:
> $fh = open $filename;
> print $
>But that, precisely, was my point: Arrays *and* hashes. If there is more than
>one plural whatzitz, then why can't there be more than one singular whatzitz?
>(and don't say, "because plural *means* more than one" :-). If having a
>filehandle character would make the code clearer, then let's do
Thus it was written in the epistle of Jon Ericson,
> Ted Ashton wrote:
> > Thus it was written in the epistle of Tom Christiansen,
> > > Nope. A filehandle is a singular whatzitz. It thus mandatory takes
> > > the singular prefix; to wit, $. What's next? Integer and float and
> > > complex and
Ted Ashton wrote:
> Thus it was written in the epistle of Tom Christiansen,
> > Nope. A filehandle is a singular whatzitz. It thus mandatory takes
> > the singular prefix; to wit, $. What's next? Integer and float and
> > complex and string and char and bits prefixes?
>
> (Weighing in with th
Thus it was written in the epistle of Tom Christiansen,
> >Hearing no outright derision in response to my trial balloon, here it is as
> >an RFC:
>
> >=head1 TITLE
>
> >Filehandles should use C<*> as a type prefix if typeglobs are eliminated.
>
> Nope. A filehandle is a singular whatzitz. It
On Wed, Aug 02, 2000 at 11:46:15AM -0700, Peter Scott wrote:
> =head1 TITLE
>
> Filehandles should use C<*> as a type prefix if typeglobs are eliminated.
I could go for this, given the `if typeglobs are eliminated' caveat.
>Hearing no outright derision in response to my trial balloon, here it is as
>an RFC:
>=head1 TITLE
>Filehandles should use C<*> as a type prefix if typeglobs are eliminated.
Nope. A filehandle is a singular whatzitz. It thus mandatory takes
the singular prefix; to wit, $. What's next? Int
Peter Scott wrote:
> Filehandles should use C<*> as a type prefix if typeglobs are eliminated.
I missed previous discussion of this (if there was any),
but it's an idea I've already thought about.
It has my vote, fwiw.
--
John Porter
Hearing no outright derision in response to my trial balloon, here it is as
an RFC:
=head1 TITLE
Filehandles should use C<*> as a type prefix if typeglobs are eliminated.
=head1 VERSION
Maintainer: Peter Scott <[EMAIL PROTECTED]>
Date: 2 Aug 2000
Version: 1
Mailing List: perl6-la
58 matches
Mail list logo
