(reply-to set to bootstrap)
On Wed, Aug 16, 2000 at 01:36:47AM -0600, Tony Olekshy wrote:
>On this matter, should something like this be a (meta) RFC?
>
> Guidelines for Developing Changes for Perl 6 (v0.1).
There's nothing to stop you writing an RFC on whatever you like :)
However, there's not
Chaim Frenkel <[EMAIL PROTECTED]> writes:
>> "DS" == Dan Sugalski <[EMAIL PROTECTED]> writes:
>
>DS> I was actually thinking that @b * @c would boil down to a single vtable
>DS> call--we'd just hit the multiply function for variable @b, and pass it a
>DS> pointer to @c, and let it Do The Rig
On Tue, Aug 15, 2000 at 04:59:19PM -0800, Michael Fowler wrote:
> On Tue, Aug 15, 2000 at 12:33:15PM +0100, Tim Bunce wrote:
> > On Mon, Aug 14, 2000 at 11:30:28AM -0500, Jonathan Scott Duff wrote:
> > > use Foo;# like CGI.pm, morphs on demand
> > >
> > > use Foo;
I do not know what advantages the try statement would have in perl.
However, in Java programming it makes exception handling more explicit. It
basically allows the programmer to "try" a certain action and see what the
effects are going to be (i.e. handle the exception) so that some action can
the
At 07:40 PM 8/15/00 -0600, Tony Olekshy wrote:
> > > catch { ... }
> > >
> > > Invoked if unwinding. This is a post-finally catch,
> >
> > What's this for? If the finally block throws?
>
>Actually it's invoked if we're unwinding at that point, according to
>the definition of unwindin
Graham Barr wrote:
>
> I would add to that, that as long as the addition of this does not effect
> the performance of calling the methods that want the "relaxed perl5-ish"
> semantics.
>
> Graham.
The IMPLEMENTATION of the rfc97 working document (unfortuneately
not web accessible, I may chang
On Tue, Aug 15, 2000 at 04:59:19PM -0800, Michael Fowler wrote:
> Which makes me think of the following. You don't need to 'use' a seperate
> module for a procedural or OO interface. The module author could simply
> provide a constructor in the procedural module that would require the OO
> modul
On Tue, Aug 15, 2000 at 12:33:15PM +0100, Tim Bunce wrote:
> I don't think you can make much valuable progress down that road till
> we know what Larry's thinking about how to support multiple installed
> versions of a module and multiple implementations of the same 'interface'.
I think much of t
On Tue, Aug 15, 2000 at 03:17:36PM -0400, Chaim Frenkel wrote:
> > "GB" == Graham Barr <[EMAIL PROTECTED]> writes:
>
> GB> On Tue, Aug 15, 2000 at 10:14:36AM -0400, Chaim Frenkel wrote:
> >> As much as I'm not for it, would
> >>
> >> having
> >>
> >> sub foo :method {} # In objects
> There has been some suggestion of perl not putting the object in the argument
> list when calling a method, but instead having a special var.
>
> If that happens we should be able to test the special var for defined-ness
> to determine how we were called.
>
> Just a thought.
Perl RFC97 sugge
On Tue, Aug 15, 2000 at 08:11:55PM +, David L. Nicol wrote:
> Would someone please enlighten me as to the purpose of an explicit "try."
In my mind it allows the important code to come before the "oh crap something
went wrong" code.
Graham.
Chaim Frenkel <[EMAIL PROTECTED]> writes:
> > "PRL" == Perl6 RFC Librarian <[EMAIL PROTECTED]> writes:
> PRL> =head2 $SIG{__DIE__}
>
> PRL> <$SIG{__DIE__}> needs to be triggered only as a I resort
> PRL> instead of firing immediately, since it messes with the mind of
> PRL> this and every o
Graham Barr <[EMAIL PROTECTED]> writes:
> Also, I have come to dislike the name `exception', its too long for me :)
> and who says we have to copy everyone else.
>
> Lookin in the thesaurus we get
>
> [Nouns] nonconformity [more]; unconformity, disconformity;
> unconventionality, informality, ab
Chaim Frenkel <[EMAIL PROTECTED]> writes:
>What about native extensions? I think VMS (and the old TOPS10) had versions
>as part of the file name.
>
>Do URIs have this capablity?
>
>And what does a read of a directory return? URIs or Native?
Relative URIs I assume - what are (hopefully) indistingu
This and other RFCs are available on the web at
http://dev.perl.org/rfc/
=head1 TITLE
object neutral error handling via exceptions
=head1 VERSION
Maintainer: Glenn Linderman <[EMAIL PROTECTED]>
Date: 16 Aug 2000
Version: 1
Mailing List: [EMAIL PROTECTED]
Number: 119
=head1 ABSTRAC
> This would change the perl5 meaning of lvalue subroutines. Currently
> you must have the lvalue as the last value before the return, and the
> assignment is implicitly done by Perl. I advocate making it explicit:
>
> # this is perl5
> sub foo :lvalue {
> $variable
Stephen P. Potter wrote:
> Lightning flashed, thunder crashed and Perl6 RFC Librarian
<[EMAIL PROTECTED]>
> whispered:
> | =head1 TITLE
> |
> | Builtin: partition
> |
> | =head1 ABSTRACT
> |
> | It is proposed that a new function, C, be added to Perl.
> | C would return @list broken into
> | refe
On Wed, Aug 16, 2000 at 10:11:32AM -0400, Chaim Frenkel wrote:
> > "TO" == Tony Olekshy <[EMAIL PROTECTED]> writes:
>
> TO> Consider "finally" vs. "always". Always? Even if force majeur?
> TO> Finally simply means, "as the final act of the unwind processing".
>
> Am I missing something. I
On Tue, Aug 15, 2000 at 11:59:50PM -0600, Tony Olekshy wrote:
> > for (@PERL::EXCEPTIONS) {
> > print $_->file, "\t", $_->line, "\n";
> > }
>
> Yawn. That's the way RFC 88 v1 does it. Check it out.
I've read it ... perhaps that's what even gave me the idea, but that
On Wed, Aug 16, 2000 at 10:19:53AM -0400, Chaim Frenkel wrote:
> I would say that outside of the try block all throws are caught if
> at all by the wrapping try. So that throws propogate outward. Never
> back within itself.
Agreed.
> There is one case to be considered, what if the try block wish
My philosophy - do nothing unless its needed. Therefore there are no
rules, and I'll attempt to avoid creating any. I remain subscribed
to language-flow, and will redirect appropriate discussion to here.
Our deadline - August 29. It's actually a little tighter than that,
because on the morning
The proposed omnibus Exceptions RFC uses the following three
rules to guide it while unwinding through the clauses of a
try statement.
Rule 1: Uncaught Exceptions Propagate
At the end of the try statement, you are going to continue
unwinding up another level if *anything* threw, *unless*
> "TO" == Tony Olekshy <[EMAIL PROTECTED]> writes:
TO> However, many people have broached topics such as conditional catch
TO> blocks (such as those based on the exception's isa relationships),
TO> multiple catch clauses with varying conditions, and post-finally
TO> catch blocks.
TO> I agree
[EMAIL PROTECTED] wrote:
>
> On Tue, Aug 15, 2000 at 09:27:23PM -0700, Ask Bjoern Hansen wrote:
> >LIST: perl6-language-objects
> >CHAIR: Nathan Wiger <[EMAIL PROTECTED]>
> >MISSION:Develop RFCs related to objects and OO programming in
> >Perl, possibly
> "TO" == Tony Olekshy <[EMAIL PROTECTED]> writes:
TO> Consider "finally" vs. "always". Always? Even if force majeur?
TO> Finally simply means, "as the final act of the unwind processing".
Am I missing something. I thought that the finally clause is executed
under normal and exceptional co
> "TO" == Tony Olekshy <[EMAIL PROTECTED]> writes:
TO> Using exceptions for failure signalling is a more robust software
TO> engineering technique, but only if your exception handling mechanism
TO> doesn't "encourage" you to drop exceptions of the floor.
Is this proven or just an assertion o
I would say that outside of the try block all throws are caught if
at all by the wrapping try. So that throws propogate outward. Never
back within itself.
There is one case to be considered, what if the try block wishes
to avoid its own catch clauses, and start the unwinding with the
uplevel try
On Tue, Aug 15, 2000 at 11:59:40PM -0600, Tony Olekshy wrote:
> Problem 1:
>
> In a large lexical scope, you have no preindication that intended
> non-local flow control is in effect until you read all the way to
> the end of the scope. The equivalent of your example in more human-
> friendly te
On Sat, 12 Aug 2000, Bart Lateur wrote:
[...]
> different either. I too think that the input file separator should have
> regexish features, if the programmer wishes so. Now, one can only set $/
[...]
> My thoughts would be: a DFA regex engine, i.e. a state machine which is
> controlled by the n
On Wed, Aug 16, 2000 at 07:39:33AM -0700, Dave Storrs wrote:
> The idea of having two different regex "languages" in Perl makes
> me very, very nervous. Potential for confusion
Indeed.
> How about instead we build the DFA as you describe, with its more
> limited syntax, but it must
I'll try to scrap and rewrite the RFC this weekend.
> $/ = qr/[\r\n]/f; # fast ?
How about we use the specialized DFA regex, but also slightly
different notation?
-Hao
This and other RFCs are available on the web at
http://dev.perl.org/rfc/
=head1 TITLE
context-based method overloading
=head1 VERSION
Maintainer: David Nicol <[EMAIL PROTECTED]>
Date: 14 Aug 2000
Last-Modified: 16 Aug 2000
Version: 2
Mailing List: [EMAIL PROTECTED]
Number: 98
=h
I thought very carefully about this before writing the Highlander
Variables RFC, and came to the conclusion that it's a bad idea.
I've read your proposal, but I'm afraid I still think it's a bad idea.
Those funny characters tell the programmer what's going on, and they
tell the compiler what the
This and other RFCs are available on the web at
http://dev.perl.org/rfc/
=head1 TITLE
Angle brackets should not be used for file globbing
=head1 VERSION
Maintainer: Jon Ericson <[EMAIL PROTECTED]>
Date: 4 August 2000
Last-Modified: 17 August 2000
Version: 2
Mailing List: [EMAIL PRO
This and other RFCs are available on the web at
http://dev.perl.org/rfc/
=head1 TITLE
Perl should have a print operator
=head1 VERSION
Maintainer: Jon Ericson <[EMAIL PROTECTED]>
Date: 5 August 2000
Last-Modified: 17 August 2000
Version: 2
Mailing List: [EMAIL PROTECTED]
Number:
Chaim Frenkel <[EMAIL PROTECTED]> writes:
> > "EH" == Evan Howarth <[EMAIL PROTECTED]> writes:
>
> EH> Chaim Frenkel <[EMAIL PROTECTED]> writes:
> >> Why would anyone want to select a different method based upon the
> >> arguments.
>
> EH> The classic example is event dispatch. Say a generi
Damian Conway <[EMAIL PROTECTED]> writes:
>> > Why would anyone want to select a different method based upon the
>> > arguments.
>>
>> Have you seen Class::Multimethods? This kind of despatch can be very
>> useful. Of course, the existence of Class::Multimethods proves that i
This and other RFCs are available on the web at
http://dev.perl.org/rfc/
=head1 TITLE
lvalue subs: parameters, explicit assignment, and wantarray() changes
=head1 VERSION
Maintainer: Nathan Torkington <[EMAIL PROTECTED]>
Date: Aug 16, 2000
Version: 1
Mailing List: [EMAIL PROTECTED]
[EMAIL PROTECTED] (Nathan Torkington) wrote on 15.08.00 in
<[EMAIL PROTECTED]>:
> Stephen P. Potter writes:
> > Why is it silly? Hashes and arrays are *conceptually* very similar
> > (even if they are extremely different implementation-wise).
>
> If that were the case, I think students would h
[EMAIL PROTECTED] (Nathan Torkington) wrote on 15.08.00 in
<[EMAIL PROTECTED]>:
> * you misunderstand the purpose of $ and @, which is to indicate
>singular vs plural.
Yes. That's one of the things that's wrong with it - maybe the biggest of
all.
It's one of the things that require con
[EMAIL PROTECTED] (Russ Allbery) wrote on 15.08.00 in
<[EMAIL PROTECTED]>:
> > All variables should be C<$x>. They should behave appropriately
> > according to their object types and methods.
>
> No thanks. I frequently use variables $foo, @foo, and %foo at the same
> time when they contain th
[EMAIL PROTECTED] (Jonathan Scott Duff) wrote on 15.08.00 in
<[EMAIL PROTECTED]>:
> You're right, there should be just one date/time routine. But it is
> *extremely* difficult to incorporate time zones in a portable fashion.
> They change at legislative whim. But if utcdate() (or whatever we
[EMAIL PROTECTED] (Nathan Wiger) wrote on 15.08.00 in
<[EMAIL PROTECTED]>:
> > I'd say, if the variable exists, interpolate it. If not, print it as
> > it stands.
>
> I initially was thinking this too, but there's a major problem:
>
>print "Your stuff is: @stuff\n";
>
> I want this to *alw
Nathan Wiger writes:
> sub somesub {
> my(@stuff) = @_;
> # do nothing
> }
>
> Then I think both of these should act exactly the same:
>
> somesub(@values);
> somesub = @values;
EUGH. No way!
Assignment should be used to reflect (get this) assignment. Using
it
Glenn Linderman wrote:
>
> This deserves a "me too".
>
> Perl6 RFC Librarian wrote:
>
> > The camel and the docs include this example:
>
> >if (/Time: (..):(..):(..)/) {
> > $hours = $1;
> > $minutes = $2;
> > $seconds = $3;
> > }
> >
> > This then becomes:
> >
Nathan Wiger writes:
> Nonetheless, I think a better thing would be to figure out if it's
> possible to "fix" this issue. I would *really* like lvalue subs ==
> rvalue subs.
I think conflating:
foo(@vals)
and
foo() = @vals
is misleading and going to cause more confusion that it solves.
>
s/PSEUDO\S?HASH/STRUCT/g
On 8/16/00 12:37 PM, Perl6 RFC Librarian wrote:
> This RFC proposes that the current constant.pm module removed, and
> replaced with a syntax allowing any variable to be marked as constant.
Unfortunately, I submitted an nearly identical RFC yesterday because I
didn't see the existing one (I searc
This and other RFCs are available on the web at
http://dev.perl.org/rfc/
=head1 TITLE
Scope of Polymorphic References and Objects
=head1 VERSION
Maintainer: Syloke Soong <[EMAIL PROTECTED]>
Mailing List: [EMAIL PROTECTED]
Date: 15 Aug 2000
Last-Modified: 16 Aug 2000
Versi
This and other RFCs are available on the web at
http://dev.perl.org/rfc/
=head1 TITLE
Better constants and constant folding
=head1 VERSION
Maintainer: John Siracusa <[EMAIL PROTECTED]>
Date: Aug 15 2000
Version: 1
Mailing List: [EMAIL PROTECTED]
Number: 113
=head1 AB
This and other RFCs are available on the web at
http://dev.perl.org/rfc/
=head1 TITLE
Perl resource configuration
=head1 VERSION
Maintainer: Jonthan Scott Duff <[EMAIL PROTECTED]>
Date: 16 Aug 2000
Version: 1
Mailing List: [EMAIL PROTECTED]
Number: 114
=head1 ABSTRACT
Perl should
Nathan Torkington wrote:
>
> > Then I think both of these should act exactly the same:
> >
> > somesub(@values);
> > somesub = @values;
>
> EUGH. No way!
>
> Assignment should be used to reflect (get this) assignment. Using
> it as argument passing is disgusting. I'm assuming you're n
At 08:03 PM 8/16/00 +, Perl6 RFC Librarian wrote:
>Perl should provide a mechanism to have common code autoloaded from a
>file.
Please, no. It's the ultimate scary action-at-a-distance.
I spent several years doing X programming. Ever seen the flowchart for how
resources are resolved? Let
On 16 Aug 2000, Kai Henningsen wrote:
> > This is very Perlish to me; the punctuation is part of the variable name
> > and disambiguates nicely. I'd be very upset if this idiom went away.
>
> That would be nice if the punctuation actually *were* part of the variable
> name.
>
> However, it i
On 8/16/00 3:55 PM, John Siracusa wrote:
> On 8/16/00 12:37 PM, Perl6 RFC Librarian wrote:
>> This RFC proposes that the current constant.pm module removed, and
>> replaced with a syntax allowing any variable to be marked as constant.
>
> Unfortunately, I submitted an nearly identical RFC yesterd
On Wed, Aug 16, 2000 at 01:07:24PM -0700, Peter Scott wrote:
> At 08:03 PM 8/16/00 +, Perl6 RFC Librarian wrote:
> >Perl should provide a mechanism to have common code autoloaded from a
> >file.
>
> Please, no. It's the ultimate scary action-at-a-distance.
If the programmer *wants* action-a
This and other RFCs are available on the web at
http://dev.perl.org/rfc/
=head1 TITLE
Default methods for objects
=head1 VERSION
Maintainer: pdl-porters team <[EMAIL PROTECTED]>
Date: 16 August 2000
Version: 1
Mailing List: [EMAIL PROTECTED]
Number: 115
=head1 ABSTRACT
This RFC p
This and other RFCs are available on the web at
http://dev.perl.org/rfc/
=head1 TITLE
Perl syntax support for ranges
=head1 VERSION
Maintainer: pdl-porters team <[EMAIL PROTECTED]>
Date: 16 August 2000
Version: 1
Mailing List: [EMAIL PROTECTED]
Number: 117
=head1 ABSTRACT
This RF
> I think conflating:
>foo(@vals)
> and
>foo() = @vals
>
> is misleading and going to cause more confusion that it solves.
In simple cases, yes. The above looks misleading. Advanced stuff like
chaining though would be really cool. I could come up with oodles of
examples. :-)
> What kind
On Wed, Aug 16, 2000 at 03:05:23PM -, Perl6 RFC Librarian wrote:
> With a here doc print < the text of the here doc, is processed verbatum. This results in Here Docs
> that either stick out in the code, or result in unwanted leading whitespace.
> There are several FAQs that relate to this pro
Perl6 RFC Librarian writes:
> It is proposed that in a list context, operators are applied
> component-wise to their arguments. Furthermore, it is proposed that
> this behaviour be extended to functions that do not provide a specific
> list context.
I don't mind making Perl's builtins do this. M
> "CN" == Chris Nandor <[EMAIL PROTECTED]> writes:
CN> Can we please cut down on the traffic to perl-announce, maybe make it
CN> moderated? Thanks,
Perhaps, the esteemed Librarian could make the -announce a Bcc?
--
Chaim FrenkelNonlinear Knowledge,
Today around 8:03pm, Perl6 RFC Librarian hammered out this masterpiece:
: This and other RFCs are available on the web at
: http://dev.perl.org/rfc/
:
: =head1 TITLE
:
: Perl resource configuration
:
: =head1 VERSION
:
: Maintainer: Jonthan Scott Duff <[EMAIL PROTECTED]>
: Date: 16 Aug
At 09:49 PM 8/16/00 +0200, Kai Henningsen wrote:
>[EMAIL PROTECTED] (Dan Sugalski) wrote on 15.08.00 in
><[EMAIL PROTECTED]>:
>
> > At 06:04 PM 8/15/00 -0400, John Porter wrote:
> > >Dan Sugalski wrote:
> > > > >Generality good.
> > > >
> > > > For many things, yes. For computers, say. For peopl
Karl Glazebrook wrote:
>
> Jon Ericson wrote:
> > But @ and % provide important context clues (if not to perl than
> > certainly for programmers). We could also eliminate the plural case in
> > English, but this would be endlessly confusing for native speaker
> > (err... speakers). Why not chan
[EMAIL PROTECTED] (Dan Sugalski) wrote on 15.08.00 in
<[EMAIL PROTECTED]>:
> At 06:04 PM 8/15/00 -0400, John Porter wrote:
> >Dan Sugalski wrote:
> > > >Generality good.
> > >
> > > For many things, yes. For computers, say. For people, no. Generality
> > > bad. Specificity and specialization go
Kai Henningsen <[EMAIL PROTECTED]> writes:
> That would be nice if the punctuation actually *were* part of the
> variable name.
> However, it isn't: to access 'second', you'd say $args[1], NOT @args[1].
> It's one of the Perl features that most confuses newcomers.
Well, I think it is; it's just
On Wed, Aug 16, 2000 at 02:38:33PM -0400, Uri Guttman wrote:
> i see problems with overlapping areas. I/O callbacks fall under both io
> and flow IMO. some of the error handling like dying deep in eval and
> $SIG{DIE} also fall under error and flow.
This is true, and inevitable. But IMHO it'd b
On Wed, Aug 16, 2000 at 08:03:31PM -, Perl6 RFC Librarian wrote:
> Perl should provide a mechanism to have common code autoloaded from a
> file. . . .
> A C file could be used to set system-wide defaults that
> the system administrator would like to promote. For instance,
> C could turn on
On Wed, Aug 16, 2000 at 01:51:09PM -0600, Nathan Torkington wrote:
> Nathan Wiger writes:
> > Nonetheless, I think a better thing would be to figure out if it's
> > possible to "fix" this issue. I would *really* like lvalue subs ==
> > rvalue subs.
>
> I think conflating:
>foo(@vals)
> and
>
> Think on this:
>
> use perlrc qw/Resource1 Resource5/; # Import only named 'Resources'
>
> use perlrc qw/:all/;# Import all 'Resources'
> This sounds much more managable than a .perlrc that get's applied globaly
> without asking for it.
Bingo. This feature should be off by de
Damien Neil wrote:
> What makes you presume this? Perhaps snrub() is something like this:
>
> sub snrub {
> foreach (@_) {
> frobnicate $_;
> }
> }
>
> You appear to arguing that expressions in function argument lists should
> not be evaluated in a list context. Is this real
Dan Sugalski writes:
> Unfortunately, I think you're somewhat under-informed as to the inherent
> capabilities of people's brains.
Ok, at this point I think all parties have to step away and let the
RFCs fall where they will.
It's obvious that there are two types of people: those who don't mind
Well said!
My take: I like perl, I don't mind it the way it is. But I'd be happier if
it was a lot more like python! (indentation aside)
I guess the question arises - how radical is perl6 allowed to be?
Karl
Kai Henningsen wrote:
> And context dependency is bad for people.
>
> There is a reas
Chaim Frenkel writes:
> CN> Can we please cut down on the traffic to perl-announce, maybe make it
> CN> moderated? Thanks,
>
> Perhaps, the esteemed Librarian could make the -announce a Bcc?
One of the moderators was a little too approval-happy. I believe
this has been fixed as of a few hours
Jon Ericson wrote:
> I've spent almost a day trying to come up with a polite response to this
> suggestion. I have started this mail 3 or 4 times but deleted what I
> wrote because it was too sarcastic, angry or dismissive. This RFC
Thanks!
> strikes to the very heart of Perl as far as I'm c
[EMAIL PROTECTED] (Dan Sugalski) wrote on 15.08.00 in
<[EMAIL PROTECTED]>:
> The ultimate target of a program's source code is the *programmer*.
True.
> Programmers, being people (well, more or less... :), work best with symbols
> and rich context.
This particular programmer *hates* what Per
Nathan Torkington wrote:
> Piers Cawley writes:
> > > > The $a and $b of the sort comparator were A Bad Idea to begin with.
> > >
> > > Ditto. Can we ditch these in Perl 6? Don't see why $_[0] and $_[1]
can't
> > > be used, or even a more standard $1 and $2. Either one makes it more
> > > obvious
Well said!
Nathan Torkington wrote:
>
> Dan Sugalski writes:
> > Unfortunately, I think you're somewhat under-informed as to the inherent
> > capabilities of people's brains.
>
> Ok, at this point I think all parties have to step away and let the
> RFCs fall where they will.
>
> It's obvious
Nathan Torkington wrote:
> Perl6 RFC Librarian writes:
> > It is proposed that in a list context, operators are applied
> > component-wise to their arguments. Furthermore, it is proposed that
> > this behaviour be extended to functions that do not provide a specific
> > list context.
>
> I don't m
Karl Glazebrook wrote:
> Nathan Wiger wrote:
> > Yeah, and isn't it cool that Perl gives you easy access to using and
> > understanding such complex data structures:
> >
> >print @{ $cars->{$model} };
> >
> > That "junk" makes it easy to see that you're derefencing a hashref that
> > contains
Nathan Wiger <[EMAIL PROTECTED]> writes:
>
>For other stuff, like print(), instead of using the "currently selected
>filehandle", just always have it print to $STDOUT unless something's
>specified. So:
>
> $oldstdout = $STDOUT;
> $STDOUT = $myfileobject;
> print "Hello, world!"; # always p
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
> 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
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
On Wed, Aug 16, 2000 at 08:27:04PM +, Nick Ing-Simmons wrote:
> Perl6 Rfc Librarian <[EMAIL PROTECTED]> writes:
> >
> >In addition, this RFC recommends deprecating select(), since it is no
> >longer needed with the new fileobject approach described in RFC 14.
> >
> >
> > $oldoutput = select(
Simply Hao <[EMAIL PROTECTED]> writes:
>> But there is no way that I want under, any circumstance, _all_
>> line endings active at the same time.
>
>Why not?
Because native tools won't behave like that and we want to mimic them
(at least as an option).
>
>Well, how about this proposal then?
>
>D
> 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
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
Nathan Wiger <[EMAIL PROTECTED]> writes:
>Admittedly, it does look cooler, but consider this:
>
> open 'http://www.yahoo.com/';
> open 'https://www.etrade.com/';# what module? https?
Yes - if you don't have one it fails "https protocol not found".
>
>No matter what, you're going to h
Perl6 Rfc Librarian <[EMAIL PROTECTED]> writes:
>
>In addition, this RFC recommends deprecating select(), since it is no
>longer needed with the new fileobject approach described in RFC 14.
>
>
> $oldoutput = select($newoutput);
>
>Can now be written simply as reassignments:
>
> $oldoutput = $
Michael Fowler <[EMAIL PROTECTED]> writes:
>On Sat, Aug 12, 2000 at 08:49:00AM -, Perl6 RFC Librarian wrote:
>> In addition, this RFC recommends deprecating select(), since it is no
>> longer needed with the new fileobject approach described in RFC 14.
>
>You should probably mention here that
Peter Scott wrote:
> Redirected to -errors to save a thousand eyeballs.
(I hope I'm on that list; please Cc me if not...)
> > > I find it quite intuitive :-)
> >
> >I note the smiley.
>
> It works without the smiley too.
Then you have the intuition of an Ascended Master.[1]
> > > What inte
At 03:40 PM 8/16/00 -0500, Jonathan Scott Duff wrote:
>Well, those of you writing "exception" RFCs be sure and include this
>example in there somewhere (if it's relevant to your RFC of course).
Done.
>I'm done thinking about exceptions now.
Some of us are hoping to do the same RSN :-)
--
Peter
At 04:59 PM 8/16/00 -0400, John Porter wrote:
> > > > What interpretation should be placed on statements in the try block
> > > > following a catch block?
> > >
> > >Whatever you want. I can think of three possibilities.
> >
> > That's the problem. Only one of them will be right.
>
>Only one of
Peter Scott wrote:
> >Only one of them needs to be right. As long as one is right,
> >there is no problem.
>
> Right, I was just pointing out that it's harder for people to divine which
> one we picked without recourse to the documentation.
Yes; unfortunately, this problem exists generally, es
On Wed, Aug 16, 2000 at 01:16:26AM -0600, Tony Olekshy wrote:
> try { } finally { } catch { }
I don not see ht epoint of this ?
IMO, it should be simple.
try { }
catch Class { }
catch { }
finally { }
If try throws it is caught by the catch blocks
finally is always run
if any of
=head2 eval/die remains perfectly workable
Perl5 has a perfectly agile exception handling method,
C, which syntax-checks at compile time and
returns the value of the value of the last expression
evaluated and sets the special error variables in cases
of errors.
We leave that alone, and use it f
On Wed, Aug 16, 2000 at 12:52:07PM -0700, Peter Scott wrote:
> At 09:29 AM 8/16/00 -0500, Jonathan Scott Duff wrote:
> >Let me draw another picture (with "try" and "catch" this time):
> >
> > try {
> > # code that may cause exceptions
> > } catch {
or AUTOLOAD can be defined in terms of C
and overloaded that way, rather than being its own
kind of magic.
catch "AUTOLOAD-$classname-$polymorphicsignature" {...
Jonathan Scott Duff wrote:
>
> On Wed, Aug 16, 2000 at 12:15:30PM -0500, David L. Nicol wrote:
> > If "catch" can be def
1 - 100 of 341 matches
Mail list logo
