in reply to Re: Re: Re: Re: Re: Breaking output lines into N-element chunks
in thread Breaking output lines into N-element chunks
Do a grep of site/lib and you'll see just how common that idiom is. I think youll be suprised.
I did grep my module directories and I am surprised. I am surprised that so many constants do exist :)
I think you might be surprised as well...2;0 juerd@ouranos:/usr/lib/perl$ perl -pe'$_ = "" unless /sub\s+[A-Z_] ++\s*\(\s*\)/' * */* */*/* */*/*/* | wc -l 1094 # Sorry for the ugly */*-stuff. I didn't feel like # using File::Find in a oneliner :)
In /usr/share/perl, you would be right. There are 47 use constants in my /usr/share/perl, and only 24 empty-prototype all-caps subroutines.2;0 juerd@ouranos:/usr/lib/perl$ perl -pe'$_ = "" unless /use\s*consta +nt/' * */* */*/* */*/*/* | wc -l 0
The fact is that these "constants" (they arent really so lets be careful with that term) will not behave as expected in about 5% of situations.
The constant pragma uses the exact same method, only in a more convoluted way. It's _ONLY_ syntax (or call it "style" if you think that's a more appropriate word).
Out of constant.pm:
As you can see, there's nothing wrong with the empty prototype sub.if (@_ == 1) { my $scalar = $_[0]; *$full_name = sub () { $scalar }; } elsif (@_) { my @list = @_; *$full_name = sub () { @list }; } else { *$full_name = sub () { }; }
Its your job as a developer to anticipate _everything_ including the skill levels of those that come after you.
I refuse to. Perl has many nifty features, and I'm not going to avoid them just because my code might be maintained by someone without programming knowledge. Take regexes for example: how many people will understand regexes but not simple constant idioms? Do I have to avoid regexes because they're hard to read for beginning regex hackers? Must I not use map, because the majority of Perl beginners doesn't know how it works? Should programmers avoid object orientation in favor of PHP-like code (I don't know why, but beginners seem to like PHP's simplicity)? Do you mean we should write our own alternatives to pack and unpack just because we should anticipate _everything_?
Sorry, but I find that a bit hard to accept. If I liked bondage like that, I would still be coding in BASIC, and I would have never used Perl's flexibility :).
Frankly juerd im a little disappointed about your reply
That was in no way my intention. I do however think you miss a great deal of Perl knowledge if you don't recognise the empty-prototype return-only constant idiom. I hope we both learned.
Yes, I reinvent wheels.
|
|---|