Peter Scott wrote, in RFC 63 (v2):
This RFC is very similar to RFC 88, which has slightly different
syntax and adds functionality for adding exceptions to a stack.
While this author considers that to be going a bit too far (he's
tried it before and found he never made use of anything under
At 9:45 -0700 2000.08.12, Nathan Wiger wrote:
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
On Sat, Aug 12, 2000 at 10:27:17PM -0400, Dan Sugalski wrote:
At 10:24 PM 8/12/00 -0400, Chaim Frenkel wrote:
"NW" == Nathan Wiger [EMAIL PROTECTED] writes:
NW just deal with filenames universally this would be a big win (leave
NW acls, permissions, versions, etc to something else).
Couldn't:
my $u = User.new('abw', 'Andy Wardley', '[EMAIL PROTECTED]');
just be
my $u = User-new('abw', 'Andy Wardley', '[EMAIL PROTECTED]');
And:
$foo.bar.baz = 10;
Just be:
$foo::bar::baz = 10;
Yes, but the semantics change. A key feature of this proposal is that
Subject: RFC 90 (v1) Builtins: zip() and unzip()
I just don't like the name zip(), unzip() - shold be saved for something
that will really do commpression.
Variants : combine
I like merge too..
As of this it will be good if there some sort of compression internally
by the perl, say for
what about (not zip() offcource :")):
@a = (1,2,3);
@b = (4,5,6);
@c = (7,8,9);
zip (how,@a,@b,@c);
i.e.
@list = zip (0,@a,@b,@c); #stright
result (1,2,3,4,5,6,7,8,9)
@list = zip (1,@a,@b,@c); #reverse
result (7,8,9,5,6,7,1,2,3)
@list = zip(2,@a,@b,@c); # all first elems, then all
Sorry that read this later...
It is one step from matrix to create SQL syntax :")
if we have MATRIX operations what about adding a conditions to it.. i.e. :
@a = (1,2,3);
@b = (4,5,6);
@c = (7,8,9);
matrix x3, @a, @b, @c where x3 5;
( 1,2,3
4,5,6
7,8,9 );
x3 in where mean column 3
Andy ~
Since you didn't mention it in your references, you may want to
check out RFC 92, Extensible Meta-Object Protocol -- Method Search
at http://tmtowtdi.perl.org/rfc/92.pod
RFC 92 considers an existing Perl 5 module we have that allows
us to write code like the following, and it considers
Peter Scott wrote, in RFC 80 (v2):
=item id
Unique numeric identifier, assigned by perl developers.
I'm loath to bother everyone with this, but to me the id of an
object should be unique to each *instance* of the class. If we had
my $e = Exception-New(id = "ABC.1234");
my $f =
"Perl6" == Perl6 RFC Librarian [EMAIL PROTECTED] writes:
Perl6 Perl should be modified so that if C$ISA::Search (or equivalent)
Do you mean "$YOUR_PACKAGE::ISA::Search"
which is in the package "YOUR_PACKAGE::ISA"?
This would be the first time (to my knowledge) that something would
be in an
I'm still saving the proposal for further digestion, but wanted
to get this out quickly:
"Perl6" == Perl6 RFC Librarian [EMAIL PROTECTED] writes:
Perl6 The existing Cnew keyword can be used to create new object instances
Perl6 of a given class.
There is no existing "new" keyword in Perl.
I simply can't get over the feeling that the proposed
zip/unzip/partition functions are far too specialized/simple, and that
something more general-purpose in the order of pack/unpack (with the
transformation spec encoded in a template) for lists would be preferable.
When someone said that
On Fri, 11 Aug 2000, Nathan Wiger wrote:
Philip Newton wrote:
So if we're now on 1-indexing, we'll see lots of @months = (undef, 'Jan',
'Feb') or qw(dummy Jan Feb)... oh well.
Far better, use the new builtin object methods:
$d = date;
print "today is ", $d-date('%A'); # Friday
* Philip Newton ([EMAIL PROTECTED]) [13 Aug 2000 04:10]:
On Fri, 11 Aug 2000, Nathan Wiger wrote:
Philip Newton wrote:
So if we're now on 1-indexing, we'll see lots of @months = (undef, 'Jan',
'Feb') or qw(dummy Jan Feb)... oh well.
Far better, use the new builtin object methods:
To nick some pits
On Fri, 11 Aug 2000, Nathan Wiger wrote:
Here is the justification. As most people write dates, they write
something like this:
1/20/1976 2:34:02
4/5/981 11:05:09
Very few people I've met write dates like this habitually in the real
world:
01/20/1976
Since you didn't mention it in your references, you may want to
check out RFC 92, Extensible Meta-Object Protocol -- Method Search
at http://tmtowtdi.perl.org/rfc/92.pod
I saw it after I posted the RFC. Yes, this is exactly the kind
of support that we need in the core to allow us to do
On Fri, 11 Aug 2000, Nathan Wiger wrote:
To me, the real question is which date() should we use:
$date = date $seconds_since_epoch; # uses time()
$date = date $modified_julian_date; # non-Unix
If we can make it work, the second one seems a lot more
platform-independent. After
On Thu, Aug 10, 2000 at 05:11:17PM +0100, Graham Barr wrote:
I was more thinking of
eval {
# fragile code
}
else {# catch ALL exceptions
switch ($@) {
case __-isa('IO') { ... }
case
Notice that the hours/mins are always padded but the rest isn't.
I think you meant minutes/seconds.
Yep, oops. Thanks.
if you're going to have an object interface, perhaps the constructor
can take the strftime string for use as the default scalar output?
That's exactly what happens:
Philip Newton wrote:
$'bar = 'unchanging'; # klingon?
Has there ever been an RFC discussing retention or deletion of this
backwards-compatibility feature?
Yes. :) RFC71, which caused much grief to Damian: Now he will never be
able to port his new Klingon.pm to Perl 6.
$pkg'var!
On Fri, Aug 11, 2000 at 04:53:01PM -0500, Jarkko Hietaniemi wrote:
On Fri, Aug 11, 2000 at 04:48:12PM -0500, David L. Nicol wrote:
It's a vast and contrived joke, right?
If it is, someone has really gone into some trouble:
http://www.cobolscript.com/samples.htm
Looks real to me, but
Jarkko Hietaniemi wrote:
I simply can't get over the feeling that the proposed
zip/unzip/partition functions are far too specialized/simple,
That's certainly a possibility. They are such common operations though, it
might be a win to build them in. With zip/unzip/partition and good array
This and other RFCs are available on the web at
http://dev.perl.org/rfc/
=head1 TITLE
Deep Copying, aka, cloning around.
=head1 VERSION
Maintainer: Peter Scott [EMAIL PROTECTED]
Date: 8 Aug 2000
Last-Modified: 12 Aug 2000
Version: 2
Mailing List: [EMAIL PROTECTED]
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: 12 Aug 2000
Version: 2
Mailing List: [EMAIL
With zip/unzip/partition
I really gotta say, those functions *need* to be renamed, for a variety
of reasons. First, they have well-established computer meanings
(compression, disks). Second, "partition" is too long anyways.
I've seen numerous emails from other people saying the same thing. If
Dan Sugalski writes:
I don't mind if someone overrides the vtable functions for a variable of a
built-in type--a standard declaration of:
my $foo;
is really shorthand for:
my generic_scalar $foo;
more or less. If a variable gets its vtable functions messed with, well,
that's OK.
At 12:48 PM 8/13/00 +1000, Jeremy Howard wrote:
Dan Sugalski writes:
I don't mind if someone overrides the vtable functions for a variable of a
built-in type--a standard declaration of:
my $foo;
is really shorthand for:
my generic_scalar $foo;
more or less. If a
At 12:23 PM 8/12/00 -0700, Larry Wall wrote:
Dan Sugalski writes:
: Yup. It's an issue for things that implement any non-standard semantics for
: existing ops, especially if those ops are overridden at runtime so the
: optimizer doesn't know. It's one thing to mess with tied variables, its
:
28 matches
Mail list logo
