And the advantage of that over
@hash{ grep /^[^_]/, keys %hash }
would be what? Brevity?
Yes.
Damian
Steve Simmons wrote:
In all the straining at gnats over whitespace, filtering, etc, I have yet
to see a single proposal that isn't accomplished by just using variables
and manipulating them appropriately. And it avoids all the problems with
whitespace on the HERE word.
In many cases, I agree
Hi,
I have couple of ideas which may or may not worth it, so I didn't
wrote the RFC but will list them here in short.
Here are the nice to have'it.
1. There will be good to have some sort of "match and/or assign" operator
for structures i.e. HASHES. Can't still figure out the syntax but may be
Lightning flashed, thunder crashed and "Ed Mills" [EMAIL PROTECTED] whispe
red:
| So we establish a var $something=n where n is the array origin.
You mean something like $[, which we've had for many, many years. And
which for many, many years we've discouraged the use of?
$[ The
Hey Raptor et al:
Wow you did some homework! Nice ideas, but the consensus seems to be "roll
your own". I've noted that opertors working on arrays are generally
discouraged in favor of scalar ops in these discussions, so for example your
(min,max) (ceiling, floor) are coded thousands of times
I think it would be a good thing for user prototypes to be able to
handle this case and I wholeheartedly support the RFC; but it opens
a can of worms that should be addressed. Perhaps in another RFC. Do
any other (Damian) RFCs on (Damian) prototyping impact (Damian)
this area?
On Mon, Aug 28, 2000 at 05:39:20PM -, Perl6 RFC Librarian wrote:
=head1 TITLE
Less line noise - let's get rid of @%
...
I withdrew it on 28th August as I figured I had lost the
argument!
I'm sorry, but this just doesn't jive with me. There is no "argument".
We are discussing
At 07:32 PM 8/27/00 +, Perl6 RFC Librarian wrote:
=head2 Prototypes
Currently, several built-ins do not provide prototype information.
prototype("CORE::abs") == ;$
prototype("CORE::shift") == undef
This must be fixed. One might even call this a bug, although the
current
Object-oriented features were added to Perl with version 5, and in many
ways still appear somewhat "tacked on", with perhaps undue respect
for the Old Ways of Perl 4.
[NB: This is not a serious missive.]
Hey, that Perl uses packages for classes, subroutines for methods, and
references for
"Randy J. Ray" wrote:
# These are pretty cool...
foreach (@old) { @new = subst /hello/X/gi, @old;
s/hello/X/gi;
push @new, $_;
}
This implies that the subst keyword would *both* modify LIST in-place and
return a complete copy of the list as a
On Mon, Aug 28, 2000 at 04:10:01PM -0400, Eric Roode wrote:
Peter Scott wrote:
Graham Barr once allowed as how he thought it would be neat if you could say
for my($x, $y, $z) (@list) { ... }
ObLanguageMinimalist:
Um. Is this so frequently-used that the above syntax is preferable
This is a bit limiting.
I'd offer a more flexible approach. We should be able to represent
any packed structure. We should be able to handle anything that an
pack/unpack format can currently handle. Except that the data does
not have to be moved out into an array/hash.
This might fit in with
Well, $hash{/re/} would only evaluate to a single scalar.
More likely, you'd want @hash{/re/}, which would be
equivalent to @hash{ grep { /re/ } keys %hash }.
I have a draft RFC that proposes that the LIST argument of a
grep be optional in a hash slice, and default to the key list
On 8/28/00 2:35 PM, Tom Christiansen wrote:
Object-oriented features were added to Perl with version 5, and in many
ways still appear somewhat "tacked on", with perhaps undue respect
for the Old Ways of Perl 4.
[NB: This is not a serious missive.]
Hey, that Perl uses packages for
Damian Conway wrote:
I have a draft RFC that proposes that the LIST argument of a
grep be optional in a hash slice, and default to the key list
of the sliced hash. So:
@hash{grep /^[^_]/}
gives you the public values of %hash.
And the advantage of that over
@hash{ grep /^[^_]/,
Peter Scott wrote:
Tony Olekshy wrote:
So if open, for example, can set $! without invoking die, then
$! and $@ must not be merged. As I read it, 151 would (as
currently promulgated) not meet my requirement for the unique
nature of a $@-style variable. I don't think overloading
Buddha Buck wrote:
I think the better way is to take Buddha's idea (soon to be RFC'ed, by
the sounds of it), and make current arrays a little more flexible. It
sounds like we'll just have to add an extra dimension somehow, and then
"arrays of compact arrays" will simply be "arrays with
Jeremy Howard wrote:
Basically, I want to be able to create a list ref of list refs, specify a
data type (eg 'int') and attributes of ':compact' or ':sparse', and have the
As Dan Sugalski suggested it seems not a good idea to bring in the list
of list ref into the proposal. Why does it have
I can currently overload + * to do this, but not . That's broken.
Hm I don't recall C++ ever thinking to overload the control-flow
operators ("", "||", "," (that is, comma), and "?:"). Why not?
Even if their "a b" should produce a more mundane 1 or 0, one
still might wish control.
What about
sub somename : method (@args) {...}
And leaving your$self some other way at the object?
That's the idea. By default you get the invocant in $_[0],
but you can have the compiler extract it for you via Cuse invocant.
Then you get to choose your access mechanism
"DLN" == David L Nicol [EMAIL PROTECTED] writes:
DLN What if every subroutine tagged itself with a list of the globals
DLN it uses, so a calling routine would know to add those to the list
DLN of globals it wants locked?
And what about all the subroutines _it_ will call? And if you solve
that
Chaim Frenkel wrote:
"DLN" == David L Nicol [EMAIL PROTECTED] writes:
DLN What if every subroutine tagged itself with a list of the globals
DLN it uses, so a calling routine would know to add those to the list
DLN of globals it wants locked?
And what about all the subroutines _it_
On Mon 28 Aug, Tom Christiansen wrote:
It's nearly part of Perl's language signature. I wouldn't count
on this going away if you still think to call this "Perl". It is
of course much more likely in the renamed "Frob" language, however.
First off, this argument is just a little too
101 - 123 of 123 matches
Mail list logo
