perl -e "$SIG{INT}= sub {print 'Hello';exit;};for ($i=0;$i<30;$i++){sleep 1;}; print 'bye';"
[ add comment ] | permalink |
( 2.6 / 122 )Remove repeated characters from a string - http://www.perlmonks.org/?node_id=353072
How to find and remove duplicate elements from an array? - http://www.perlmonks.org/?node_id=90493
perlfaqs - http://perldoc.perl.org/perlfaq4.html
perl references - http://www.sdsc.edu/~moreland/courses/I ... rlref.html
perl tuts - http://perldoc.perl.org/index-tutorials.html
[ add comment ] | permalink |
( 2.8 / 26 )The variables declared with my() are visible only within the scope of the block which names them. They are not visible outside of this block, not even in routines or blocks that it calls.
local() variables, on the other hand, are visible to routines that are called from the block where they are declared.
Neither is visible after the end (the final closing curly brace) of the block at all.
Whereas our() has Package scope.
[ add comment ] | permalink | related link |
( 3 / 20 )If constructors can have arbitrary names, then why not destructors? Because while a constructor is explicitly called, a destructor is not. Destruction happens automatically via Perl's garbage collection (GC) system, which is a quick but somewhat lazy reference-based GC system. To know what to call, Perl insists that the destructor be named DESTROY. Perl's notion of the right time to call a destructor is not well-defined currently, which is why your destructors should not rely on when they are called.
Why is DESTROY in all caps? Perl on occasion uses purely uppercase function names as a convention to indicate that the function will be automatically called by Perl in some way. Others that are called implicitly include BEGIN, END, AUTOLOAD, plus all methods used by tied objects, described in the perltie manpage.
[ add comment ] | permalink |
( 3 / 62 )Like the special per-package variables recognized by Exporter (such as @EXPORT, @EXPORT_OK, @EXPORT_FAIL, %EXPORT_TAGS, and $VERSION), the @ISA array must be a package-scoped global and not a file-scoped lexical created via my(). Most classes have just one item in their @ISA array. In this case, we have what's called ``single inheritance'', or SI for short.
Consider this class:
package Employee;
use Person;
@ISA = ("Person");
1;
Not a lot to it, eh? All it's doing so far is loading in another class and stating that this one will inherit methods from that other class if need be. We have given it none of its own methods. We rely upon an Employee to behave just like a Person.
[ add comment ] | permalink |
( 3 / 65 )sub new {
my $self = {};
$self->{NAME} = undef;
$self->{AGE} = undef;
$self->{PEERS} = [];
bless ($self);
return $self;
}
[ add comment ] | permalink | related link |
( 2.8 / 78 )Autovivification is a distinguishing feature of the Perl programming language involving the dynamic creation of data structures. Autovivification is the automatic creation of a variable reference when an undefined value is dereferenced. In other words, Perl autovivification allows a programmer to refer to a structured variable, and arbitrary sub-elements of that structured variable, without expressly declaring the existence of the variable and its complete structure beforehand.
In contrast, other programming languages either: 1) require a programmer to expressly declare an entire variable structure before using or referring to any part of it; or 2) require a programmer to declare a part of a variable structure before referring to any part of it; or 3) create an assignment to a part of a variable before referring, assigning to or composing an expression that refers to any part of it.
[ add comment ] ( 1 view ) | permalink | related link |
( 3 / 43 )If I do a LEFT JOIN, I get all records that match in the same way and IN ADDITION I get an extra record for each unmatched record in the left table of the join - thus ensuring (in my example) that every PERSON gets a mention:
mysql> select name, phone, selling
from demo_people left join demo_property
on demo_people.pid = demo_property.pid;
If I do a RIGHT JOIN, I get all the records that match and IN ADDITION I get an extra record for each unmatched record in the right table of the join - in my example, that means that each property gets a mention even if we don't have seller details:
mysql> select name, phone, selling
from demo_people right join demo_property
on demo_people.pid = demo_property.pid;
An INNER JOIN does a full join, just like the first example, and the word OUTER may be added after the word LEFT or RIGHT in the last two examples - it's provided for ODBC compatibility and doesn't add an extra capabilities.
[ add comment ] ( 1 view ) | permalink | related link |
( 3 / 35 )There are rare occasions when you do want to export methods or variable names into the calling package. I only do this occasionally for static helper methods I need very, very often. In order to export symbols, inherit from the Exporter class and fill the @EXPORT array with the symbols you'd like to export:
package Util;
use base 'Exporter';
our @EXPORT = ('foo', 'bar');
Try not to pollute another package's namespace unless you have a very good reason for doing so! Most packages on CPAN explicitly state which symbols get exported with their use, if any.
It might be a good idea to leave it up to the requiring package to decide which symbols get exported into its namespace. In that case you simply use the @EXPORT_OK array instead or @EXPORT.
package Util;
use base 'Exporter';
our @EXPORT_OK = ('foo', 'bar');
[ add comment ] ( 1 view ) | permalink | related link |
( 3 / 20 )USE
Imports some semantics into the current package from the named
module, generally by aliasing certain subroutine or variable
names into your package. It is exactly equivalent to
BEGIN { require Module; import Module LIST; }
except that Module *must* be a bareword.
The "BEGIN" forces the "require" and "import" to happen at
compile time. The "require" makes sure the module is loaded into
memory if it hasn't been yet. The "import" is not a
builtin--it's just an ordinary static method call into the
"Module" package to tell the module to import the list of
features back into the current package. The module can implement
its "import" method any way it likes, though most modules just
choose to derive their "import" method via inheritance from the
"Exporter" class that is defined in the "Exporter" module. See
Exporter. If no "import" method can be found then the call is
skipped.
REQUIRE
Otherwise, demands that a library file be included if it hasn't
already been included. The file is included via the do-FILE
mechanism, which is essentially just a variety of "eval". Has
semantics similar to the following subroutine:
sub require {
my ($filename) = @_;
if (exists $INC{$filename}) {
return 1 if $INC{$filename};
die "Compilation failed in require";
}
my ($realfilename,$result);
ITER: {
foreach $prefix (@INC) {
$realfilename = "$prefix/$filename";
if (-f $realfilename) {
$INC{$filename} = $realfilename;
$result = do $realfilename;
last ITER;
}
}
die "Can't find $filename in \@INC";
}
if ($@) {
$INC{$filename} = undef;
die $@;
} elsif (!$result) {
delete $INC{$filename};
die "$filename did not return true value";
} else {
return $result;
}
}
Note that the file will not be included twice under the same
specified name.
The file must return true as the last statement to indicate
successful execution of any initialization code, so it's
customary to end such a file with "1;" unless you're sure it'll
return true otherwise. But it's better just to put the "1;", in
case you add more statements.
[ add comment ] ( 1 view ) | permalink |
( 3 / 20 )
Calendar
