Responding to your references to modules, we haven't used them because we can't count on them being there. Obviously my problem, not yours. =)
Thanks for the response. - Bryan > Hi Bryan > > It's a bit lengthy, but I hope it motivates you a bit to look around... > >> You mention larger projects, and I've heard about "reusable code"... Is >> that generally done by copy/paste into the script you're working on? > > Code copied&pasted around is a candidate for a perl module, the perlish > variant of libraries. > >> Or is >> there a way to somehow "compile" like C does where it will gather chunks >> from a library and stuff them together into a single script? > > You stuff the modularized code together by > > use SomeModule; > use AnotherModule; > > into different scripts (instead of copy&paste what's in the modules). > > If you detect an error, you can "simply" (means: if no side effects have been > worked around outside the module...) correct it in the module and don't have > to "oh shit, into which of my scripts did I copy the error made 3 years > ago?!?". > > Modules should have an as easy, logical, minimal, "problem-covering", > natural,... API as possible :-) > They hide complex code and make it possible to change the implementation. > > Sorting algorithms are a good example to modularized/encapsulate into modules. > A fake example code snippet: > > use MySortStrategy 'sort'; # line A > my @sorted=sort(@some_unsorted_data); > > If you want to use another sort strategy, you simply change line A to > > use MyOtherSortStrategy 'sort'; > > The point here is that the implementation is separated from usage. > > Another fake example with another approach: > > use MyGenericSort 'sort'; > my @sorted1=sort(-strategy=>'quicksort', -data=>[EMAIL PROTECTED]); > my @sorted2=sort(-strategy=>'bubblesort', -data=>[EMAIL PROTECTED]); > >> I ask because >> portability is huge for me, I have to produce single standalone scripts >> that work on any of various unices. > > That's a good occasion to abstract the differences between the unices and > "hide" them behind a common API. An example for that is the module > > File::Spec - portably perform operations on file names. > > [...] > > Or look at the Storable module: > No need the explicitly code the storing of different data structures to a file > every time! Just give the arbitrary complex perl data structure to one of the > subroutines provided and saving is done with one line of code. > > The object oriented paradigma allows for again more resusability... > > Check the perl documentation > > perldoc perl > > Look at the mass of modules on search.cpan.org, and there are certainly lots > of online resources in english available (which I don't have handy). > > hth, > Hans > > > -- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] <http://learn.perl.org/> <http://learn.perl.org/first-response>
