Nathan Wiger <[EMAIL PROTECTED]> writes:
>open 'http://www.yahoo.com/';
>open 'https://www.etrade.com/';# what module? https?
>
> No matter what, you're going to have to embed something in there that
> decides for you what todo. What if an "httpx:" method comes out?? Will
> Perl
Since what I proposed is obviously the wrong thing to do, I'm
wondering whether I should try redrafting RFC 69 or withdrawing it
completely, after which hopefully someone else will make a better
proposal. Please let me know. Thanks.
-Hao
On Fri, Aug 11, 2000 at 02:16:31AM -0700, Nathan Wiger wrote:
> [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 hav
On 9 Aug 2000, Chaim Frenkel wrote:
> > "JE" == Jon Ericson <[EMAIL PROTECTED]> writes:
>
> JE> Chaim Frenkel wrote:
> >> What does
> >>
> >> $foo = <"filename">;# 1
> >> $bar = <"another">;
> >> $gaz = <"filename">; # 2
>
> >> Does #2 get the second line or the first?
>
> JE> $
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
> ># 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
On Fri, 11 Aug 2000 10:31:55 -0400 (EDT), [EMAIL PROTECTED] wrote:
>Since what I proposed is obviously the wrong thing to do, I'm
>wondering whether I should try redrafting RFC 69 or withdrawing it
>completely, after which hopefully someone else will make a better
>proposal. Please let me know.
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;
> >
> > 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
> 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
Here's a list of attributes that I found in my old Symbolics Reference
Guide to Streams, FIles, and I/O. (March 1985)
Host
Device
Directory
Name
Type
Version
Plus it needs to handle cross-system support. How to specify the name
of a unix file when
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
[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
13 matches
Mail list logo
