Re: Shortcut: ?=
What about: ($var = 'succeeded') ||= 'failed'; On Mon, 3 Feb 2003, Sean O'Rourke wrote: Argh. Please disregard that last message as the ramblings of a pre-caffeinated mind. /s On Mon, 3 Feb 2003, Sean O'Rourke wrote: On Mon, 3 Feb 2003, Dave Mitchell wrote: $var ??= 'succeeded' :: 'failed'; Aha! $var 'succeeded' || 'failed'; Thank you, precedence. /s
AW: Language Discussion Summaries
to provide a feeling for the weight of opinion, e.g., most people felt this way, some people felt differently, etc. One should trace back who was of what opinion. So my suggestion would be Discussion: Foo feature Want it:Person A, Person B, Person C, Person D Reject it: Person E, Person F, Person G, Person H Neutral:Person I So posters should also may try to give a clean statement on there final posts how they feal about the feature. Like I think that, but this is Vote: reject this feature. Murat
Re: AW: Language Discussion Summaries
From: =?iso-8859-1?Q?Murat_=DCnalan?= [EMAIL PROTECTED] Date: Tue, 4 Feb 2003 10:21:11 +0100 to provide a feeling for the weight of opinion, e.g., most people felt this way, some people felt differently, etc. One should trace back who was of what opinion. So my suggestion would be Discussion: Foo feature Want it: Person A, Person B, Person C, Person D Reject it: Person E, Person F, Person G, Person H Neutral: Person I I don't think we would really need a Neutral list... So posters should also may try to give a clean statement on there final posts how they feal about the feature. So, would this precise list really help the design team in making decisions. As I see it, they don't care how many of us like a particular feature; on the contrary, they're using us as idea machines. If one person comes up with an idea they like, and most people hate it, they might still use it. I think the original general consensus is fine, and a more specific list would only bog down the summaries. Like I think that, but this is Vote: reject this feature. Vote: reject this idea :) Luke
Re: Arrays: Default Values
Rick Delaney [EMAIL PROTECTED] writes: I'd also like to point out that ruby has defaults for hashes but assigning nil (the equivalent of undef) does not set the default; delete does. Yeah, but Hashes aren't Arrays. And vice versa. -- Piers
Re: Arrays: Default Values
Aaron Sherman [EMAIL PROTECTED] writes:
On Wed, 2003-01-29 at 14:54, Jonathan Scott Duff wrote:
Can someone give me a realish world example of when you would want an
array that can store both undefined values and default values and those
values are different?
my @send_partner_email is default(1);
while $websignups.getline {
($id) = /UserID: (\d+)/;
if /Source: External DB With No Privacy Policy/ {
@send_partner_email[$id] = undef; # No answer given
} elsif /Spam Me: Yes/ {
@send_partner_email[$id] = 1;
} else {
@send_partner_email[$id] = 0;
}
}
# If you were not in the websignups list, you signed up before privacy
# policy, so we spam you (default=1)
In this case, there's a true shrug answer, which is hard to deal with.
We need to do something later on with the undefined case (no answer was
given, and no spam warning issued). This sort of logic deferral is
common to many uses of undefined values (or NULL) in databases, even
when columns have defaults that are non-null.
In this case surely you're better off doing this with a state object.
class UnspecifiedState {
method maybe_send_mail($user) { go_get_more_info }
}
class SendMailState {
method maybe_send_mail($user) { generate_and_send_mail_to($user) }
}
class NoSendMailState {
method maybe_send_mail($user) { }
}
my @send_partner_email is default(SendMailState.new);
while $websignups.getline {
($id) = /UserId: (\d+)/;
when /Source: External DB With No Privacy Policy/ {
@send_partner_email[$id] = UnspecifiedState.new;
}
when /Spam Me: Yes/ {
@send_partner_email[$id] = SendMailState.new;
}
otherwise {
@send_partner_email[$id] = NoSendMailState.new;
}
}
in other words, when you have to deal with tristate logic, make it
explicit tri state logic.
--
Piers
Re: Language Discussion Summaries
The idea of discussion summaries has been well received, so I'm going to push forward with a few. I invite everyone here to join in. The idea is *not* that Miko writes summaries of every thread. The idea is that the proponent of an idea, or someone very interested in an idea, writes a summary as a clean final presentation of the idea and its reception. Submitting a summary of your pet proposed feature is a good way to put the idea in front of the decision makers. You can show off your idea without the clutter of endless detailed commentary. That being said, you still need to present a balanced summary of the all opinions, including those you disagree with. The summaries will be located at http://www.idocs.com/perl6/ Here's how to submit a summary. Use the template at http://www.idocs.com/perl6/template.html . The HTML is set to use the stylesheets on my server, so you can edit the summary on your own machine and submit it once it's clean and ready. Email the summary to me at [EMAIL PROTECTED] The summary should be written after discussion of the idea has winded down. I won't announce in the list the appearance of individual summaries, but I will occasionally post a list of new summaries. I'll be starting with three of my own favorites: vrep (http:[EMAIL PROTECTED]/msg09684.html), the monolithic Loop controls thread (http:[EMAIL PROTECTED]/msg09684.html), and named params in subroutines (http:[EMAIL PROTECTED]/msg09551.html). -Miko Miko O'Sullivan Programmer Analyst Rescue Mission of Roanoke
Re: Language Discussion Summaries
Miko O'Sullivan wrote: The idea of discussion summaries has been well received, so I'm going to push forward with a few. I invite everyone here to join in. The idea is *not* that Miko writes summaries of every thread. The idea is that the proponent of an idea, or someone very interested in an idea, writes a summary as a clean final presentation of the idea and its reception. Hmmm... I'm looking at this and I'm wondering You suggest doing it in HTML. Wouldn't it make more sense to do it in POD, the standard documentation language for Perl? And how do these differ in concept to the RFC process Perl 6 has already gone through? Wouldn't it make sense, assuming that clean, final presentations of proposed ideas or features in Perl are useful, to re-open the RFC process?
Re: Language Discussion Summaries
On Tue, 4 Feb 2003, Buddha Buck wrote: You suggest doing it in HTML. Wouldn't it make more sense to do it in POD, the standard documentation language for Perl? For now, since it's a web site, let's stick to HTML. If somebody just way prefers POD, contact me off list and we'll figure out the best way to proceed. And how do these differ in concept to the RFC process Perl 6 has already gone through? Wouldn't it make sense, assuming that clean, final presentations of proposed ideas or features in Perl are useful, to re-open the RFC process? RFC's are proposals before the comments. The summaries are, well, summaries of the comments. My main concern is that Larry, Damian, et al, are likely to have a hard time reading through all the comments in the language list (Damian isn't even in the list right now), so the summaries are a way of letting them cut to the chase on the discussion of each idea. -miko Miko O'Sullivan Programmer Analyst Rescue Mission of Roanoke
Re: Language Discussion Summaries
Miko O'Sullivan wrote: And how do these differ in concept to the RFC process Perl 6 has already gone through? Wouldn't it make sense, assuming that clean, final presentations of proposed ideas or features in Perl are useful, to re-open the RFC process? RFC's are proposals before the comments. The summaries are, well, summaries of the comments. My main concern is that Larry, Damian, et al, are likely to have a hard time reading through all the comments in the language list (Damian isn't even in the list right now), so the summaries are a way of letting them cut to the chase on the discussion of each idea. You are aware the that RFCs went through a revision process, and the finalized RFCs that the Design Team are looking at are supposed to include the final form of the idea after discussion, and a summary of what was thought of it? Many of the RFCs weren't written until after the idea had been discussed.
Re: Language Discussion Summaries
On Tue, 4 Feb 2003, Buddha Buck wrote: You are aware the that RFCs went through a revision process, and the finalized RFCs that the Design Team are looking at are supposed to include the final form of the idea after discussion, and a summary of what was thought of it? Many of the RFCs weren't written until after the idea had been discussed. Sure, I'm aware of that. However, the language list goes on (and sometimes, on and on and on). If those discussions are to be useful, somebody needs to summarize them. -miko Miko O'Sullivan Programmer Analyst Rescue Mission of Roanoke
Re: Language Discussion Summaries
On Tue, Feb 04, 2003 at 10:56:34AM -0500, Buddha Buck wrote: Miko O'Sullivan wrote: And how do these differ in concept to the RFC process Perl 6 has already gone through? Wouldn't it make sense, assuming that clean, final presentations of proposed ideas or features in Perl are useful, to re-open the RFC process? RFC's are proposals before the comments. The summaries are, well, summaries of the comments. My main concern is that Larry, Damian, et al, are likely to have a hard time reading through all the comments in the language list (Damian isn't even in the list right now), so the summaries are a way of letting them cut to the chase on the discussion of each idea. You are aware the that RFCs went through a revision process, and the finalized RFCs that the Design Team are looking at are supposed to include the final form of the idea after discussion, and a summary of what was thought of it? Many of the RFCs weren't written until after the idea had been discussed. Buddha Buck's comments aside, I think thread-summaries would be a useful thing. But probably only if we continue to have these long seemingly endless threads. Better might be someone who's there to shout LET'S WRAP IT UP PEOPLE! every now and then. And maybe that someone is Miko :-) -Scott -- Jonathan Scott Duff [EMAIL PROTECTED]
Re: Language Discussion Summaries
Sounds like a job for a bot! (couldn't resist) -- Gregor Jonathan Scott Duff [EMAIL PROTECTED] 02/04/2003 11:38 AM Please respond to duff To: Buddha Buck [EMAIL PROTECTED] cc: Miko O'Sullivan [EMAIL PROTECTED], [EMAIL PROTECTED] Subject:Re: Language Discussion Summaries On Tue, Feb 04, 2003 at 10:56:34AM -0500, Buddha Buck wrote: Miko O'Sullivan wrote: And how do these differ in concept to the RFC process Perl 6 has already gone through? Wouldn't it make sense, assuming that clean, final presentations of proposed ideas or features in Perl are useful, to re-open the RFC process? RFC's are proposals before the comments. The summaries are, well, summaries of the comments. My main concern is that Larry, Damian, et al, are likely to have a hard time reading through all the comments in the language list (Damian isn't even in the list right now), so the summaries are a way of letting them cut to the chase on the discussion of each idea. You are aware the that RFCs went through a revision process, and the finalized RFCs that the Design Team are looking at are supposed to include the final form of the idea after discussion, and a summary of what was thought of it? Many of the RFCs weren't written until after the idea had been discussed. Buddha Buck's comments aside, I think thread-summaries would be a useful thing. But probably only if we continue to have these long seemingly endless threads. Better might be someone who's there to shout LET'S WRAP IT UP PEOPLE! every now and then. And maybe that someone is Miko :-) -Scott -- Jonathan Scott Duff [EMAIL PROTECTED]
This weeks' summary
The Perl 6 Summary for the week ending 20030202 Welcome to the second Perl 6 summary of the Copious Free Time era and already I've broken the 'mailed out by Monday evening' promise. There were reasons however, mostly to do with going down to London to do the paperwork for my redundancy stuff. So, I'm emending the promise to 'mailed out by logical Monday evening'. Starting with perl6-internals (which was pretty quiet this week, only 76 messages compared to perl6-language which tipped the scales with 162) Parrot Objects (noun, not verb) Piers Cawley worried about class private attributes and asked it it was still going to be possible to write an object serializing tool that wouldn't require tons of Perl class overloads. Dan said that it should still be possible. http://makeashorterlink.com/?R34F24653 The packfile patches, an ongoing saga. Leo Tötsch spent the week working on the packfile format and Parrot's tools for manipulating it. Various internals folks provided feedback, pointers to standards and other handy feedback. http://makeashorterlink.com/?V25F31653 http://makeashorterlink.com/?G47F21653 http://makeashorterlink.com/?W28F35653 http://makeashorterlink.com/?O19F21653 Securing Parrot ASM Thomas Whateley has been thinking about how to allow Parrot to run untrusted code in a sandbox, and proposed a system where code would provide a list of required rights and Parrot would guarantee that only those privileges were provided. Matthew Byng-Maddick pointed everyone at the RFC he'd written along these lines and raised the issue of what happens when you call out to a module that's written natively, which he described a 'brick wall'. Others were less sure that this was a showstopper. Somewhat annoyingly my mailer seems to have had a bad moment and lost some messages, including one from Dan in which he outlined his vision for 'safe mode' and gave some pointers to the VMS docs in this area. http://makeashorterlink.com/?W3AF52653 http://dev.perl.org/rfc/353.pod http://makeashorterlink.com/?D2BF12653 -- Dan's outline Parrot Developer World Map Leon Brocard announced the Parrot Developer World Map, which plots the locations of all the Parrot developers who sent him their location details on a map of the world. A cursory glance at the map would seem to imply that a good place for a Parrot Developers' face to face meeting would be a Caribbean island. Gregor neatly one upped Leon with his interactive SVG version. http://www.astray.com/parrot/worldmap/ http://makeashorterlink.com/?O2CF12653 Coroutine context patch Jonathan Sillito found some problems with the coroutine code, so he wrote a test exposing the errors, patched things to fix the errors and added a documentation patch to be on the safe side. Go Jonathan. Steve Fink applied the patches. Jonathan also had a question about naming, and wondered if anyone would be interested in a howto for compiler writers. Nobody commented on this, but the howto sounds like a great idea to me. http://makeashorterlink.com/?T4DF21653 Multiple code segments and the interpreter Leo Tötsch noted some problems with interpreter-code and multiple code segments, suggested a way forward and asked for comments. Nicholas Clark commented, wondering about the potential for memory leaks but Leo seemed to think that that was covered. http://makeashorterlink.com/?Q3EF15653 Parrot run loop problems Leo has also been thinking about Parrot run loops and reckons we're doing it wrong. So he proposed a different way of doing things, working through its impact on the various kinds of Parrot core. Steve Fink liked Leo's idea, but Jason Gloudon was less sure. http://makeashorterlink.com/?T1FF53653 Meanwhile, in perl6-language More Array Behaviours Michael Lazzaro is working on documenting Perl Arrays and asked for confirmations and clarifications on various areas of Array behaviour. One subthread morphed into a discussion of when to use is properties and when to use but properties. It turns out that the 'is is compile time, but is runtime' rule of thumb is only a rule of thumb. Damian says that a better distinction is 'but is a property on a value, is is a property on a referent'. Variables, arrays, opaque objects, hashes etc are referents and therefore get is properties. Values are thing things that are held in variables, arrays, opaque objects etc, and they get but properties. http://makeashorterlink.com/?O20021753 Spare Brackets Martin wondered if it would be possible to use [] to do both hash and array lookups. Short answer No. Which isn't to say the thread didn't take off like a runaway train. After far too many messages we reached the same 'No' conclusion that Damian
