Re: [OT] TDD + Pair Programming
Luke Closs [EMAIL PROTECTED] writes: On Sat, Apr 01, 2006 at 04:04:42PM -0800, Jeffrey Thalhammer wrote: What makes pairing good is the increased attention to code as it comes out. The pair discusses the implementation, which not only finds lots of simple bugs very early, it also: - transfers knowledge extremely fast - focuses on solving the problem at hand in the simplest way possible - encourages code refactoring and other good practices - builds discipline and respect in the team Agreed. The test are as worthy as the resulting code, so the healthy effects of Pair programming should also be exploited for them. So feel free to combine TDD with Pair Programming, but don't divide the pair. Steffen -- Steffen Schwigon [EMAIL PROTECTED] Dresden Perl Mongers http://dresden-pm.org/
Re: Show-stopping Bug in Module::Install and the Havoc it Created
On Sat, Mar 11, 2006 at 10:20:29AM +0100, Tels wrote: B when it breaks, end-users cannot fix the problem for themselves, they need to bug the author and he has to release a new version. (Good luck with that with sparsely maintained modules...) Last time this happened to me, I just replaced the bundled version with a newer one. No need to bug the author (though I did verify that others already had). (Since then, I've heard (but haven't confirmed) that just installing a newer MI and running Makefile.PL in the broken dist will do this automatically. Is this correct?)
Where did I see this use of plan()?
I remember working with some module that had tests something like:
use Test::More;
plan tests = numtests();
...
is($foo, $bar, 'foo is bar');
sub numtests { 13 }
So that when you added a new test to the bottom, the number to modify
was right there also. Ring a bell with anyone?
Re: [PATCH] My first patch, for builtins.*
Andy Lester wrote: I've been spending a lot of time the past 6 months (more?) doing source code cleanup on the Perl 5 source code. Welcome @ parrot, Andy. I'd like to spend some time doing the same for Parrot, too. I hope that doing the kind of maintenance I'm interested in makes things easier for the core Parrot developers do their jobs. Here's my first patch. Let me know if y'all see this sort of work as useful, or if I shouldn't bother. Useful and very welcome, thanks, applied - r12096. (I've slightly modified it, used N_BUILTINS once more). xoxo, Andy leo
Re: Show-stopping Bug in Module::Install and the Havoc it Created
Yitzchak Scott-Thoennes wrote: On Sat, Mar 11, 2006 at 10:20:29AM +0100, Tels wrote: B when it breaks, end-users cannot fix the problem for themselves, they need to bug the author and he has to release a new version. (Good luck with that with sparsely maintained modules...) Last time this happened to me, I just replaced the bundled version with a newer one. No need to bug the author (though I did verify that others already had). (Since then, I've heard (but haven't confirmed) that just installing a newer MI and running Makefile.PL in the broken dist will do this automatically. Is this correct?) No, although if you delete the inc directory entirely, the Makefile.PL should latch onto the system version and go into author mode, which for the purposes of installation is almost entirely the same. HOWEVER, that requires that they NOT be using a custom extension, and than the commands used in the Makefile.PL match those in the current version of Module::Install. The command list isn't entirely frozen yet, so while it may work, there's some risks. Once the commands have frozen, this will be a lot safer to do. Adam K
[svn:perl6-synopsis] r8553 - doc/trunk/design/syn
Author: autrijus
Date: Mon Apr 3 05:47:07 2006
New Revision: 8553
Modified:
doc/trunk/design/syn/S09.pod
Log:
* S09: Leo pointed out the paragraph on autovivifiction
is still mentioning references. Replace it with modern
wording (surface semantics stays unchanged)
Modified: doc/trunk/design/syn/S09.pod
==
--- doc/trunk/design/syn/S09.pod(original)
+++ doc/trunk/design/syn/S09.podMon Apr 3 05:47:07 2006
@@ -696,9 +696,10 @@
my $val := $hash{foo}{bar};
my @array;
-my $ref = \$array[0][0];
+my $ref = \$array[0][0]; # $ref is an Arguments object - see S02
my %hash;
$hash{foo}{bar} = foo; # duh
-This rule applies to dereferencing arrays, hashes, and scalar references.
+This rule applies to CArray, CHash, and CScalar container objects.
+
Re: Module requirements (was: Module::Build and installing in non-standardlocations)
Moin, On Sunday 02 April 2006 16:37, Sébastien Aperghis-Tramoni wrote: Adam Kennedy wrote: [snip] This is a little harder with Module::Build as it has a few dependencies that ask 5.005 or 5.6, although in some cases incorrectly. I send patches so modules like File::Temp or ExtUtils::Constant work with 5.004 (and maybe earlier) but their author haven't yet released updated versions. With these patches (and if the test suites of some of these are fixed), several modules can probably work on 5.004 or earlier with little to no changes. OTOH, who still runs pre-5.8.x code deserves what they get. There are horrible bugs in older Perls, and I don't know why people still insist using insecure, buggy and feature-lacking code like 5.6. or even gasp 5.004. Just think Unicode support, hash randomization, memory leaks. Using these older Perls means you basically show the hard-working Perl5-Porters that you don't care for their work in improving Perl. I know, now people will come out of the wood and say that they have that old system, and no, they can't upgrade Perl etc, never touch a running system etc yadda yadda. But what the heck do you then try to upgrade modules on said system when you didn't want to touch the system? Best wishes, Tels -- Signed on Mon Apr 3 18:28:11 2006 with key 0x93B84C15. Visit my photo gallery at http://bloodgate.com/photos/ PGP key on http://bloodgate.com/tels.asc or per email. I'm not a vegetarian, but I eat animals who are -- Groucho Marx pgpPAaVWHvLKH.pgp Description: PGP signature
[svn:perl6-synopsis] r8554 - doc/trunk/design/syn
Author: larry
Date: Mon Apr 3 11:08:54 2006
New Revision: 8554
Modified:
doc/trunk/design/syn/S05.pod
Log:
Mark Biggar points out that rule closure section had embedded closure verbiage.
Modified: doc/trunk/design/syn/S05.pod
==
--- doc/trunk/design/syn/S05.pod(original)
+++ doc/trunk/design/syn/S05.podMon Apr 3 11:08:54 2006
@@ -13,9 +13,9 @@
Maintainer: Patrick Michaud [EMAIL PROTECTED]
Date: 24 Jun 2002
- Last Modified: 1 Apr 2006
+ Last Modified: 3 Apr 2006
Number: 5
- Version: 13
+ Version: 14
This document summarizes Apocalypse 5, which is about the new regex
syntax. We now try to call them rules because they haven't been
@@ -588,10 +588,11 @@
The closure is guaranteed to be run at the canonical time.
-An Bexplicit return from the closure binds the Iresult object for
-this match, ignores the rest of the current rule, and reports success:
+As with an ordinary embedded closure, an Bexplicit return from a
+rule closure binds the Iresult object for this match, ignores the
+rest of the current rule, and reports success:
- / (\d) { return $0.sqrt } NotReached /;
+ / (\d) { return $0.sqrt } NotReached /;
This has the effect of capturing the square root of the numified string,
instead of the string. The CNotReached part is not reached.
[perl #38840] Use File::Spec instead of /dev/null
# New Ticket Created by Will Coleda # Please include the string: [perl #38840] # in the subject line of all future correspondence about this issue. # URL: https://rt.perl.org/rt3/Ticket/Display.html?id=38840 The following files reference '/dev/null/' directly, and should be updated to use the File::Spec's interface instead of either rolling their own or assuming '/dev/null' works everywhere. languages/punie/t/base_term.t lib/Parrot/Configure/Step.pm lib/Parrot/Test/Perl6.pm lib/Parrot/Test.pm t/configure/step.t t/examples/library.t t/library/pcre.t t/run/exit.t t/run/options.t tools/dev/lib_deps.pl
[perl #38841] [TODO] Split exec run core into two distinct run cores
# New Ticket Created by Bernhard Schmalhofer # Please include the string: [perl #38841] # in the subject line of all future correspondence about this issue. # URL: https://rt.perl.org/rt3/Ticket/Display.html?id=38841 The exec runcore is about saving compiled JIT code in an object file and generating an executable. The generated executable can then be executed without having to do JIT compilation again. Compilation and execution are two very distinct phases, still they are refered to as exec core, as indicated by the enum PARROT_EXEC_CORE in interpreter.h. I propose to replace the enum value PARROT_EXEC_CORE with the two new values : PARROT_EXEC_COMPILE_CORE and PARROT_EXEC_RUN_CORE. This should make the code more clear and might limit the use of the shared variable 'Parrot_exec_run'. The problem that core is dumped, whenever the compiled JIT is executed, would of course not be solved by that. Any comments? CU, Bernhard
Re: Module requirements (was: Module::Build and installing in non-standardlocations)
I know, now people will come out of the wood and say that they have that old system, and no, they can't upgrade Perl etc, never touch a running system etc yadda yadda. But what the heck do you then try to upgrade modules on said system when you didn't want to touch the system? To quote possibly the smartest thing I've ever heard Donald Rumsfeld say (although he put it somewhat confusingly) There are known knowns. These are things we know that we know. There are known unknowns. That is to say, there are things that we know we don't know. But there are also unknown unknowns. There are things we don't know we don't know. While you might not see why, let me tell you from the number of bug emails I've received about these sorts of issues, I _know_ there are scenarios we don't know about where this stuff is important. I just don't know what they are :) Adam K
Re: [perl #38841] [TODO] Split exec run core into two distinct run cores
On Apr 3, 2006, at 21:04, Bernhard Schmalhofer (via RT) wrote: I propose to replace the enum value PARROT_EXEC_CORE with the two new values : PARROT_EXEC_COMPILE_CORE and PARROT_EXEC_RUN_CORE. This should make the code more clear and might limit the use of the shared variable 'Parrot_exec_run'. Very much appreciated. As already noted in that include file, runcore feature bits should be arranged, so that individual parts of a run core can be tested too. E.g. exec := jit_bit | exec_bit. And while there, e.g. runcore should have an associated name for better error reporting in e.g. src/interpreter.c:308 internal_exception(1, Couldn't find init_func for core %d, which); Thanks, leo
[svn:parrot-pdd] r12104 - trunk/docs/pdds/clip
Author: petdance
Date: Mon Apr 3 13:29:21 2006
New Revision: 12104
Modified:
trunk/docs/pdds/clip/pdd07_codingstd.pod
Log:
Added section on const and localizing variables. Also, cleaned up some
whitespce
Modified: trunk/docs/pdds/clip/pdd07_codingstd.pod
==
--- trunk/docs/pdds/clip/pdd07_codingstd.pod(original)
+++ trunk/docs/pdds/clip/pdd07_codingstd.podMon Apr 3 13:29:21 2006
@@ -1,4 +1,4 @@
-# Copyright: 2001-2005 The Perl Foundation. All Rights Reserved.
+# Copyright: 2001-2006 The Perl Foundation. All Rights Reserved.
# $Id$
=head1 NAME
@@ -86,7 +86,8 @@
=item *
-No C++ style comments (C//): some C compilers may choke on them
+C-style comments only (C/* comment */). Not all C compilers handle
+C++-style comments.
=item *
@@ -502,8 +503,8 @@
=item *
-A macro defining a mask of flag bits should be suffixed with C_MASK, eg Cfoo
-= ~PMC_STATUS_MASK (but see notes on extensibility below).
+A macro defining a mask of flag bits should be suffixed with C_MASK, eg
+Cfoo = ~PMC_STATUS_MASK (but see notes on extensibility below).
=item *
@@ -565,19 +566,19 @@
the form CGLOBAL_foo (the name being deliberately clunky). So we might for
example have the following macros:
- /* perl_core.h or similar */
+/* perl_core.h or similar */
- #ifdef HAS_THREADS
- # define GLOBALS_BASE (aTHX_-globals)
- #else
- # define GLOBALS_BASE (Perl_globals)
- #endif
-
- /* pmc_private.h */
-
- #define GLOBAL_foo GLOBALS_BASE.pmc.foo
- #define GLOBAL_bar GLOBALS_BASE.pmc.bar
- ... etc ...
+#ifdef HAS_THREADS
+# define GLOBALS_BASE (aTHX_-globals)
+#else
+# define GLOBALS_BASE (Perl_globals)
+#endif
+
+/* pmc_private.h */
+
+#define GLOBAL_foo GLOBALS_BASE.pmc.foo
+#define GLOBAL_bar GLOBALS_BASE.pmc.bar
+... etc ...
=back
@@ -679,7 +680,7 @@
This inline POD documentation is parsed to HTML by running:
- % perl tools/docs/write_docs.pl -s
+% perl tools/docs/write_docs.pl -s
=item Optimizations
@@ -699,16 +700,16 @@
comments are particularly useful at the top of each major branch, eg
if (FOO_bar_BAZ(**p+*q) = (r-s[FOZ FAZ_MASK]) || FLOP_2(z99)) {
- /* we're in foo mode: clean up lexicals */
- ... (20 lines of gibberish) ...
+/* we're in foo mode: clean up lexicals */
+... (20 lines of gibberish) ...
}
else if (...) {
- /* we're in bar mode: clean up globals */
- ... (20 more lines of gibberish) ...
+/* we're in bar mode: clean up globals */
+... (20 more lines of gibberish) ...
}
else {
- /* we're in baz mode: self-destruct */
-
+/* we're in baz mode: self-destruct */
+
}
=back
@@ -760,6 +761,79 @@
TBC ... Any contributions welcome !!!
+=head2 Defensive programming
+
+=head3 The Cconst keyword on arguments
+
+Use the Cconst keyword as often as possible on pointers. It lets
+the compiler know when you intend to modify the contents of something.
+For example, take this definition:
+
+int strlen( const char *p );
+
+The Cconst qualifier tells the compiler that the argument will not be
+modified. The compiler can then tell you that this is an uninitialized
+variable:
+
+char *p;
+int n = strlen(p);
+
+Without the Cconst, the compiler has to assume that Cstrlen() is
+actually initializing the contents of Cp.
+
+=head3 The Cconst keyword on variables
+
+If you're declaring a temporary pointer, declare it Cconst, with the
+const to the right of the C*, to indicate that the pointer should not
+be modified.
+
+Wango * const w = get_current_wango();
+w-min = 0;
+w-max = 14;
+w-name = Ted;
+
+This prevents you from modifying Cw inadvertantly.
+
+new_wango = w++; /* Error */
+
+If you're not going to modify the target of the pointer, put a Cconst
+to the left of the type, as in:
+
+const Wango * const w = get_current_wango();
+if ( n wango-min || n wango-max ) {
+/* do something */
+}
+
+=head3 Localizing variables
+
+Declare variables in the innermost scope possible.
+
+if ( foo ) {
+int i;
+for ( i=0; in; i++ ) {
+do_something(i);
+}
+}
+
+Don't reuse unrelated variables. Localize as much as possible, even if
+the variables happen to have the same names.
+
+if ( foo ) {
+int i;
+for ( i=0; in; i++ ) {
+do_something(i);
+}
+}
+else {
+int i;
+for ( i=14; i0; i-- ) {
+do_something_else(i*i);
+}
+}
+
+You could hoist the Cint i; outside the test, but now you'll have an
+Ci that's visible after it's used, which is confusing at best.
+
=head2 Performance
We want Perl to be fast. Very fast. But we also want it to be portable and
Re: [svn:perl6-synopsis] r8553 - doc/trunk/design/syn
This is perl 6, right?
my %hash; $hash{foo}{bar} - shouldn't it be %hash{foo}{bar}?
On 4/3/06, [EMAIL PROTECTED] [EMAIL PROTECTED] wrote:
Author: autrijus
Date: Mon Apr 3 05:47:07 2006
New Revision: 8553
Modified:
doc/trunk/design/syn/S09.pod
Log:
* S09: Leo pointed out the paragraph on autovivifiction
is still mentioning references. Replace it with modern
wording (surface semantics stays unchanged)
Modified: doc/trunk/design/syn/S09.pod
==
--- doc/trunk/design/syn/S09.pod(original)
+++ doc/trunk/design/syn/S09.podMon Apr 3 05:47:07 2006
@@ -696,9 +696,10 @@
my $val := $hash{foo}{bar};
my @array;
-my $ref = \$array[0][0];
+my $ref = \$array[0][0]; # $ref is an Arguments object - see S02
my %hash;
$hash{foo}{bar} = foo; # duh
-This rule applies to dereferencing arrays, hashes, and scalar references.
+This rule applies to CArray, CHash, and CScalar container objects.
+
Re: [svn:perl6-synopsis] r8553 - doc/trunk/design/syn
On 4/3/06, Amos Robinson [EMAIL PROTECTED] wrote:
This is perl 6, right?
my %hash; $hash{foo}{bar} - shouldn't it be %hash{foo}{bar}?
%hashfoobar even.
Luke
[svn:perl6-synopsis] r8555 - doc/trunk/design/syn
Author: autrijus
Date: Mon Apr 3 15:48:30 2006
New Revision: 8555
Modified:
doc/trunk/design/syn/S06.pod
Log:
* S06: Make it clear that concat-means-concat for duplicated
named arguments, and that it is possible to bind a tuple
into a scalar.
sub fun (Int @x) { ... }
fun( x = (1, 2), x = (3, 4) );# @x := (1, 2, 3, 4)
sub fun (Int $x) { ... }
fun( x = (1, 2), x = (3, 4) );# $x := (3, 4)
Modified: doc/trunk/design/syn/S06.pod
==
--- doc/trunk/design/syn/S06.pod(original)
+++ doc/trunk/design/syn/S06.podMon Apr 3 15:48:30 2006
@@ -423,15 +423,17 @@
to be concatenated:
sub fun (Int @x) { ... }
-fun( x = 1, x = 2 ); # @x := (1, 2)
+fun( x = 1, x = 2 ); # @x := (1, 2)
+fun( x = (1, 2), x = (3, 4) );# @x := (1, 2, 3, 4)
Other sigils binds only to the Ilast argument with that name:
sub fun (Int $x) { ... }
-f( x = 1, x = 2 );# $x := 2
+f( x = 1, x = 2 );# $x := 2
+fun( x = (1, 2), x = (3, 4) );# $x := (3, 4)
-This means a defaults must come Ibefore known named parameters,
-similar to how hash constructors work:
+This means a hash holding default values must come Ibefore known named
+parameters, similar to how hash constructors work:
# Allow x and y in %defaults be overrided
f( *%defaults, x = 1, y = 2 );
[svn:perl6-synopsis] r8556 - doc/trunk/design/syn
Author: larry
Date: Mon Apr 3 15:59:38 2006
New Revision: 8556
Modified:
doc/trunk/design/syn/S09.pod
Log:
Fixed P5isms in P6 code.
Modified: doc/trunk/design/syn/S09.pod
==
--- doc/trunk/design/syn/S09.pod(original)
+++ doc/trunk/design/syn/S09.podMon Apr 3 15:59:38 2006
@@ -688,18 +688,18 @@
In Perl 6 these read-only operations are indeed non-destructive:
my %hash;
-exists $hash{foo}{bar}; # %hash is still empty
+exists %hashfoobar; # %hash is still empty
But these ones Ido autovivify:
my %hash;
-my $val := $hash{foo}{bar};
+my $val := %hashfoobar;
my @array;
-my $ref = \$array[0][0]; # $ref is an Arguments object - see S02
+my $ref = [EMAIL PROTECTED]; # $ref is an Arguments object - see S02
my %hash;
-$hash{foo}{bar} = foo; # duh
+%hashfoobar = foo; # duh
This rule applies to CArray, CHash, and CScalar container objects.
Re: Where did I see this use of plan()?
Yitzchak Scott-Thoennes wrote:
I remember working with some module that had tests something like:
use Test::More;
plan tests = numtests();
...
is($foo, $bar, 'foo is bar');
sub numtests { 13 }
So that when you added a new test to the bottom, the number to modify
was right there also. Ring a bell with anyone?
Googling reveals several instances of
plan tests = $numtests;
where $numtests is the result of some calculation. So there doesn't
appear to be anything preventing your approach. Just remember that, if
coded as per your example, there cannot be any tests inside BEGIN blocks
in the test file, because your call to 'plan' will miss such tests
(unless it's first in the BEGIN block).
jimk
Re: Where did I see this use of plan()?
Yitzchak Scott-Thoennes wrote:
I remember working with some module that had tests something like:
use Test::More;
plan tests = numtests();
...
is($foo, $bar, 'foo is bar');
sub numtests { 13 }
So that when you added a new test to the bottom, the number to modify
was right there also. Ring a bell with anyone?
Didn't see that one, but if you want to simplify the count of the
number of tests, a simple solution is to use BEGIN blocs:
use Test::More;
my $tests;
plan tests = $tests;
BEGIN { $tests += XX }
# bloc of tests
# ...
BEGIN { $tests += XX }
# bloc of tests
# ...
Sébastien Aperghis-Tramoni
-- - --- -- - -- - --- -- - --- -- - --[ http://maddingue.org ]
Close the world, txEn eht nepO
Re: Module requirements (was: Module::Build and installing in non-standardlocations)
Tels wrote: Moin, Hello Tels, OTOH, who still runs pre-5.8.x code deserves what they get. There are horrible bugs in older Perls, and I don't know why people still insist using insecure, buggy and feature-lacking code like 5.6. or even gasp 5.004. Just think Unicode support, hash randomization, memory leaks. You forget that there's more than one way to use Perl :-) When Perl is used for sysadmin tasks, most of the features you listed (and I could add threads support, new IO implementation, signals handling, subroutines attributes) are of no to little use because such Perl scripts are run for executing tasks that do not require advanced Perl features like those just listed. Remember that on Unix systems, Perl is like Bash, Sed and Awk, only more powerful (even if it's by one or two orders). Do you replace your /bin/sh on your Solaris with the latest Bash just because it has very new and cool features? Usually you can't. Mainly because it could break things, and has little to no added value. Using these older Perls means you basically show the hard-working Perl5-Porters that you don't care for their work in improving Perl. But the Perl interpreter (which is what the P5Porters are working on) and the Perl modules are mostly disconnected (*). Where would be the interest to use an interpreted language if it were tied to a specific version of the interpreter? Most Perl code out there don't require recent features. To continue with my previous analogy, there are also many people that work hard on the Linux kernel, the GNU system, and all the different parts that compose a GNU/Linux distribution, but when a server is in production, you can't upgrade it at your wish. (*) Yes, I know that the core Perl distribution includes many modules, but ask any P5Porter and he'll answer you that the core is over-crowed and that all core modules that can be made dual-life should be released on the CPAN. I know, now people will come out of the wood and say that they have that old system, and no, they can't upgrade Perl etc, never touch a running system etc yadda yadda. But what the heck do you then try to upgrade modules on said system when you didn't want to touch the system? My current $work is to write a Perl program that must execute on about 1200 Linux servers, with Perl versions ranging from 5.004 to 5.8. I can't upgrade Perl on these because they have different kernel / glibc / gcc versions. But that's not a problem because I don't need to upgrade Perl or the modules on said systems, just to put the modules I need in a directory and use lib /that/directory. Of course I need to use modules that work with 5.004, or patch them so they work with 5.004, but you could be surprised to see how little some of the patches are. Can be as simple as removing require 5.6 (as for File::Temp). Most of the patches I've sent were less than 10 lines of differences. Sébastien Aperghis-Tramoni -- - --- -- - -- - --- -- - --- -- - --[ http://maddingue.org ] Close the world, txEn eht nepO
Re: Module requirements (was: Module::Build and installing in non-standardlocations)
Sébastien Aperghis-Tramoni [EMAIL PROTECTED] wrote: OTOH, who still runs pre-5.8.x code deserves what they get. There are horrible bugs in older Perls, and I don't know why people still insist using insecure, buggy and feature-lacking code like 5.6. or even gasp 5.004. Just think Unicode support, hash randomization, memory leaks. FWIW I've heard at least one valid argument for sticking with 5.6, and that actually is unicode support. :-) Apparently, in 5.6 regular expressions don't have full unicode support. But in 5.8 the regexp unicode stuff is expensive. And to make matters worse, if anything in any package that you import uses unicode, the new, slower unicode regular expression algorithm is applied to *everything* and there's no easy way to turn that off. This is just a nasty rumour I'm sure, but I've heard it multiple times from multiple people. I like to stay on the cutting edge and if my regexps are too slow, I'll find some other way to do it. :-) Cheers, Tyler
Re: [PATCH] My first patch, for builtins.*
On Sunday 02 April 2006 21:17, Andy Lester wrote: Here's my first patch. Let me know if y'all see this sort of work as useful, or if I shouldn't bother. Please continue. In the next round of their scans, Coverity may add Parrot to the list of projects. For various annoying reasons, I can't do it, but running CPD over the code could reveal a lot of interesting information: http://xrl.us/hq45 -- c
Re: [svn:parrot-pdd] r12104 - trunk/docs/pdds/clip
On Monday 03 April 2006 13:29, [EMAIL PROTECTED] wrote: Modified: trunk/docs/pdds/clip/pdd07_codingstd.pod === === --- trunk/docs/pdds/clip/pdd07_codingstd.pod (original) @@ -760,6 +761,79 @@ TBC ... Any contributions welcome !!! +=head2 Defensive programming + +=head3 The Cconst keyword on arguments + +Use the Cconst keyword as often as possible on pointers. It lets +the compiler know when you intend to modify the contents of something. Perhaps ... do not intend to modify...? -- c
Re: curly-quotes
On Sun, Apr 02, 2006 at 02:32:03AM -0800, Jonathan Lang wrote: : Given perl6's use of unicode as a basis, could we get curly quotes, : both single and double, to do the same things that straight quotes do? Depends on what same thing means, I suppose. Looks like you want them directional, which is not exactly the same thing. An argument could also be made for simply treating them all as the same character. That being said... : That is: text does the same thing as text, and 'text' does the : same thing as 'text'. Other than looks neat, why do this? Because : curly-quotes come in matching sets, like parentheses and brackets do; : this lets you nest them. Hmm, yes. That would be nice. But then, any number of bracketing characters would be nice to steal from non-Latin-1 Unicode, and we're trying to restrain ourselves for the moment. Because... : (This seems so simple and obvious that I'll be surprised if someone : hasn't already proposed this; however, I don't recall seeing it : anywhere.) Either your mailer or some MTA along the way seems to have silently and oh-so-helpfully converted your pretty curly quotes to ASCII quotes. And therein lies the (hopefully short-term) problem with getting beyond Latin-1. Not that we can't support the higher characters, but that the current infrastructure will *silently* introduce bugs when you send such code around. It's even a little bit risky sending Latin-1, but at least that tends to produce complete gobbldygook when it fails. So the best we could do right now with the quotes would be to allow them but to require you not to use them with semantics different from plain ASCII double quotes. Makes me wonder whether we can set up some automated way to at least detect such accidental de-unicodification. Even just knowing the maximum intended codepoint in the message might help detect most such errors. Or even just knowing that *any* characters above 255 were intended... Larry
Context and coercion
Kudos to all on the Perl 6 mailing list, What's the conceptual difference (or relationship) between context and type coercion? Is $moose.prefix:~ the same as $moose.coerce:as(Str) for instance? And forgive my brain, but how would you nicely define coercion in a class? Like, could you spare an example? Also, what's the point of making a whole grammatical category for coerce that behaves like an infix operator? Thanks in advance.
Re: Context and coercion
On Mon, Apr 03, 2006 at 07:23:28PM -0700, Joshua Choi wrote:
: Kudos to all on the Perl 6 mailing list,
:
: What's the conceptual difference (or relationship) between context and type
: coercion? Is
: $moose.prefix:~
: the same as
: $moose.coerce:as(Str)
: for instance?
No difference.
: And forgive my brain, but how would you nicely define coercion in a class?
: Like, could you spare an example?
Currently something like:
multi submethod infix:as ($self: Str) {...}
multi submethod infix:as ($self: Int) {...}
or
multi sub infix:as (MyClass $self, Str) {...}
multi sub infix:as (MyClass $self, Int) {...}
: Also, what's the point of making a whole grammatical category for coerce
: that behaves like an infix operator?
In the current synopses there is no coerce grammatical category
any more. Everything is subsumed under infix:as, at least this week...
There's some discussion about whether it should simply be:
method as (Str) {...}
method as (Int) {...}
maybe with an is deep thrown in for good measure, but we haven't
quite got there yet.
Larry
Re: Context and coercion
On Mon, Apr 03, 2006 at 08:24:51PM -0700, Larry Wall wrote:
: There's some discussion about whether it should simply be:
:
: method as (Str) {...}
: method as (Int) {...}
:
: maybe with an is deep thrown in for good measure, but we haven't
: quite got there yet.
Er, to have multiple of them in the same class, that would of course
have to be:
multi method as (Str) {...}
multi method as (Int) {...}
Generally, I love to travel. Specifically, I love the fact that
jet lag is a such a convenient excuse for stupidity.
Larry
Re: Module requirements (was: Module::Build and installing in non-standardlocations)
On 4/4/06, Tyler MacDonald [EMAIL PROTECTED] wrote: Sébastien Aperghis-Tramoni [EMAIL PROTECTED] wrote: OTOH, who still runs pre-5.8.x code deserves what they get. There are horrible bugs in older Perls, and I don't know why people still insist using insecure, buggy and feature-lacking code like 5.6. or even gasp 5.004. Just think Unicode support, hash randomization, memory leaks. FWIW I've heard at least one valid argument for sticking with 5.6, and that actually is unicode support. :-) Apparently, in 5.6 regular expressions don't have full unicode support. But in 5.8 the regexp unicode stuff is expensive. And to make matters worse, if anything in any package that you import uses unicode, the new, slower unicode regular expression algorithm is applied to *everything* and there's no easy way to turn that off. This is just a nasty rumour I'm sure, but I've heard it multiple times from multiple people. I like to stay on the cutting edge and if my regexps are too slow, I'll find some other way to do it. :-) I dont believe that this is correct. The regex engine uses UTF8 logic if the pattern is UTF8 or if the string is UTF8. If both are ascii then it uses ascii logic only. Yves -- perl -Mre=debug -e /just|another|perl|hacker/
