... ale zly pan. Damian Conway dokonce v Perl Best Practices doporucuje prototypy vubec nepouzivat, snad krome pripadu kdy je treba simulovat chovani nejake vestavene veci. Prototypy maji totiz jednu podstatnou nevyhodu - prototypove funkci nemuzu rozumne predavat vic parametru expanzi jednoho pole, neco jako
sub mojefunkce {
my ($mujarg, @zbytek) = @_;
my $rv = jina_funkce(@zbytek);
}
kde me vubec nezajima, jake dalsi parametry mojefunkce() dostane, jejich semantika je "dejte mi cokoli co mam poslat do jina_funkce()". Pokud by jina_funkce() mela prototyp, mam problem.
Navic teda prototypy maji dalsi nevyhodu, ze se nad svoji definici chovaji jinak nez pod ni, cili zalezi na umisteni te funkce v kodu.
Je dobre je znat, ale pro jejich pouziti je treba mit _fakt_ dobry duvod a ne je sekat automaticky uplne vsude.
V PBP se doporucuje spousta veci, ale tento dil Perlicek je spise o tom, co se z toho da vyzdimat. (Minuly dil mel taky tuto povahu, ale az do predminuleho dilu se clanky vicemene ridily PBP a dalsimi "korektnimi" pravidly.)
Ten problem u jina_funkce jsem moc nepochopil. Pokud udelate prototyp obou funkci jako (@) tak zadny problem nebude. Eventuelne muze byt jeste mojefunkce ($@).
S umistenim prototypu mate pravdu, zapomnel jsem uvest ze samozrejme prototyp funkce musi byt znamy v dobe jeho volani a to jiz pri kompilaci.