I wrote:
>
>Well I sat down, thought carefully about it, and reorganized
>my proposed license along the same lines that I would organize
>a config file. Instead of enumerating what is allowed, deny
>this, deny that, deny the other, allow everything else. I
>think that this is a good way to rewri
This and other RFCs are available on the web at
http://dev.perl.org/rfc/
=head1 TITLE
Interpolation of method calls
=head1 VERSION
Maintainer: Michael G Schwern <[EMAIL PROTECTED]>
Date: 14 Sep 2000
Mailing List: [EMAIL PROTECTED]
Number: 222
Version: 1
Status: Developing
=head
This and other RFCs are available on the web at
http://dev.perl.org/rfc/
=head1 TITLE
Subroutines: Extend subroutine contexts to include name parameters and lazy arguments
=head1 VERSION
Maintainer: Damian Conway <[EMAIL PROTECTED]>
Date: 17 August 2000
Last Modified: 14 September 2000
This and other RFCs are available on the web at
http://dev.perl.org/rfc/
=head1 TITLE
Data: Superpositions
=head1 VERSION
Maintainer: Damian Conway <[EMAIL PROTECTED]>
Date: 14 September 2000
Mailing List: [EMAIL PROTECTED]
Number: 225
Version: 1
Status: Developing
=head1 ABSTRA
This and other RFCs are available on the web at
http://dev.perl.org/rfc/
=head1 TITLE
Extend the window to turn on taint mode
=head1 VERSION
Maintainer: Adam Turoff <[EMAIL PROTECTED]>
Date: Sep 14 2000
Mailing List: [EMAIL PROTECTED]
Number: 227
Version: 1
Status: Developing
=h
This and other RFCs are available on the web at
http://dev.perl.org/rfc/
=head1 TITLE
Add memoize into the standard library
=head1 VERSION
Maintainer: Adam Turoff <[EMAIL PROTECTED]>
Date: Sep 14 2000
Mailing List: [EMAIL PROTECTED]
Number: 228
Version: 1
Status: Developing
=hea
This and other RFCs are available on the web at
http://dev.perl.org/rfc/
=head1 TITLE
Inline Comments for Perl.
=head1 VERSION
Maintainer: Glenn Linderman <[EMAIL PROTECTED]>
Date: 14 Aug 2000
Last Modified: 14 Sep 2000
Mailing List: [EMAIL PROTECTED]
Number: 102
Version: 2
Sta
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
Last Modified: 14 Sep 2000
Mailing List: [EMAIL PROTECTED]
Number: 119
This and other RFCs are available on the web at
http://dev.perl.org/rfc/
=head1 TITLE
Variable interpolation on demand.
=head1 VERSION
Maintainer: Glenn Linderman <[EMAIL PROTECTED]>
Date: 14 Sep 2000
Mailing List: [EMAIL PROTECTED]
Number: 229
Version: 1
Status: Developing
=hea
On Thu, Sep 14, 2000 at 12:01:03AM -0700, Glenn Linderman wrote:
> > Once extracted, a module can deal with it
> > just as easily, and with much more flexibility, than a core patch to
> > perl can.
>
> Who cleans up all the junk files later?
Nobody does, they're not junk. They go into the t/ di
On Wed, 13 Sep 2000 22:49:14 -0700, Glenn Linderman wrote:
>So who needs a special format type? Just need a string. It becomes a
>format when you use it as such... So just
>
> my $frm = <<'.'
>@<: @
>$name, $ssn
>.
I, for one, can see two problems with this. And I'm not
=head1 TITLE
Interpolation of method calls
=head1 VERSION
Maintainer: Michael G Schwern <[EMAIL PROTECTED]>
Date: 14 Sep 2000
Version:1
Mailing List: [EMAIL PROTECTED]
=head1 ABSTRACT
Method calls should interpolate in double-quoted strings, and similar
locations.
This topic is actually covered, albeit far less in-depth and lumped with an
unrelated change, by Nathan Wiger's RFC 103, just in case you weren't aware.
On Thu, Sep 14, 2000 at 03:57:41AM -0400, Michael G Schwern wrote:
> Methods will be run in scalar context. A method which returns a single sc
I would suggest that anyone want to contribute to this discussion should
first read the thread about the addition of this pragma to perl5 in
the perl5-porters archives
http://www.xray.mpe.mpg.de/cgi-bin/w3glimpse/perl5-porters?query=use+namespace+pragma&errors=0&case=on&maxfiles=100&maxlines=30
On 30 Aug 2000 02:13:38 -, Perl6 RFC Librarian wrote:
>Replace =~, !~, m//, s///, and tr// with match(), subst(), and trade()
Why?
What's next, replace the regex syntax with something that more closely
ressembles the rest of Perl?
Regexes are a language within the language. And not a tiny
- Original Message -
From: "Dan Sugalski" <[EMAIL PROTECTED]>
>
> >If more speed is needed, make the part that's currently too slow
> >_simpler_, not _more_complex_.
>
> I think you'll find it rather more useful to make the part that's
currently
> too slow *faster*, rather than more or les
At 0:12 -0400 2000.09.14, Chaim Frenkel wrote:
>Possibly a few functions to make it easy.
>
>$Perl::EpochOffset
>
> 0 on a unix box
> 966770660 on a Mac (Lifted from pudge's previous email)
> etc.
>
>Then on output. print time()-$Perl::EpochOffset;
No, that w
Chaim Frenkel <[EMAIL PROTECTED]> writes:
> "AD" == Andy Dougherty <[EMAIL PROTECTED]> writes:
>AD> In my humble opinion, I think perl's time() ought to just call the C
>AD> library's time() function and not waste time mucking with the return
>AD> value. Instead, if the time is to be stored e
Nathan Wiger <[EMAIL PROTECTED]> writes:
> Nathan Torkington wrote:
> >
> > Yes! I mentioned the hypothetical
> > use strict 'types';
> > which would require all variables assigned to/from an object, and
> > all variables upon which method calls are made, to be typed like
> > this. Then the
Michael G Schwern <[EMAIL PROTECTED]> writes:
> On Wed, Sep 13, 2000 at 08:43:43PM -, Perl6 RFC Librarian wrote:
> > The behaviour of the syntax should simply be an
> > assertion of the invariant:
> >
> >(!defined($spot) || (ref($spot) && $spot->isa('Dog)))
>
> What about the current
Graham Barr <[EMAIL PROTECTED]> writes:
> I would suggest that anyone want to contribute to this discussion should
> first read the thread about the addition of this pragma to perl5 in
> the perl5-porters archives
>
>
>http://www.xray.mpe.mpg.de/cgi-bin/w3glimpse/perl5-porters?query=use+namespa
Perl6 RFC Librarian <[EMAIL PROTECTED]> writes:
> This and other RFCs are available on the web at
> http://dev.perl.org/rfc/
>
> =head1 TITLE
>
> C is just an assertion
>
> =head1 VERSION
>
> Maintainer: Piers Cawley <[EMAIL PROTECTED]>
> Date: 13th September 2000
> Mailing List: [EMA
Nathan Torkington <[EMAIL PROTECTED]> writes:
> Perl6 RFC Librarian writes:
> > I therefore propose that C comes to mean that C<$spot>
> > is restricted to being either undefined or a reference to a C
> > object (or any subclasses of Dog). Simply having this implicit
> > assertion can be useful t
Simon Cozens <[EMAIL PROTECTED]> writes:
> On Tue, Sep 12, 2000 at 03:17:47PM -0400, Ken Fox wrote:
> > That's fine for the VM and the support libraries, but I'd *really*
> > like to see the parser/front-end in Perl. There are dozens of RFCs
> > that require some non-trivial extensions to the par
On Thu, Sep 14, 2000 at 02:40:31PM +0100, Piers Cawley wrote:
> > Are there any better reasons than "It would be nice?"
>
> Can there *be* a better reason than "It would be nice"? Seriously,
> niceness is a damned fine goal.
No, it isn't. Practical wins over nice any day. Fast probably wins over
Andy Dougherty <[EMAIL PROTECTED]> writes:
On Thu, 14 Sep 2000, Charles Lane wrote:
>> On at least some non-Unix systems, the time() function is itself an attempt
>> to emulate Posix functionality...note that I say "attempt". And also note
>
>Do you mean that the following program might not print
At 11:01 -0400 2000.09.14, Andy Dougherty wrote:
>On Thu, 14 Sep 2000, Chris Nandor wrote:
>
>> There's also the possibility of time accepting an argument, where 0 would
>> be perl's time and 1 would be native time, or something.
>
>Now that's a clever idea. Hmm. I think I like it as a solution
At 11:05 -0400 2000.09.14, Philip Newton wrote:
>You have another assumption up there: that time_t == signed long (since
>you're printing it with %ld) with a resolution of seconds (since you say
>"%ld seconds"). ISO/IEC 9899:1999 (draft C standard, the only C standard-y
True. In Mac OS, time_t i
At 11:15 -0400 2000.09.14, Charles Lane wrote:
>I've been in the Epoch !=0 mode and it sucked. I vote for Epoch=0 as
>the default.
Well, Perl is about making things easy. What is the most common case,
needing an arbitrary value of time that may or may not be used to transfer
between platforms,
On Thu, 14 Sep 2000, Charles Lane wrote:
> From the perspective of a non-Unix user that has been fighting this battle
> for a few years now, you can't just take the C library time() on all systems.
Sorry, I don't know what that sentence means.
> On at least some non-Unix systems, the time() f
At 10:08 -0400 2000.09.14, Andy Dougherty wrote:
>This is not a simple either-or. Suppose you are using a Mac and that
>perl6 decides to use the Unix epoch. Suppose you want to communicate with
>other Mac programs or library functions about time (e.g. perhaps by
>calling things through the XS in
On Thu, 14 Sep 2000, Chris Nandor wrote:
> There's also the possibility of time accepting an argument, where 0 would
> be perl's time and 1 would be native time, or something.
Now that's a clever idea. Hmm. I think I like it as a solution to the
specific issue at hand better than the proposed
On Thu, 14 Sep 2000, Andy Dougherty wrote:
> Do you mean that the following program might not print '5' (well, about 5,
> given sleep's uncertaintites ...)
>
> #include
> #include
> #include /* May need sys/time.h instead */
> int main(void)
> {
>time_t start,
Jarkko Hietaniemi wrote:
> > In the other camp, C has been suggested; but
> > the conflation of that with its thread-related semantics may not
> > be a such good idea.
>
> C.
Well, "pass" might be o.k.; but it usually means something going
*into* a sub, not coming out...
--
John Porter
Eric Roode wrote:
>
> sub func1
> {
> func2();
> }
>
> sub func2
> {
> last func1;
> }
>
> ? Imho, it is a BAD THING for functions to know who called them,
> and to vary their behavior accordingly.
Yes. This is a serious downside to the propos
On Thu, Sep 14, 2000 at 11:46:31AM -0400, 'John Porter' wrote:
> Jarkko Hietaniemi wrote:
> > > In the other camp, C has been suggested; but
> > > the conflation of that with its thread-related semantics may not
> > > be a such good idea.
> >
> > C.
>
> Well, "pass" might be o.k.; but it usually
Garrett Goebel wrote:
>
> * Subroutines automatically get their name as a label
My concern here is whether it introduces a problem with C
vs. C. If, as you propose, subs do get their name as label,
I would like to conflate these two forms. But the semantics of
C specifies that @_ is passed as
> =head1 TITLE
>
> crypt() default salt
>
> =head1 VERSION
>
> Maintainer: Mark Dominus <[EMAIL PROTECTED]>
> Date: 11 Sep 2000
> Last Modified: 13 Sep 2000
> Mailing List: [EMAIL PROTECTED]
> Number: 208
> Version: 2
> Status: Developing
If there are no objections, I will freez
David L. Nicol wrote:
> "Randal L. Schwartz" wrote:
> >
> > I think we need a distinction between "looping" blocks and
> > "non-looping" blocks. And further, it still makes sense to
> > distinguish "blocks that return values" (like subroutines and map/grep
> > blocks) from either of those. But
> David L. Nicol wrote:
> > "Randal L. Schwartz" wrote:
> > >
> > > I think we need a distinction between "looping" blocks and
> > > "non-looping" blocks. And further, it still makes sense to
> > > distinguish "blocks that return values" (like subroutines and map/grep
> > > blocks) from either o
David L. Nicol wrote:
> "Randal L. Schwartz" wrote:
> >
> > I think we need a distinction between "looping" blocks and
> > "non-looping" blocks. And further, it still makes sense to
> > distinguish "blocks that return values" (like subroutines
> > and map/grep blocks) from either of those. But
Garrett Goebel wrote:
>Could someone shoot down or prop up the following:
>
>* Subroutines automatically get their name as a label
Ick! Shades of Pascal! Why don't we just replace "return $value"
with "subroutine_name = $value;"!
Seriously, what is the point of
sub func1
{
func
> This topic is actually covered, albeit far less in-depth and lumped with an
> unrelated change, by Nathan Wiger's RFC 103, just in case you weren't aware.
Yeah, I've got to split those up. I was trying cut down on the flood of
RFC's that poor Larry has to sift through :-(, but they are both com
Nathan Wiger wrote:
>
> > use namespace 'Big::Long::Prefix';
> > my ::Class $object = ::Class->new;
>
> Assuming repairing :: precedence is a reality I don't think this
> proposal buys us anything.
...That being said, I'm not necessarily against it. I'm
just against bloat. I hadn't paid
> What's next, replace the regex syntax with something that more closely
> ressembles the rest of Perl?
No.
> Regexes are a language within the language. And not a tiny one.
I know... :-)
> So, if regexes are such a completely different sublanguage, I can see
> the m// and s/// syntax as just
On Thu, 14 Sep 2000, Chris Nandor wrote:
> Well, Perl is about making things easy. What is the most common case,
> needing an arbitrary value of time that may or may not be used to transfer
> between platforms, or needing a value of time that is specific to a given
> platform?
> And I can
At 11:59 -0400 2000.09.14, Andy Dougherty wrote:
>On Thu, 14 Sep 2000, Chris Nandor wrote:
>
>> Well, Perl is about making things easy. What is the most common case,
>> needing an arbitrary value of time that may or may not be used to transfer
>> between platforms, or needing a value of time that
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
Nathan Wiger wrote:
> I think this is a definite possibility:
>
>$FH = open scalar $myvar;
>print $FH "stuff";
>
> Then the scalar handler would just have to provide the necessary print()
> et al methods to do scalar manipulation. Theoretically this can be done
> modularly, without havi
'John Porter' wrote:
>
> David L. Nicol wrote:
> > "Randal L. Schwartz" wrote:
> > >
> > > I think we need a distinction between "looping" blocks and
> > > "non-looping" blocks. And further, it still makes sense to
> > > distinguish "blocks that return values" (like subroutines and map/grep
> >
At 10:52 AM 9/14/00 -0700, Nathan Wiger wrote:
>Actually, to me this thread underscores how broken here docs are
>themselves. We already have q//, qq//, and qx// which duplicate their
>functions far more flexibly. Question: Do we really need here docs?
I have thought this before, but I think the
This whole debate has got silly.
RFC 111 V1 covered both the whitespace on the terminator and the
indenting - there was a lot of debate that this was two things - more were
in favour of the terminator and there was more debate on the indenting.
Therefore I split this into two RFCs leaving RFC111
Nathan Wiger wrote:
>Actually, to me this thread underscores how broken here docs are
>themselves. We already have q//, qq//, and qx// which duplicate their
>functions far more flexibly. Question: Do we really need here docs?
Yes.
Try generating lots of HTML, Javascript, Postscript, or other
lan
David L. Nicol wrote:
>
> This ability to jump to "the right place" is exactly what exception handling
> is for, as I understand it. Exceptions allow us to have one kind of block
> and any number of kinds of exit mechanisms. If qC(last die return) are all
> excpetions, the can travel up the call
From: John Porter [mailto:[EMAIL PROTECTED]]
> Eric Roode wrote:
> >
> > sub func1
> > {
> > func2();
> > }
> >
> > sub func2
> > {
> > last func1;
> > }
> >
> > ? Imho, it is a BAD THING for functions to know who called them,
> > and to vary the
Richard Proctor made some excellent comments, and asked:
>When measuring whitespace how does the system treat tabs? (be realistic
>and dont FLAME)
I suggest that there be NO tab/space conversion. Not 8 columns, not
4 columns, nothing. If the here doc terminator has four tabs preceding
it, then f
On 14 Sep 2000, Ariel Scolnicov wrote:
> 1. It requires the perl parser know about indentation. Of course we
>all know that tabs are 8 characters wide (I myself make a point of
>bludgeoning anyone who says otherwise), but do we really want to
>open this can of worms?
No, b
> Show me where this fails and I'll shut up about it.
Actually, to me this thread underscores how broken here docs are
themselves. We already have q//, qq//, and qx// which duplicate their
functions far more flexibly. Question: Do we really need here docs?
Before you scream "Bloody murder", pleas
On Wed, 13 Sep 2000, Nathan Torkington wrote:
> Simon Cozens writes:
> > > Nice!
> > Efficient!
> > Practical!
> >
> > Choose two.
>
> I take this oblique comment to mean that it'd bloat the op-tree too
> much?
Well, suppose we simply add the -FOO (choose your letter) flag to
perl...
Ben Tilly <[EMAIL PROTECTED]> writes:
>Well I sat down, thought carefully about it, and reorganized
>my proposed license along the same lines that I would organize
>a config file. Instead of enumerating what is allowed, deny
>this, deny that, deny the other, allow everything else. I
>think that
Nick Ing-Simmons wrote:
>
>Ben Tilly <[EMAIL PROTECTED]> writes:
> >Well I sat down, thought carefully about it, and reorganized
> >my proposed license along the same lines that I would organize
> >a config file. Instead of enumerating what is allowed, deny
> >this, deny that, deny the other, all
Michael G Schwern <[EMAIL PROTECTED]> writes:
>
>print "Today's weather will be $weather->temp degrees and sunny.";
>
>This does not DWIM. Instead of interpolating C<$weather->temp> as a method
>call, it comes out as C<$weather.'->temp'> and is usually followed immediately
>by the questio
Piers Cawley writes:
> TBH, I'm not sure I want to go too far down that road in this RFC. And
> tbh they seem more like internals issues to me. The runtime behaviour
> this change grants is good enough for me and I don't want to see the
> proposal bogged down in flamage about strict types. Of cour
Alan Burlison wrote:
>
> Adam Turoff wrote:
>
> > It would have been nicer to institute this policy from the start,
> > but no one expected to get 200 RFCs in just over one month, either.
>
> Indeed - I think everyone was astonished by the rate at which they
> appeared. I just hope the code is
Steve Fink writes:
> I just don't know if I'd bother to switch to Perl6 for a 10% speedup
Speed will *not* be the only reason to switch to perl6. It will (might)
have:
- bytecode compilation
- compile-time checking
- a rational stdlib
- vastly simpler extension mechanism
You can focus on an
From: Wordsmith <[EMAIL PROTECTED]>
Subject: A.Word.A.Day--GIGO
To: [EMAIL PROTECTED]
GIGO (GI-goh) noun
1. `Garbage In, Garbage Out' -- usually said in response to lusers who
complain that a program didn't "do the right thing" when given
imperfect input or otherwise mistreated i
> > > 1.Benchmarks of text processing programs show improved performance on
> > perl6 over perl5.
> >
> > Yes, but how much improved? Is 50% in everyone's minds, or is 10%
> > enough? How much improvement is feasible?
>
> As a first approximation to what is realistic, I'm going to put 10%
Steve Fink writes:
> I just wonder if a 10% improvement on some benchmark is worth writing a
> new language for. A 100% improvement on a single "representative
> real-world task" would be a lot more persuasive. But much more
> convincing would be allowing perl to be embedded as a scripting languag
Nathan Torkington wrote:
>
> And there's no law that says some areas can't run *faster* than 10%.
"...where all the children are above average.". 10% across the board
demands that, unless you overclock by 10%. :-)
> But I think we have to be realistic. We all want a programming
> language that
arrays-of-scalars
Reply-To: [EMAIL PROTECTED]
This and other RFCs are available on the web at
http://dev.perl.org/rfc/
=head1 TITLE
Standard support for opening i/o handles on scalars and
arrays-of-scalars
=head1 VERSION
Maintainer: Eryq (Erik Dorfman) <[EMAIL PROTECTED]>
Date: 23 Aug 2
This and other RFCs are available on the web at
http://dev.perl.org/rfc/
=head1 TITLE
STDIN, STDOUT, STDERR, ARGV, and DATA should become scalars
=head1 VERSION
Maintainer: Nathan Wiger <[EMAIL PROTECTED]>
Date: 04 Aug 2000
Last-Modified: 14 Sep 2000
Mailing List: [EMAIL PROTECTED]
On Thu, Sep 14, 2000 at 12:15:28PM -0700, Glenn Linderman wrote:
> 1) why extract it if it could potentially be used in place
> 2) if it cannot be used in place, then why bundle it
>
> So I guess RFC 183 leaves me not understanding its goals. If there
> is a benefit to the bundling, then RFC 183
Glenn Linderman wrote:
>
> 1) why extract it if it could potentially be used in place
> 2) if it cannot be used in place, then why bundle it
I tend to agree. If they're stored as podified sections, and
get extracted to files, then pod has merely been (mis-)used as
some kind of shar.
If the t
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)
>
>
Michael,
Thanks for the explanation. So you see, I'm one of those people that go around
looking for redundancies to eliminate. So when I hear that you want to extract
a .t file from perl source (as specified by the RFC 183), it makes me wonder
1) why extract it if it could potentially be used
Bart Lateur wrote:
> On Wed, 13 Sep 2000 22:49:14 -0700, Glenn Linderman wrote:
>
> >So who needs a special format type? Just need a string. It becomes a
> >format when you use it as such... So just
> >
> > my $frm = <<'.'
> >@<: @
> >$name, $ssn
> >.
>
> I, for one, can
On Thu, 14 Sep 2000 08:47:24 -0700, Nathan Wiger wrote:
>One thing to remember is that regex's are already used in a number of
>functions:
>
> @results = grep /^VAR=\w+/, @values;
You are being mislead. You might just as well say that length() is being
used in other functions:
@result
On 13 Sep 2000 14:22:30 -0700, Russ Allbery wrote:
>I think it should be specified that the return value is seconds since Unix
>epoch and the storage size be left unspecified, from the language
>perspective. On those platforms that support it, using 64 bits is
>obviously a good idea.
64 bits is
This and other RFCs are available on the web at
http://dev.perl.org/rfc/
=head1 TITLE
Objects should have builtin stringifying STRING method
=head1 VERSION
Maintainer: Nathan Wiger <[EMAIL PROTECTED]>
Date: 06 Aug 2000
Last Modified: 14 Sep 2000
Mailing List: [EMAIL PROTECTED]
This and other RFCs are available on the web at
http://dev.perl.org/rfc/
=head1 TITLE
Interpolation of method calls
=head1 VERSION
Maintainer: Michael G Schwern <[EMAIL PROTECTED]>
Date: 14 Sep 2000
Mailing List: [EMAIL PROTECTED]
Number: 222
Version: 1
Status: Developing
=head
First of all, I think this is a great idea
On 14 Sep 2000, Perl6 RFC Librarian wrote:
> Are there any contexts besides double quotes ("", qq{}, <<"EOF") where this
> need be applied? What about inside regexes? And if so, left and/or right
> hand side?
Regexes are enough like double quoted str
This and other RFCs are available on the web at
http://dev.perl.org/rfc/
=head1 TITLE
Objects : Hierarchical calls to initializers and destructors
=head1 VERSION
Maintainer: Damian Conway <[EMAIL PROTECTED]>
Date: 1 September 2000
Mailing List: [EMAIL PROTECTED]
Number: 189
Version
On Thu, Sep 14, 2000 at 07:49:32AM -0700, Nathan Wiger wrote:
> > > print 'Today\'s weather will be '.join($", $weather->temp()).
> > > ' degrees and sunny.';
> > >
> > > However if temp() calls wantarray(), the result will be FALSE (scalar).
>
> I think what he's trying to get at i
This and other RFCs are available on the web at
http://dev.perl.org/rfc/
=head1 TITLE
Objects : Rationalizing C, C, and C
=head1 VERSION
Maintainer: Damian Conway <[EMAIL PROTECTED]>
Date: 14 September 2000
Mailing List: [EMAIL PROTECTED]
Number: 224
Version: 1
Status: Developing
Piers wrote:
> I'm kind of tempted to look at adding another pragma to go with 'use
> base' along the lines of:
>
> use implements 'Interface';
>
> Which is almost entirely like C but with
> 'Interface' consisting of nothing but:
>
>
> package Interfac
On Thu, Sep 14, 2000 at 02:19:38PM +0100, Piers Cawley wrote:
> Michael G Schwern <[EMAIL PROTECTED]> writes:
> > package Dog;
> > use fields qw(this night up);
> >
> > my Dog $ph = [];
> > $ph->{this} = "that";
>
> That works? I thought you had to do:
>
> my Dog $self = f
This and other RFCs are available on the web at
http://dev.perl.org/rfc/
=head1 TITLE
Interpolation of method calls
=head1 VERSION
Maintainer: Michael G Schwern <[EMAIL PROTECTED]>
Date: 14 Sep 2000
Mailing List: [EMAIL PROTECTED]
Number: 222
Version: 1
Status: Developing
=head
Ben Tilly wrote:
> The Perl6 RFC Librarian quoth:
> >
> >This and other RFCs are available on the web at
> > http://dev.perl.org/rfc/
> >
> >=head1 TITLE
> >
> >Perl6's License Should Be a Minor Bugfix of Perl5's License
> [...]
> This resolves very few of the IMHO rather serious issues I have
Bradley M. Kuhn wrote:
>
>Ben Tilly wrote:
>
> > >I believe that is correct as well.
> >
> > Is subset really the word? Should I choose to accept and redistribute
> > using the AL, I should be able to distribute under any terms I choose
>that
> > are consistent with the distribution requirements
Nick Ing-Simmons wrote:
> Bradley M . Kuhn <[EMAIL PROTECTED]> writes:
> >
> >(Think of it as writing a Last Will and Testament---you can do it on your
> > own in a pinch, but it's always better to write a draft and then have a
> > lawyer help you rewrite it so it's more legally sound, because it
bkuhn wrote:
> >law,
> >and it isn't worth putting statements like this in licenses. They are
> >unenforceable through copyright law, and thus
Ben Tilly wrote:
> I borrowed it from both the BSD and the GPL. Even if it is
> unenforcable, it is likely to discourage people from abusing
> that.
Ben Tilly wrote:
> >I believe that is correct as well.
>
> Is subset really the word? Should I choose to accept and redistribute
> using the AL, I should be able to distribute under any terms I choose that
> are consistent with the distribution requirements of the AL. This may
> include adding
> Bradley M . Kuhn <[EMAIL PROTECTED]> writes:
> >I don't think this is completely out the question, either. I was actually
> >planning on writing an RFC that proposes that all contributions to the core
> >be copyright assigned to Larry.
Nick Ing-Simmons wrote:
> Well if that becomes a require
Nathan Torkington <[EMAIL PROTECTED]> writes:
>Dan Sugalski writes:
>> It's possible, for example, for a tied/overloaded/really-darned-strange
>> variable to look true but still be false. If you do:
>>
>>$foo = $bar || $baz;
>>
>> and both $bar and $baz are objects, the 'naive' way is to ma
This and other RFCs are available on the web at
http://dev.perl.org/rfc/
=head1 TITLE
Exception objects and classes for builtins
=head1 VERSION
Maintainer: Peter Scott <[EMAIL PROTECTED]>
Date: 9 Aug 2000
Last Modified: 14 Sep 2000
Mailing List: [EMAIL PROTECTED]
Bradley M. Kuhn wrote:
>
>
>bkuhn wrote:
> > >law,
> > >and it isn't worth putting statements like this in licenses. They are
> > >unenforceable through copyright law, and thus
>
>Ben Tilly wrote:
>
> > I borrowed it from both the BSD and the GPL. Even if it is
> > unenforcable, it is likely to
Perl6 RFC Librarian (aka Damian Conway) wrote:
> This RFC (seriously) proposes Perl 6 provide C and C operators,
> and, thereby, conjunctive and disjunctive superpositional types.
>
Great to see this RFC'd--this will makes lots of data crunching code _way_
easier.
Now, I haven't quite finished re
This and other RFCs are available on the web at
http://dev.perl.org/rfc/
=head1 TITLE
Proposed syntax for matrix element access and slicing.
=head1 VERSION
Maintainer: Buddha Buck <[EMAIL PROTECTED]>
Date: 29 August 2000
Last Modified: 14 September 2000
Mailing List: [EMAIL PROTE
> "CN" == Chris Nandor <[EMAIL PROTECTED]> writes:
CN> No, that won't really work. When my offset from GMT changes for daylight
CN> savings time, it will break. The point of having a module is that epoch
CN> conversions are more complicated than that. For example, Mac OS epoch
CN> begins a
Philip Newton <[EMAIL PROTECTED]> writes:
> You have another assumption up there: that time_t == signed long (since
> you're printing it with %ld) with a resolution of seconds (since you say
> "%ld seconds"). ISO/IEC 9899:1999 (draft C standard, the only C
> standard-y thing I have around) says t
1 - 100 of 175 matches
Mail list logo
