I am trying to understand the following small portion from S12, and it
seems slightly ambiguous to me:
=== from S12:
You may wish to declare an attribute that is hidden even from the
class; a completely private role attribute may be declared like this:
C
The name of such a private attrib
On Tue, 22 Feb 2005 11:37:21 -0800, "Larry Wall" <[EMAIL PROTECTED]> said:
> or our great-grandchildren
> will curse our lack of foresight.
>
> Larry
It won't matter then anyway...Perl 25 code will
100
> Subject: [RELEASE] Parrot 0.1.2 "Phoenix" Released!
> From: Leopold Toetsch <[EMAIL PROTECTED]>
> To: Perl 6 Internals
> On behalf of the Parrot team I'm proud to announce the release of
> Parrot 0.1.2.
>
> What is Parrot?
>
> Parrot is a virtu
How about "zephyr".
On Mon, 23 May 2005 18:55:29 +0200, "Juerd" <[EMAIL PROTECTED]> said:
> Thomas Klausner skribis 2005-05-23 18:03 (+0200):
> > onion
>
> Sorry, I had previously overlooked this lone paragraph.
>
> I like "onion" the
It reminds me of minor league baseball and roller coasters...anyway,
onion seems somehow appropriate since they also make the people kitchen
cry ;)
On Mon, 23 May 2005 21:00:51 +0200, "Juerd" <[EMAIL PROTECTED]> said:
> [EMAIL PROTECTED] skribis 2005-05-23 13:58 (-0500):
>
From: david nicol [EMAIL PROTECTED]
> foreach (grep { $_->{smoker} and $_->{age} > 18 } @Subscribers){
> $->send($Cigarette_Advertisement)
> }
>
> This would imply an extension of the array tieing
> interface, so we can send the grep block
From: [EMAIL PROTECTED]
> If I have:
>
>$a = [ 1, 2, 3 ];
>$b = [ 1, 2, 3 ];
>
>%foo{$a} = 'A';
>%foo{$b} = 'B';
>
> Then I want C< (%foo{$a} == 'A') && %foo{$b} == 'B' > to be true.
Maybe this
From: Larry Wall [EMAIL PROTECTED]
> (Had an interesting typo there. I put => insteaqd of ->.
> I wonder how much trouble that sort of thing is gonna cause.
> Maybe pairs can be disallowed or warned about where a pointy
> sub might be expected.)
I foresee a lot of problems.
From: Larry Wall [EMAIL PROTECTED]
> Of course, there are issues here if the code modifies those
> variables, since the issue of whether a variable is rw is
> really distinct from whether it represents a pass by value
> or reference. Slapping a "constant" on it is a bald-
From: Larry Wall [EMAIL PROTECTED]
> Perhaps there should be a way
> to declare a parameter to be pass-by-value, producing a
> modifiable variable that does not affect the caller's value.
> But I'm not sure saving one assignment in the body is worth
> the extra m
From: [EMAIL PROTECTED]
> Wow, this is nice. He means (I think) that this will be translated into
> my Date $bday = Date->new('June 25, 2002');
I rather like it too, but it hinges on how strictly typing is enforced. If
typing is strictly enforced then it works because the
On Monday, September 2, 2002, at 03:44 AM, Damian Conway wrote:
>> my Date $date .= new('Jun 25, 20002');
>
> H. That's a very interesting idea.
> I like it.
Looks pretty groovy to me too. It looks like the .=
operator, no longer being employed as a string appender,
now means "use the cla
From: Trey Harris [EMAIL PROTECTED]
> no strict 'refs';
> my Date $date;
> $date .= 'Sep 21, 1963';
>
> There is a method name there--'Date::Sep 21, 1963'.
But that's my point. You wouldn't have to put the method name or
From: Dan Sugalski [EMAIL PROTECTED]
> This will potentially get out of hand quickly
I don't think this is a case where out-of-hand-generalization is necessary.
I'm only saying that there could be a handy shorthand for a single very
common case. Nevertheless, I'll simplify the
From: Ken Fox [EMAIL PROTECTED]
> Over loading is what C++ has. It is not the same as
> multi-dispatch. The trouble with over loading is that the
> compiler uses static (compile-time) type information to
> select the over loaded method. This can create subtle
> bugs when people try
From: Peter Behroozi [EMAIL PROTECTED]
> Has anyone considered a syntax for allowing
> subroutines to have many different names for
> the same argument? For example, in CGI.pm, many
> methods support the "-override" parameter but
> can also accept the alias of "
From: Damian Conway [EMAIL PROTECTED]
> If it were allowed, it would probably be done
> via properties instead:
>
> sub hidden (str $name, int $force, int $override is aka($force))
>{ ... }
Would the following be simpler...?
sub hidden (str $name, int $force i
It was settled a while ago that sub arguments would be defaulted like this:
sub load_data ($version / /=1) {...}
(The space between / and / is on purpose, my emailer has problems if they
are together) I and a few others had issues with the slash-slash-equals
thing, but were unable to persuad
From: Jonathan Scott Duff [EMAIL PROTECTED]
> Or are you proposing to *only* replace //=? Or are you
> proposing to *only* replace //= in subroutine declarations?
Only augment //= in subroutine declarations, //= would also work.
> What issues did you have with //=? It seems
From: Jonathan Scott Duff [EMAIL PROTECTED]
> Oh. You want default() to be synonymous with //= but only in
> subroutine declarations. That seems a tad odd. Why not make it
> synonymous everywhere?
>
> my $foo is default(23); # same as ...
> my $foo //= 23;
Well, for &q
From: Trey Harris [EMAIL PROTECTED]
> Properties are meant to be out-of-band information; miko's
> suggestion would have this property setting the *value* of
> the variable.
Ah, but my exact point is that the default *isn't* set immediately. The
property is held until the sub
From: Ken Fox [EMAIL PROTECTED]
> BTW, does anybody else find "is rx" funny?
Only because they're not called regular expressions anymore. How about
"px" for "pattern expression"?
-Miko
---
From: Luke Palmer [EMAIL PROTECTED]
> [snip]
Luke, thanks and congratulations on a well written case. You put into
words exactly what I was trying to put into words myself. Now I don't have
to finish this ugly draft I have lying around
From: Michael Lazzaro [EMAIL PROTECTED]
> Proposed Remedy: We need to better document our
> discussions so that we don't keep having them.
That's a groovy idea. It'll help us all by defining terms and providing
examples to wrap our brains around.
An idea to add to the gen
SUMMARY
The 'untaintby' property restricts which modules may untaint the data or
data derived from that data.
DETAILS
I was recently using a module I downloaded from CPAN and looking through
the code I discovered that it untainted certain data that it had no
business untainting (IMHO). The unt
Larry said:
> If properties aren't entirely passive, then it may be
> possible to register a callback on the "tainted" property
> itself that defeats any misguided attempt to untaint it.
Callbacks on properties? That's too cool. By doing callbacks on tainted
and on taintby, a module could be wri
From: Michael G Schwern [EMAIL PROTECTED]
> This came up at YAPC::Europe. Someone [1] wanted to know if 1/0
> would produce a divide by zero error in Perl 6, or if it would
> return a value representing an indeterminate result (undef?)
> It would make more sense for Perl, upon b
From: Mark J. Reed [EMAIL PROTECTED]
> Summary of values:
>
>1/0 +Inf
>-1/0 -Inf
>0/0 NaN
>Inf/0NaN
>Inf/Inf NaN
Are Inf and NaN going to be standard in Perl 6? As long as we're traveling
d
From: Andrew Rodland [EMAIL PROTECTED]
> After much fighting with google to find the right spelling,
Sorry bout that. Your searching was probably as difficult as my attempts
to pronounce it.
> it looks like "Lukasiewiczian NULL" is just the nifty NULL
> that SQL has, and the
A brainstorm for your enjoyment, perusal, and general discussion...
SUMMARY
A proposal for an extension to the usual exception handling concept. The
concept detailed here provides a mechanism for handling exceptions in one
of three ways: changing the values being evaluated, setting the result
From: Luke Palmer [EMAIL PROTECTED]
> I like the idea of this. The finer details, like returning
> what to do, could be more elegant. But the extensibility
> idea is golden.
Thanks Luke. Your email made me think of another way of explaining the
concept. Basically, what I'm sugg
31 matches
Mail list logo
