RE: remote generators
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 a generator object for
foreach to shift qualifying subscribers off of.
I'm uncomfortable with the idea of an object reaching out and overriding
other functions. What if I really want to grep through everything in the
array? How would this work if the grep block is passed to another server:
grep {
print STDERR 'testing:', $_{name}, \n;
$_{smoker} and $_{age} 18;
}
That's not to say that grep and map methods might not be a nifty idea as
tied array methods, but let's keep it to an object-perpsective, say
something like this:
@Subscribers-grep({ $_-{smoker} and $_-{age} 18 });
I'll grant you that tied hashes already reach out and override commands
like each and keys, but those are very simple commands that only take a
hash as an argument, not other complicated arguments like blocks.
Personally, I can't help but think that in any situation in you need to use
a tied array for that sort of complexity you'd probably do better with a
real SOAP object that has methods like return_qualified_smokers.
-Miko
mail2web - Check your email from the web at
http://mail2web.com/ .
Re: RFC - Hashing PMC's albie@halfarrabio.di.uminho.pt
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 in Perl 5, so the language wouldn't
need to be changed in this regard. In Perl 5 the string ID's of the
objects, which are guaranteed globally unique during their lifetime, can be
used as hash keys. So for the code above, your desire for C (%foo{$a} ==
'A') %foo{$b} == 'B' would be met. Of course, you can't pull the
objects themselves back out of the Ckeys array, but FWIW there's a module
on CPAN that gives you that ability, so even that requirement is sorta met
in Perl 5.
I want to be able to do C $b[0] = 3 and
still be able to lookup %foo{$b}
Again, looks like you want something that's already in Perl 5. Tweak the
above code to Perl5 syntax and it Does What You Expect.
But then sometimes you'd *want* hashing to be based
on the content. Hmm. Assuming $b hasn't been
modified, how about:
%foo{*$a} = 'A';
%foo{*$b} = 'B';
If we can make the assumption that the need to do this type of thing is so
rare that we don't need a special language feature to do it, we can again
look to existing Perl 5 capabilities to give you what you want:
%foo{join '', @a} = 'A'
Sorry if this got a bit rambly; I'm not sure working
things out as you type is necessarily a good idea
Maybe I'm doing that myself. Here's my point: the features you suggest
sound great. However, all of those features are already available in Perl
5 in an only slightly more roundabout way. Ergo, I submit that the
language does not need to be changed in any way to do what you suggest.
-Miko
mail2web - Check your email from the web at
http://mail2web.com/ .
Re: 'while {' in Perl 6
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, - means a property or
method will be next while = means maps to. Indeed, 25% of my brain
thinks that - ought to be switched to = because maps to is already
pretty close to the new intended meaning. = as a pair creator doesn't
make a lot of sense in that context anyway, so there's no ambiguity. (45%
of my brain says that = now creates a pair object so yes in fact it *is*
ambiguous, 25% says to Just Trust Larry, and 5% is busy craving a latte).
Question: if the compiler *doesn't* raise an error, what happens? How would
the following code be interpreted, even insanely? An endless loop perhaps?
while something() = $_ { ... }
-Miko
mail2web - Check your email from the web at
http://mail2web.com/ .
Re: Autovivi
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 the speed of pass-by-reference with the guarantees of pass-by-value. 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. I'm not sure I read that right, but it sounds like you're implying that pass-by-values will be read-only. Is that the plan? -Miko mail2web - Check your email from the web at http://mail2web.com/ .
Re: Autovivi
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 said ...
The default is pass-by-reference, but non-modifiable. If
there's a pass-by-value, it'll have to be specially requested
somehow.
This is a minimal difference from Perl 5, in which everything
was pass-by-reference, but modifiable. To get pass-by-value,
you just do an assignment. :-)
Thesis: there should be an option for pass-by-value-modifiable without
requiring a new assignment or new variable.
Reason 1: Pass-by-value-non-modifiable *is* a significant change from
Perl5. I know this doesn't quite mesh with the technical facts, but from
the how-people-actually-use-it perspective, there's a big change. Yes,
Perl5 is pass-by-reference-modifiable, but in practice most people don't
use it that way. Except for short 1-3 line functions, most subs start by
creating named variables and copying them from @_, like one of these lines:
my $self = shift;
my ($tag) = @_;
That is, they actually use it like pass-by-value-modifiable. Now, Perl6
will give us a slicker way to get well-named variables as subroutine
arguments:
sub mysub ($name, $email) { ... }
Ah, but that's where a bait-and-switch problem comes in. It feels like the
param list is taking the place of my ($tag) = @_;, but the new-improved
named arguments don't act the same way. Suddenly they're not modifiable.
That's different.
Reason 2: Enforced non-modifiable arguments are a pain. PL/SQL does not
allow you to modify pass-by-value arguments to functions, and most PLSQL
programmers I've talked to hate that. It requires you to create a named
argument, then another variable with an almost-same-name that can be
modified. My PLSQL is cluttered with variables named v_email and p_email,
instead of just email. I would hate to see Perl go down that road.
Resolution: Use whatever default seems good, but provide the freedom to get
pass-by-value-modifiable, perhaps something like this:
sub mysub ($name is m, $email is m) { ... }
-Miko
mail2web - Check your email from the web at
http://mail2web.com/ .
Re: auto deserialization
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
that since Date isn't a String, it should call the FROM_STRING static
method if such a method is available.
However, it appears that typing won't be so strictly enforced, in which
case the intent becomes ambiguous. Does the line mean to instantiate Date
using the string, or to just assign the string to $bday and just have the
wrong type?
Is there some kind of third option? I have to admit I've always found Java
commands like Date bday = new Date('June 25, 2002') somehow redundant.
-Miko
mail2web - Check your email from the web at
http://mail2web.com/ .
Re: auto deserialization
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 just mentioned.
If so, perhaps it would only be a small step further for
it to also mean and if I don't give the name of the method,
use new_from_[class of object being passed]. So, the following code
would call Date::new_from_String, passing 'Sep 21, 1963' as the
sole argument:
my Date $date;
$date .= 'Sep 21, 1963';
The Perl golfers will love it. It's almost as concise as the original
idea, w/o the ambuguity of what ought to be assigned (the string or a new
object). It shouldn't slow things down, either, because the determination
of the argument's class could be determined at compile time.
-Miko
mail2web - Check your email from the web at
http://mail2web.com/ .
Re: auto deserialization
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. It would see that
$date is in the Date class, and 'Sep 21, 1963' is in the String class, so
it would pretend the statement really reads
$date = Date::new_from_String('Sep 21, 1963');
mail2web - Check your email from the web at
http://mail2web.com/ .
Re: auto deserialization
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, and forget I said anything about the .= operator, I'm glad it's keeping its current job. Suppose there were a #= operator (or whatever you like) which means nothing more and nothing less than instantiate an object of the type the variable is declared for using the 'new' method of that class. Pass the value on the right as the single argument, and assign the results to the variable on the left. To me that results in delightfully clean and unambiguous code like $date #= 'Sep 21, 1963'; If the compiler detects that there is no 'new' method that accepts a single argument of the type to the right of the operator then that's a compile-time error. mail2web - Check your email from the web at http://mail2web.com/ .
Re: Multimethod Dispatch
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 by sub-classing. So, just to clarify, does that mean that multi-dispatch is (by definition) a run-time thing, and overloading is (by def) a compile time thing? -Miko mail2web - Check your email from the web at http://mail2web.com/ .
RE: Argument aliasing for subs
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 at
http:[EMAIL PROTECTED]/msg09551.html . The
end result was that Damian liked the idea and leans towards a syntax like
this:
sub load_data (
$filename_tainted is named('filename'),
$version_input is named('version','ver') //= 1)
{...}
-Miko
mail2web - Check your email from the web at
http://mail2web.com/ .
Re: Argument aliasing for subs
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))
{ ... }
Damian's statement says to me that there is an argument named $force, and
another argument named $override which is also known as $force... that
sounds conflicting. The revised statement simply says that there's an
argument named $force and it is also known as $override.
BTW, the aka thing is cool. It could be complementary to is named:
# can't use force_tainted as argument:
sub hidden (int $force_tainted is named($force))
# can use force_tainted as argument:
sub hidden (int $force_tainted is aka($force))
mail2web - Check your email from the web at
http://mail2web.com/ .
Defaulting params (reprise)
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 persuade Damian, Larry, et al to change. I'd
like to make one more proposal for defaulting. Damian seems to like
properties for arguments, how 'bout this construct:
sub load_data ( $version is default(1) ) {...}
It's clean, fits the existing syntax, and immediately understandable.
Thoughts?
-Miko
--
If you reprise the songs, we'll reprise the jokes. - George S. Kaufman
mail2web - Check your email from the web at
http://mail2web.com/ .
Re: Defaulting params (reprise)
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 to me. I love the //= operator, but in the context of sub declarations it's confusing as the *only* way to default an argument. I still think = makes sense as an argument defaulter... but that issue's been settled for now and I'm not advancing it again. :-) -Miko mail2web - Check your email from the web at http://mail2web.com/ .
Re: Defaulting params (reprise)
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 in a function call, it would almost have to
not DWIM outside a function call. Why? Well, the concept (as seen through
my too-human eyes) would be that the function arguments would be created
and populated something like this: 1) create the variable 2) if the
argument is sent, set the value of the variable using the sent value 3)
else set the value using the default property.
OK, that makes sense so far, but outside of a function call, I'm not sure
where it would be decided that the variable was never set, and so it would
never get the default value. Yes, is default could populate the variable
as soon as it is created, but that seems wasteful.
Is there a general rule that a property must make sense in all contexts?
If Perl6 has the is named property for sub arguments, does that mean that
it must also make sense outside a function...
my $foo is named('bar');
(Hmm, maybe it does... you could have two variables aliased to each other.
OK, bad example. Work with me here.)
-Miko
mail2web - Check your email from the web at
http://mail2web.com/ .
Re: Defaulting params (reprise)
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. If the argument is passed, the default property is ignored. If it isn't set, only then is the default property used to set the value. That's why I don't think the property makes any sense except when used to define subroutine arguments. And then Damian said: That's why we chose them for parameter defaulting as well. Ah well. Let's see how it plays in Peoria. -Miko mail2web - Check your email from the web at http://mail2web.com/ .
Re: Blocks and semicolons
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 at http://mail2web.com/ .
RE: We need an OO issue list tutorial!
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 cookbooks: we could use a lot more of Damian's And now for something completely similar concept. There's a growing fear out there that Perl6 is going to crumble everyone's houses in an earthquake of shifting paradigms. Every Perl6 cookbook would do well to start with some delightfully childlike examples like this: # Perl5 blah(); # Perl6 blah(); Stuff like that eases people into the Perl6 world by starting with the familiar. Perhaps to go with Apocalypses and Exegeses we could have Psalms, a bunch of bitsize perls of wisdom. Except, um, psalms are, by definition, sacred, so, um, I dunno, just a thought. Larry? -Miko mail2web - Check your email from the web at http://mail2web.com/ .
Re: untaintby property
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 to implement my ideas without having to fiddle with the language itself. Too groovy. -Miko mail2web - Check your email from the web at http://mail2web.com/ .
RE: Indeterminate math
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 bit of impossible math, to return undef (like other functions do on failure) than to generate an error. The error seems a throwback to earlier days of hardwired calculators. The problem with returning undef is that undef numifies to zero. It would make more sense if either 1/0 returned NaN, if Perl6 has NaN, or throw an error, which Larry has indicated will be a concept in Perl6. There once was a man from NaNtucket Who kept all his bits in a bucket He said I'm a hero! I divided by zero! and the bits in the bucket, they tuckit! -Miko mail2web - Check your email from the web at http://mail2web.com/ .
Re: Indeterminate math
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 (the square root of -1), or Lukasiwiscean Null? (Sorry if I sound sarcastic, I'm actually honestly curious.) My inner Larry Wall is right now saying that there needs to be a more generalized solution to all this. OK, here's one. By default, anything/0 throws an exception. However, you can load modules to handle those exceptions, substituting Inf, NaN, or whatever as the evaluation of the expression. -Miko mail2web - Check your email from the web at http://mail2web.com/ .
Lukasiewiczian logic (was Indeterminate math)
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 that it affects logical and aggregate operations. Actually, something I wouldn't mind seeing in other languages -- I can't say if perl is one of those, but if it can be provided by expansion, that would be neato. Miko, did I get the right thing out of that? Yup. It would be cool to be able to overload , ||, and ! to implement Lukasiewiczian logic within a given scope. I'm no expert, but I wrote a short essay explaining Lukasiewiczian logic. See http://ars.userfriendly.org/cartoons/read.cgi?id=20020904tid=389032 Trivia: Jan Lukasiewicz is the Polish in Reverse Polish Notation. Trivia 2: my mom, Carole O'Sullivan nee Lucas, says Lukasiewicz is probably my second cousin fifteen times removed, or something like that. It's probably my best credentials in the math world. -Miko mail2web - Check your email from the web at http://mail2web.com/ .
A concept for Exceptions
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 of the entire expression, or throwing an exception as usual. JUSTIFICATION Why do I want to augment how exceptions are handled? Is everything about exceptions already invented? The answer is that I hate how Java handles exceptions. In Java it seems like every time you want to do something, you have to surround it with exception handlers. I find that in Java my code becomes buried in exceptions. Yes, the current every-block-is-a-try-block greatly helps this problem, but there's still the looming prospect of having to write mountains of CATCH blocks to handle every problem. What I propose here is a system that provides a technique for actually fixing the problems on the fly, instead of having to hand code error handling every step of the way. Furthermore, the techniques described here provide a way to make certain behaviors modifiable, so that everybody gets their own favorite flavor of ice cream, so to speak. This concept was inspired by the variety of preferences about how Perl6 should handle 1/0. Please note that this is not a proposal for *changing* how exceptions are handled, it's merely an *addition* to the standard techniques. EXCEPTIONCREATOR CLASS Each block gets a reference to an ExceptionCreator object. By default, blocks inherit their parent's reference, so we won't have to be moving and creating references a lot. When the interpretor gets to an error, it calls the ExceptionCreator's standard method for handling that specific type of exception: divByZero(), stringConcatenationUsingUndef(), whatever. The method for that type of exception calls the constructor of an Exception class that is devoted to handling just that type of exception. The Exception's constructor method, described in more detail on the next section, determines how the exception is handled. To change how certain exceptions behave, a block simply changes the methods of the existing ExceptionCreator to point to other subroutines. This approach allows for an ala carte style of exception configuration. Blocks can (through a module that makes this sort of thing easy), clone the ExceptionCreator object, then change just the methods that are desired. A reference to that new object is passed down the line to child blocks. You can also set the default ExceptionCreator reference, i.e. the ExceptionCreator used by default by all blocks in the entire program. By doing so, you can set how certain exceptions are handled by modules that you use but didn't write. For example, suppose I want all string concatenations using undef to be fatal (and I do). I simply override the default ExceptionCreator's concatUndef() method to something more fatal. The following are some of the standard exceptions that the interpretor might throw. I'm sure there a more. These are just the ones that come to mind. - divide by zero - numeric operation on non-numeric value - string concatenation using undef - use of tainted data in protected operation - unsuccesful attempt to open file Modules that provide alternate exception handlers should supply static methods for making the change to a given block. For example, to have div by zero evaluate to Inf instead of a fatal exception, you could simply add this code to your block: use Math::Inf::Exception; and voila, the import routine sets your block's ExceptionCreator for handling div by zero errors. EXCEPTION CLASS Every type of standard exception has its own class. The static constructor method, new, accepts one argument and returns one of three possible values. The input is a reference to the object that caused the exception. This is an optional argument in case no specific object threw the exception. An example of an object that threw an exception would the undef object used in a string concatenation. The constructor returns one of three values: an exception object, the DO_OVER constant, or the EXPRESSION constant. If an exception object is returned, that means that the interpretor should immediately exit the block, throwing the exception to that block's CATCH block, or its parent's CATCH block, and so on outward until somebody catches it. You know the routine. DO_OVER means to reevaluate the expression because the reference to the offending variable has been set to something else. For example, the undef might have been changed to an empty string. The interpretor will only call each type of exception once for each type of object. If the exception constructor just sets the value to another undef, the interpretor will make a nasty gesture are the handler, so enough of you, and throw its own UnhandledException exception. It must be noted
Re: A concept for Exceptions
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 is that certain common types of exceptions could be handled in-place, instead of having to write exception handlers. Perl5 already does some things like this, e.g. undefs become empty strings and zeros when needed. I'm just suggesting formalizing the process more so that custom in-place exception handlers can be implemented. Does that make the return what to do concept a little more elegant? If not, feel free to work a Pygmalion with my Eliza Doolittle. -miko mail2web - Check your email from the web at http://mail2web.com/ .
Re: [RELEASE] Parrot 0.1.2 Phoenix Released!
Leo, you (or someone) might want to: s/Poicephalus/Phoenix/ on parrotcode.org etc. When you get a spare minute ;-) -- Ciao Richard Foley Ciao - shorter than aufwiedersehen http://www.oreilly.com/catalog/perldebugpr/ -Original Message- Date: Sun, 6 Mar 2005 16:57:38 +0100 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 dynamic languages. Parrot 0.1.2 contains a lot of new stuff: - New string handling code. Strings now have charset and encoding - Parts of a generational garbage collector - Better Python support, separated into dynclasses - Parrot Grammar Engine - Improved test coverage and documentation - and a lot more After some pause you can grab it from http://www.cpan.org/authors/id/L/LT/LTOETSCH/parrot-0.1.2.tar.gz. As parrot is still in steady development we recommend that you just get the latest and best from CVS by following the directions at http://dev.perl.org/cvs/. Turn your web browser towards http://www.parrotcode.org/ for more information about Parrot, get involved, and: Have fun! leo
Re: Perl development server
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 http://convolution.nl/make_juerd_happy.html http://convolution.nl/gajigu_juerd_n.html
Re: Perl development server
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 far. How about zephyr. The building my grandmother lives in is called Zephyr. For me, the word is strongly associated with old people, and not at all with programming :) While an onion has many layers that together make a single whole that adds taste to almost any meal, which I think is a nice view of Perl 6. Juerd -- http://convolution.nl/maak_juerd_blij.html http://convolution.nl/make_juerd_happy.html http://convolution.nl/gajigu_juerd_n.html
A question about role-private attributes
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 private attribute is always considered lexically
scoped. If a role declares private lexical items, those items are
private to the role due to the nature of lexical scoping.
===
I was unable to figure out what this piece of code would print:
role A {
my $!spleen;
method set_spleen($x) { $!spleen = $x; return self }
method say_spleen() { say $!spleen }
}
class B does A {}
class C does A {}
B.new.set_spleen(3).say_spleen();
B.new.say_spleen();
C.new.say_spleen();
==
How many 3s will that print? Just a single 3 would indicate that every
instance of every class that composed A has its own copy. If 3 is
printed twice, that would indicate that not every instance but every
class has its own copy. All three 3s will indicate only a single copy
for the entire role.
My guess is that the first interpretation was intended. Is that guess
correct? I would also guess that Cmy $spleen would give us the third
interpretation. But I do not know what syntax would result in a role-
private class attribute.
Thanks,
Abhijit
