A question about role-private attributes

2008-11-09 Thread [EMAIL PROTECTED]
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: Cmy $!spleen; The name of such a

Re: Perl development server

2005-05-23 Thread [EMAIL PROTECTED]
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 best so far. Juerd -- http://convolution.nl/maak_juerd_blij.html

Re: Perl development server

2005-05-23 Thread [EMAIL PROTECTED]
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): I like onion the best so

Re: [RELEASE] Parrot 0.1.2 Phoenix Released!

2005-03-07 Thread [EMAIL PROTECTED]
Subject: [RELEASE] Parrot 0.1.2 Phoenix Released! From: Leopold Toetsch [EMAIL PROTECTED] To: Perl 6 Internals perl6-internals@perl.org On behalf of the Parrot team I'm proud to announce the release of Parrot 0.1.2. What is Parrot? Parrot is a virtual machine aimed at running Perl6 and other

A concept for Exceptions

2002-10-15 Thread [EMAIL PROTECTED]
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

Re: A concept for Exceptions

2002-10-15 Thread [EMAIL PROTECTED]
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 suggesting

Re: untaintby property

2002-10-14 Thread [EMAIL PROTECTED]
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 written

RE: Indeterminate math

2002-10-14 Thread [EMAIL PROTECTED]
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 being given a simple

Re: Indeterminate math

2002-10-14 Thread [EMAIL PROTECTED]
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 down that road, how about i

Lukasiewiczian logic (was Indeterminate math)

2002-10-14 Thread [EMAIL PROTECTED]
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 nifty ways

RE: We need an OO issue list tutorial!

2002-10-04 Thread [EMAIL PROTECTED]
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 general concept of Perl6

Re: Blocks and semicolons

2002-09-12 Thread [EMAIL PROTECTED]
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 mail2web - Check your email from the web

Re: Defaulting params (reprise)

2002-09-05 Thread [EMAIL PROTECTED]
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 is called

Re: Multimethod Dispatch

2002-09-04 Thread [EMAIL PROTECTED]
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 to re-use code

RE: Argument aliasing for subs

2002-09-04 Thread [EMAIL PROTECTED]
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 -force: Yes. See the thread starting

Re: Argument aliasing for subs

2002-09-04 Thread [EMAIL PROTECTED]
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 is aka($override

Defaulting params (reprise)

2002-09-04 Thread [EMAIL PROTECTED]
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

Re: Defaulting params (reprise)

2002-09-04 Thread [EMAIL PROTECTED]
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 clear and concise

Re: Defaulting params (reprise)

2002-09-04 Thread [EMAIL PROTECTED]
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 is default to DWIM

Re: auto deserialization

2002-09-03 Thread [EMAIL PROTECTED]
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 class I

Re: auto deserialization

2002-09-03 Thread [EMAIL PROTECTED]
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 the class because the compiler would understand what to call

Re: auto deserialization

2002-09-03 Thread [EMAIL PROTECTED]
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 proposal. Oh

Re: auto deserialization

2002-08-28 Thread [EMAIL PROTECTED]
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 VM can always know

Re: Autovivi

2002-08-14 Thread [EMAIL PROTECTED]
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 mental baggage. and later he

Re: Autovivi

2002-08-13 Thread [EMAIL PROTECTED]
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-faced attempt to get

Re: 'while {' in Perl 6

2002-08-12 Thread [EMAIL PROTECTED]
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. To my Perl5 eyes

Re: RFC - Hashing PMC's albie@halfarrabio.di.uminho.pt

2002-07-23 Thread [EMAIL PROTECTED]
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 a case of And Now For Something Completely Similar. This looks like something we already have

RE: remote generators

2002-07-22 Thread [EMAIL PROTECTED]
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 to the data server, and get back