in reply to Breaking output lines into N-element chunks
forget all this join and % business... use the nice perl-supplied variables!
#!/usr/bin/perl -w
use strict;
$|++;
my @a = qw/v0 v1 v2 v3 v4 v5/;
sub LIMIT () { 4 }
while(scalar @a)
{
local $,=' ';
print 'd:', splice(@a,0,LIMIT), $/;
}
Update: made changes caught by Juerd (below)
~Particle ;Þ
Re: Re: Breaking output lines into N-element chunks
by Juerd (Abbot) on Apr 11, 2002 at 21:06 UTC
|
sub LIMIT { 4 }
What is the point in defining LIMIT when you don't use it? :) Oh, and adding an empty prototype makes your LIMIT inlineable, which will increase speed (okay, in scripts like these you'll hardly notice the difference, but hey, it's only two extra characters (or three if you want whitespace, like I do)).
sub LIMIT () { 4 }
No, this is not a bad use of prototypes. Actually, this is a very good feature which allows for constants to be used (the constant pragma does the same)
use constant LIMIT => 4;
I don't like that syntax, though, so I stick to subs with empty prototypes.
Yes, I reinvent wheels.
| [reply] [Watch: Dir/Any] [d/l] [select] |
|
| [reply] [Watch: Dir/Any] |
|
I don't like that syntax, though, so I stick to subs with empty prototypes
While I agree with you that the constant syntax is not that nice I believe that in the long run you are probably doing yourself a disservice with not using it.
The advantage of using constant is that it clearly announces to a maintainence coder or equiv what is going on. They would need to be fairly experienced to know what the purpose is of such an unusual looking sub, and if they were like me might even remove the prototype on principle.
A second point is that by using the module you are implicitly documenting what you are doing. Not just on a literal programming level but also simply on the level that the maintainence coder can then review constant.pm documentation and see that there _are_ quirks with this technique. Now these quirks apply whether you do it by hand or by using contant.pm, the only difference being that if you do all your constants by hand its up to YOU to document these quirks to future programmers.
Being a lazy type, especially when it comes to documentation I would use constant.pm for this reason alone...
Yves / DeMerphq
---
Writing a good benchmark isnt as easy as it might look.
| [reply] [Watch: Dir/Any] |
|
unusual looking sub
If subs with empty prototypes and only a return value are unsual looking to you, better read some Perl :) It's one of the most occuring idioms, very useable, fast and reasonably clear.
Besides, ALLCAPS names often indicate constants too, and if you don't recognise it as a constant, ANY coder (not just Perl coders) should be able to deduct its meaning within a matter of seconds.
its up to YOU to document these quirks to future programmers.
Anyone who doesn't see it's a constant (single return value, empty prototype, name in ALLCAPS, defined before any other sub and often found in @EXPORT), should not be maintaining my code. I like my code to be maintained by programmers, not HTML monkeys. If someone hires a non-coder to do code maintenance, that's not my problem :). And when it does become my problem, I get paid for it ;).
No offense meant.
Yes, I reinvent wheels.
| [reply] [Watch: Dir/Any] |
|
|
|
while i agree with you that using the constant module (pragma?) is better for maintainence, i don't like the syntax at all. i'd prefer syntax like
use MyConstant;
MyConstant LIMIT { 4 };
which would create a sub named LIMIT with an empty prototype. unfortunately, i don't know how to do this. i think a well-written module with this functionality would satisfy both syntax and maintainence issues.
can someone point me in the right direction towards writing a module like this?
~Particle ;Þ
| [reply] [Watch: Dir/Any] [d/l] |
|
|
|