# # spec file for package perl-Carp-Assert # # Copyright (c) 2015 SUSE LINUX GmbH, Nuernberg, Germany. # # All modifications and additions to the file contributed by third parties # remain the property of their copyright owners, unless otherwise agreed # upon. The license for this file, and modifications and additions to the # file, is the same license as for the pristine package itself (unless the # license for the pristine package is not an Open Source License, in which # case the license is the MIT License). An "Open Source License" is a # license that conforms to the Open Source Definition (Version 1.9) # published by the Open Source Initiative. # Please submit bugfixes or comments via http://bugs.opensuse.org/ # Name: perl-Carp-Assert Version: 0.21 Release: 143.18 %define cpan_name Carp-Assert Summary: executable comments License: Artistic-1.0 or GPL-1.0+ Group: Development/Libraries/Perl Url: http://search.cpan.org/dist/Carp-Assert/ Source: http://www.cpan.org/authors/id/N/NE/NEILB/%{cpan_name}-%{version}.tar.gz BuildArch: noarch BuildRoot: %{_tmppath}/%{name}-%{version}-build BuildRequires: perl BuildRequires: perl-macros BuildRequires: perl(Test::More) >= 0.88 %{perl_requires} %description "We are ready for any unforseen event that may or may not occur." - Dan Quayle Carp::Assert is intended for a purpose like the ANSI C library http://en.wikipedia.org/wiki/Assert.h. If you're already familiar with assert.h, then you can probably skip this and go straight to the FUNCTIONS section. Assertions are the explicit expressions of your assumptions about the reality your program is expected to deal with, and a declaration of those which it is not. They are used to prevent your program from blissfully processing garbage inputs (garbage in, garbage out becomes garbage in, error out) and to tell you when you've produced garbage output. (If I was going to be a cynic about Perl and the user nature, I'd say there are no user inputs but garbage, and Perl produces nothing but...) An assertion is used to prevent the impossible from being asked of your code, or at least tell you when it does. For example: # Take the square root of a number. sub my_sqrt { my($num) = shift; # the square root of a negative number is imaginary. assert($num >= 0); return sqrt $num; } The assertion will warn you if a negative number was handed to your subroutine, a reality the routine has no intention of dealing with. An assertion should also be used as something of a reality check, to make sure what your code just did really did happen: open(FILE, $filename) || die $!; @stuff = ; @stuff = do_something(@stuff); # I should have some stuff. assert(@stuff > 0); The assertion makes sure you have some @stuff at the end. Maybe the file was empty, maybe do_something() returned an empty list... either way, the assert() will give you a clue as to where the problem lies, rather than 50 lines down at when you wonder why your program isn't printing anything. Since assertions are designed for debugging and will remove themelves from production code, your assertions should be carefully crafted so as to not have any side-effects, change any variables, or otherwise have any effect on your program. Here is an example of a bad assertation: assert($error = 1 if $king ne 'Henry'); # Bad! It sets an error flag which may then be used somewhere else in your program. When you shut off your assertions with the $DEBUG flag, $error will no longer be set. Here's another example of *bad* use: assert($next_pres ne 'Dan Quayle' or goto Canada); # Bad! This assertion has the side effect of moving to Canada should it fail. This is a very bad assertion since error handling should not be placed in an assertion, nor should it have side-effects. In short, an assertion is an executable comment. For instance, instead of writing this # $life ends with a '!' $life = begin_life(); you'd replace the comment with an assertion which *enforces* the comment. $life = begin_life(); assert( $life =~ /!$/ ); %prep %setup -q -n %{cpan_name}-%{version} %build %{__perl} Makefile.PL INSTALLDIRS=vendor %{__make} %{?_smp_mflags} %check %{__make} test %install %perl_make_install %perl_process_packlist %perl_gen_filelist %files -f %{name}.files %defattr(-,root,root,755) %doc Changes README %changelog * Mon Apr 13 2015 coolo@suse.com - updated to 0.21 see /usr/share/doc/packages/perl-Carp-Assert/Changes * Thu Nov 17 2011 coolo@suse.com - regenerate with cpanspec 1.78.05 * Tue Aug 30 2011 andrea.turrini@gmail.com - standardized "Authors:" format in description of perl-Carp-Assert.spec * Tue Nov 30 2010 coolo@novell.com - switch to perl_requires macro * Tue Mar 9 2010 chris@computersalat.de - cleanup spec o dep perl-macro o Provides * Sun Jan 10 2010 jengelh@medozas.de - enable parallel build * Sat Jul 25 2009 chris@computersalat.de - spec mods * removed ^---------- * removed ^#--------- * Sun Jun 28 2009 chris@computersalat.de - added perl-macros o autogen filelist with perl_gen_filelist - spec mods o fixed deps * Tue Jan 9 2007 anicka@suse.cz - update to 0.20 * The tests will no longer fail should the user have NDEBUG or PERL_NDEBUG environment variables set * Update the license link to point to the whole Perl license, not just the Artistic license. * Fixed installation for those who have Pod::Tests but pod2test is not in their PATH as some CPAN shell configurations do. * Wed Jan 25 2006 mls@suse.de - converted neededforbuild to BuildRequires * Fri Aug 13 2004 mjancar@suse.cz - update to 0.18 * Sun Jan 11 2004 adrian@suse.de - build as user * Fri Aug 22 2003 mjancar@suse.cz - require the perl version we build with * Tue Jul 15 2003 mjancar@suse.cz - adapt to perl-5.8.1 - use %%perl_process_packlist * Wed Jun 18 2003 coolo@suse.de - package directories * Tue May 20 2003 mjancar@suse.cz - remove unpackaged files * Mon Jul 29 2002 mls@suse.de - Fixed neededforbuild for perl-5.8.0 * Tue Jul 2 2002 mls@suse.de - remove race in .packlist generation * Wed Jan 2 2002 cihlar@suse.cz - update to version 0.17 * Tue Aug 14 2001 rvasice@suse.cz - initial package release (version 0.13)