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
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):
>
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
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
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
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
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: 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
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: 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
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
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
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
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: 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: 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: 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: 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
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: 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
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: 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: 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: 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
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: [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
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: 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]
> (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: [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: 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
31 matches
Mail list logo
