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

On Tue, 15 Aug 2000, Nathan Wiger wrote: > 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

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 14 (v3) Modify open() to support FileObjects and

Nathan Wiger wrote: ># Replaced by 'open socket' >socket >setsockopt # socket->options >connect # overload <> or socket->connect >shutdown# close instead > close and shutdown are not exactly the same, especially when a fork has occurred and a child proces

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

[EMAIL PROTECTED] (Nathan Wiger) wrote on 12.08.00 in <[EMAIL PROTECTED]>: > Here's a step-by-step process for supporting both that I propose. > Suggestions welcome: > > 1. If called as an indirect object function (in the form currently >proposed), steps 2-3 are skipped and the handler speci

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

On Sat, 12 Aug 2000, Nathan Wiger wrote: > > 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. > Plus the non-"/" separated fi

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

On Mon, Aug 14, 2000 at 03:01:54PM -0700, Nathan Wiger wrote: > > or less verbose, > > > > $fh = open " > This is still up in the air. I think this will probably end up doing a > GET via the http handler on the webpage specified. That seems the most > natural,

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

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. Oh, before I forget, one also needs

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->write instead > > sysread and syswrite also work on files that were opened via standa

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

> "NW" == Nathan Wiger <[EMAIL PROTECTED]> writes: NW># Replaced by 'open sys' NW>sysopen NW>sysread # sys->read instead NW>syswrite# sys->write instead sysread and syswrite also work on files that were opened via standard open. It bypasses the stdio library.

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

Today around 2:54pm, Nathan Wiger hammered out this masterpiece: : > 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 dir

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 14 (v3) Modify open() to support FileObjects and

On Mon, Aug 14, 2000 at 04:50:51PM -0400, Casey R. Tweten wrote: > open HOME_PAGE, "> $url" or die $!; #assuming default (as of 5.6.x) syntax > print HOME_PAGE getprint $url; > close HOME_PAGE; > > So now we have a file called `http://my.homepage.com`. Perhaps we want to > parse this file, so

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

Today around 1:08pm, Jonathan Scott Duff hammered out this masterpiece: : Where are these handlers registered? How are they registered? In my : mind I was thinking that we could just name our handlers as packages : so that : : $fh = open "http://www.perl.com"; # and :

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

On Sat, Aug 12, 2000 at 11:01:30PM -0400, Chaim Frenkel wrote: > What hasn't been discussed, is > > Are files (or perhaps resources) named natively or in a portable fashion? > > If portable, then > for (@ARGV) { open $_; ... } > has to DWIM both portable and native formats. > > If native

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

On Mon, Aug 14, 2000 at 11:21:38AM -0700, Nathan Wiger wrote: > Exactly. Or to be "more correct" > >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 corre

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: RFC 14 (v3) Modify open() to support FileObjects and

On Sat, Aug 12, 2000 at 09:09:33PM -0700, Nathan Wiger wrote: > 1. If called as an indirect object function (in the form currently >proposed), steps 2-3 are skipped and the handler specified is >automatically invoked. What does that mean? When the handler is invoked, what does it see?

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

Joe McMahon wrote: > On Sat, 12 Aug 2000, Nathan Wiger wrote: > > > 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. > >

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: RFC 14 (v3) Modify open() to support FileObjects and

> "JSD" == Jonathan Scott Duff <[EMAIL PROTECTED]> writes: JSD> I originally didn't like this but the more I think about it, the more JSD> I like it ... as long as the default handler knows about URIs :-) JSD> I'd like JSD>open "http://www.perl.com"; JSD> do DWIM. (Some random though

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

Nathan Wiger wrote: > In another email you asked: > > > Why not extend C to be able to take other things besides > > strings of text? This wasn't me. > Registering a custom handler has this capability. For example: > >use handler 'myhttp' => MyCustomMod; # upcoming syntax >open myhtt

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

On Fri, Aug 11, 2000 at 02:58:34PM -0700, Nathan Wiger wrote: > > ># 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 u

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

Nathan Wiger wrote: > 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://www.perl.com/"; Explicitly register custom handles: use myhttp; register open, 'http' => myhttp::new;

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

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

Perl6 RFC Librarian wrote: ># Open a remote webpage >$http = open http "http://www.perl.com/", GET; ^ >@doc = <$http>; >print @doc if $http->content_type eq 'text/html'; >close $http; This open seems awfully crufty to me. The U

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

This and other RFCs are available on the web at http://dev.perl.org/rfc/ =head1 TITLE Modify open() to support FileObjects and Extensibility =head1 VERSION Maintainer: Nathan Wiger <[EMAIL PROTECTED]> Date: 04 Aug 2000 Last-Modified: 11 Aug 2000 Version: 3 Mailing List: [EMAIL