Re: RFC 350 (v1) Advanced I/O (AIO)

> you would do: > > $sock = AIO::Open( Host => 'www.perl.org', >Port => 80 ) ; > Similarly for LWP you would just do: > > $sock = AIO::Open( Url => 'http://www.perl.org' ) ; > $event = AIO::Open( Host => 'www.perl.org', >

The One True Deadline is approaching

We've only got 4 days left until the One True Deadline on this whole thing. Please, go check this out: http://dev.perl.org/rfc/overdue-perl6-language-io.html And get your RFC's finished up. Remember: Oct 1st is a true deadline, coming from the powers above, meaning if your RFC is not frozen by t

Re: RFC 30 (v4) STDIN, STDOUT, STDERR, ARGV, and DATA should become scalars

Let's table this discussion, please. There are two different concerns here: 1. IO::Handle et al *are* too damn big and slow. 2. Bareword filehandles *are* a pain to deal with. Perl 5.6 already has a lot of this solved by allowing lexically-scoped variables to hold filehandles. We should

Re: RFC 100 (v2) Embed full URI support into Perl

Hildo Biersma wrote: > > > Personally I hated it. And I distinctly remember saying so. And I > > still hate it. > > I dislike it too. URIs are a user-space matter and should not be > built-in to the language - put it in a module. And if you have an OS > that implements URIs directly, well then

Re: RFC 100 (v2) Embed full URI support into Perl

> I'd rather see you drop (or footnote) the discussion of how the various > systems are going to map content among themselves, and focus more on > what the construct allows. For instance, returning to some of the > original implementation ideas, that the location information be passed > to the pr

Re: RFC 30 (v4) STDIN, STDOUT, STDERR, ARGV, and DATA should become scalars

Tom Christiansen wrote: > > >Scalars hold references to objects. Filehandles should, ultimately, > >be objects, as should directory handles. > > I haven't yet seen anybody yet propose bifurcating {file,directory}handles. > This would certainly be nice. If I'm understanding what you mean, I bel

Re: RFC 14 (v4) Modify open() to support FileObjects and Extensibility

Michael G Schwern wrote: > > On Sun, Sep 17, 2000 at 05:35:47AM -, Perl6 RFC Librarian wrote: > >$fo->untaint - Removes tainting from that data source > > I can guarantee this will be abused and severely water down the > utility of taint mode. Well, as Tom pointed out to me this alre

Sublist -io RFC wrap-up time

[ for those on -all or -objects this is gonna look real familiar :-) ] All- As Nat has mentioned on -meta, it's time to start wrapping things up. In particular, I think the following "deadlines" should apply: 1. Any and all *new* RFC's should be submitted by Wednesday at the absolute l

Re: RFC 30 (v4) STDIN, STDOUT, STDERR, ARGV, and DATA should become scalars

"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:

Re: Cross-referencing RFC 186 with RFC 183 and RFC 79

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) > >

Re: Cross-referencing RFC 186 with RFC 183 and RFC 79

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

Re: RFC 101 (v2) Handlers and Pseudo-classes

[added -io cross-post] John Porter wrote: > > Just MHO, but I don't think this is the kind of thing that should > go in the core. Just MHO. I think I agree. Just to clarify, the only reason it's an RFC and not just a Perl 5 module is because RFC 14 (the one on a new open()) relies on a handler

Re: "Standardization" of Perl IO functions

Jon Ericson wrote: > > Is a problem with writing these the other way around as well: > > @file = readline open(" print open(">>/var/log/logfile") "Hello, world!"; Currently - and by currently I mean that only RFC 14 was adopted and everything else stayed the same - these would have to be wr

"Standardization" of Perl IO functions

All- This is an idea I've been chewing on for some time. RFC 14 proposes a new syntax to open(): $FH = open dir "/usr/local/bin" or die "Badness: $!"; which is far different from the current open(). This is actually a more flexible and consistent syntax, with a cool feature I just came acros

Re: RFC 39 (v3) Perl should have a print operator

Jon Ericson wrote: > > I would want it to return @items: > > @sorted = sort print @items; > > I'd prefer a different name (tee?) and keep print as it is. Pretty much all the stuff being discussed right now can be stuck in a module: package Print::Variations; use Exporter; @EXPORT

Re: RFC 39 (v3) Perl should have a print operator

Jon Ericson wrote: > > Agreed. Good style would avoid this problem. The example in the > synopsis of this RFC should be: > > my $output = >"Print this line.\n"<; Would this be solved if print returned the string it printed? This seems to be what everyone's getting at: my $output = print

Re: RFC 129 (v1) Replace default filehandle/select with $DEFOUT, $DEFERR, $DEFIN

*finally* getting around to answering these... ;-) Jon Ericson wrote: > > This is not strictly true. <> is shorthand for . ARGV is the > special filehandle that opens each file in @ARGV. If @ARGV is empty, > $ARGV[0] is set to '-'. Thanks for the clarification. > @ARGV = ('filename'); >

Re: RFC 181 (v1) Formats out of core / New format syntax

> Have you also looked at Damian's Text::Autoformat, which has a renewed format > implementation that looks *very* good a candidate for replacing perl 4/5's > format. Yes, I have. It's actually very powerful. I've actually been meaning to talk to Damian about this, because at one time he had ment

Re: RFC 34 (v3) Angle brackets should not be used for file globbing

Tom Christiansen wrote: > > >Is some technical reason that this can't be done in perl 5? I hate > >having to add another pair of braces just to reassure perl that I didn't > >forget a comma: > > >print {$fh{$name}} "data\n"; > > Indirect objects are very limited in what they can be. Curre

Re: RFC 181 (v1) Formats out of core / New format syntax

Johan Vromans wrote: > > Good work! Thanks. :-) > Is there any reason left to maintain formats as something internally > special? Well, as you note in your implementation suggestions, it would be nice if Perl compiled the format the first time around. Along with the implicit constructors sugge

Re: filehandle objects et al.

Jerrad Pierce wrote: > > Perl6 does not *have* to break anything, and certainly not everything. > The prime directive should be not to break things unless necessary. > Translation should not be a fall-back panacea. And it surely isn't perfect... Actually, this is false. If Perl 6 worked just like

Re: RFC 39 (v2) Perl should have a print operator

"David L. Nicol" wrote: > > 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 think this is an excellent idea independ

Re: filehandle objects et al.

> I vehemently disagree with this filehandle object nonsense. > This is Perl, not Java, not Python. Everyone together Purrl... :-P Well, fileobjects are already in Perl 5. Most people just don't use them by default. But as TomC pointed out, in Perl 5 you can do this: open $fh, "$file";# i

Re: RFC 39 (v2) Perl should have a print operator

Jon Ericson wrote: > > I think this is a little premature. These are Requests For Comments not > Suggestions To Larry yet. So far, you have been to only person to offer > constructive criticism on this RFC. I think that it is a very small win > at the moment, but this is not the RFC's final fo

Re: RFC 39 (v2) Perl should have a print operator

> >"Print this line.\n"<; Some questions: 1. How do you specify alternate filehandles to output to? select() doesn't count for the purposes of this question. 2. How do you support the list form of print, namely: print "Hello there ", $r->fullname, "!\n"; 3. Can you

Re: RFC 30 (v2) STDIN, STDOUT, and STDERR should be renamed

Graham Barr wrote: > > > Create a new handle, like $DEFOUT. Then there would be no need > for selectsaver either as you would do the equiv. of > > local($DEFOUT) = $newhandle; Just submitted an RFC on this exact idea. -Nate

Re: RFC 100 (v1) Embed full URI support into Perl

> So, what's so portable about file:// URLs again? How do they magically > know that //c/ means / on UNIX? What do they do with //z/? This is only one example. I'm not sure it's the best way. It's definitely not the only way. Chaim asked: > Or for that matter "file://u/frankeh/Projects" become

Re: RFC 14 (v3) Modify open() to support FileObjects and

Chaim Frenkel wrote: > > You forget that open() handles all the magic. "| ...", " ...|", and > the rest of the family. Sysopen specifically doesn't. So one could > easily (and does) use open to do the magic, and then uses sysread/syswrite > to handle the dirty details of playing with a pipe. Yea

Re: RFC 14 (v3) Modify open() to support FileObjects and

> Random thoughts: > > open "http://www.perl.com"; > open "http://www.perl.com?foo=bar&baz=blat"; > open "http://www.perl.com", %args; > open "http://www.perl.com", { mode => 'POST' }, %args; > > Hmm. I think that "modes" should be made explicit rather than relyi

Re: RFC 100 (v1) Embed full URI support into Perl

Sam Tregar wrote: > > How is this better than File::Spec's approach? File::Spec has the idea and representation dead on. However, the interface is a pain; to write portable scripts you have to go through some contortions. With URI support, you still have to contort a little, but not as much. Her

Re: command line option: $|++

Peter Scott wrote: > > Can someone knowledgeable on this issue speak to it? > > Will $| $/ $\ et al be retired, or be valid for some default filehandle? > > Will there still be default filehandles? There's been a big debate on the -io list about this. No clear decisions yet, but looks like the

Re: RFC 100 (v1) Embed full URI support into Perl

Chaim Frenkel wrote: > > > "PRL" == Perl6 RFC Librarian <[EMAIL PROTECTED]> writes: > > PRL>$fo = open "C:\Windows\System";# non-portable > PRL>$fo = open "file://C|/Windows/System"; # portable > > In what way is the second example portable? I don't think it will > do anythi

Re: RFC 14 (v3) Modify open() to support FileObjects and

Chaim Frenkel wrote: > > >>>>> "NW" == Nathan Wiger <[EMAIL PROTECTED]> writes: > > NW># Replaced by 'open sys' > NW>sysopen > NW>sysread # sys->read instead > NW>syswrite# sys->

Re: RFC 14 (v3) Modify open() to support FileObjects and

> >myhttp->open("http://www.perl.com", "fred", "barney"); > > Indeed I had written it that way to begin with, but changed it because > it didn't seem to make a difference to me. Why is one "more correct" > than the other? Currently, there's no real difference. Depending on what happens in P

Re: RFC 14 (v3) Modify open() to support FileObjects and

> $fh = open socket "tcp://www.perl.com:80"; This is not bad, I hadn't thought of making it URI-like. There is already a proposal in the RFC to replace socket() with: # Open a client socket # By overloading < and > we can do clients and servers $socket = open socket "< 25", PF_I

Re: RFC 14 (v3) Modify open() to support FileObjects and

> $fh = open file "http://my.homepage.com"; Excellent point. Thanks Scott! :-) > or less verbose, > > $fh = open "

Re: RFC 14 (v3) Modify open() to support FileObjects and

> open "http://my.homepage.com"; # the file Well, I think this is a bit of an edge case. If you really have a file named this, it would have to be in UNIX, named: http:/my.homepage.com So, you'd have a UNIX directory named "http:" containing the file "my.homepage.com". The double // will get

Re: RFC 30 (v3) STDIN, STDOUT, and STDERR should be renamed

Jonathan Scott Duff wrote: > > Everytime I see this I think that Perl should have it's own namespace > for special variables. > > print $PERL::STDERR "Oops!\n"; Check out RFC 17, it deals with this issue somewhat. The two suggestions I like that I've heard are the one you mention and $P

Re: RFC 14 (v3) Modify open() to support FileObjects and

> What does that mean? When the handler is invoked, what does it see? > > $fh = open myhttp "http://www.perl.com", "fred", "barney"; > > Does that result in a call like this? > > myhttp::open("http://www.perl.com", "fred", "barney"); Exactly. Or to be "more correct" myhttp

Re: Internal Filename Representations (was Re: Summary of I/O related RFCs)

> And how do we make it easy to pass in a name to open? In an email I sent to Jarkko off-list, I suggested this: If we embedded full URI support into Perl, then people could write portable scripts using URIs, or non-portable ones using native syntax. *Internally*, both could be converted into so

Re: RFC 14 (v3) Modify open() to support FileObjects and

> Pick one: > > 1) Filenames that end with a '/' are directories and those that don't > are files. (Both examples are files.) No, too restrictive. I don't like this and would hate having to remember it. > 2) Filenames are tested to determine how they are to be opened. (C<-f > '/etc'> is fa

Re: Internal Filename Representations (was Re: Summary of I/O related RFCs)

Chaim Frenkel wrote: > > The VMS (and TOPS20) advocates will scream here. Versions are part of > the file name. The default is the latest version. But the filesystem > automatically versions files. > > Hmm, if we support versioning files, will perl have to support emacs > versioned files? /foo/b

Re: Internal Filename Representations (was Re: Summary of I/O related RFCs)

> I think it's far from trivial, especially if you want to take into > account network names, file versions, protection attributes and ACLs, ... Sure, this all depends on what we're going to do with this data and at what level. The biggest problem that modules like CGI.pm have to deal with is jus

Re: RFC 30 (v2) STDIN, STDOUT, and STDERR should be renamed

> >The rule is easier ("print always goes to $STDOUT, whatever that > >contains") and there's not select() overhead. Everything else should be > >object methods, making stuff clearer still. > > And it is also a pain in the butt. > > select *LOG; > do_stuff(); > > sub do_stuff { > pri

Re: RFC 30 (v2) STDIN, STDOUT, and STDERR should be renamed

> That's no different than the current state of affairs. > >$oldoutput = *STDOUT; >*STDOUT = $filehandle; > > I don't see how select() is any less needed under this proposal than it is now. Perl 5 has the concept of a "currently selected filehandle". So, whatever is selected by select()

Re: RFC 14 (v3) Modify open() to support FileObjects and

> If not, you can always C. Not under the RFC! :-) It calls for removal of opendir and lots of other functions as being deletable because the new open can handle directories, system calls, and so on. In another email you asked: > Why not extend C to be able to take other things besides > string

Re: RFC 14 (v3) Modify open() to support FileObjects and

> ># Open a remote webpage > >$http = open http "http://www.perl.com/", GET; > ^ 1) > The URL says that it's a http resource, so why do we have > to tell open to use a http handler? a) Allows custom handlers: open myhttp "http://ww

Internal Filename Representations (was Re: Summary of I/O related RFCs)

[cc'ed on internals as FYI] > =item 36 (v1): Structured Internal Representation of Filenames 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 cumb

Re: RFC 14 (v2) Modify open() to support FileObjects and

> Also, what if you write your own module, say "MyHttp", that you want to > open certain documents? How do you do this? The more general notation: > >open MyHttp, 'http://www.yahoo.com/', $custom, $args; Dangit! That first comma shouldn't be there (typo). Should say: open MyHttp 'http://

Re: RFC 14 (v2) Modify open() to support FileObjects and

> This is nutso... shall we open->ssh and open->telnet and > open->any_protocal_under_the_sun in the core? Well, just because the hooks are there doesn't mean all the member modules have to be in core. The idea would be, as Tom Hughes suggests: > That is if the core provides a way for modules to

Re: RFC 14 (v2) Modify open() to support FileObjects and

> How about this? > > open '/etc/passwd'; # file > open '/usr/local/bin/'; # directory (note the trailing '/') > open 'ftp://ftp.perl.org/'; # ftp > open 'http://www.yahoo.com/'; # http > open 'ldap://ldap.bigfoot.com/';# ldap I t

Re: RFC 14 (v2) Modify open() to support FileObjects and

> It occurs to me that one could embed the class name right in the first > argument: > > $perl = open 'ftp://ftp.linux.activestate.com/pub/staff/gsar/APC/' > or die "ActiveState ftp site is hosed again: $!"; Yeah, the next version is going to include a syntax that's very similar to this, a

Re: RFC 14 (v2) Modify open() to support FileObjects and

> It is far from clear that having user specify the class as an input > is always the right thing to do. > > I don't like the idea of zillions of perl6 scripts getting hard-coded > IO::File when we decide to change the class hierachy in perl6.2. Great point. If you see at the bottom under IMPLEM

Re: Treating filehandles like strings

> I'd rather have a filehandle stringify to > the filename instead. Great minds think alike. :-) I was actually going to add this to the new version of the open() RFC as a possible use of RFC 49's soon-to-be-renamed STRING method. Now I know I have at least I have one supporter! ;-) -Nate

Re: RFC 14 (v2) Modify open() to support FileObjects and

> If it is possible to get both the higher level and the lower level > implementation layers to be active at the same time would be great. > > But don't lose the access to the bare metal. Sorry, looks like I should have included an example on sysopen(): # Open files like sysopen() $fo = o