Back To Schedule
Tuesday, June 8 • 16:30 - 17:20
Refactoring your EXPORTS: Rescuing a client from global-variale-hell.

Sign up or log in to save this to your schedule, view media, leave feedback and see who's attending!

Feedback form is now closed.
At first @EXPORT seemed natural, at least to  C programmers: Everyone sees everything, uses what they need. Fast forward a few decades, with a GlobalVariableModule that can't be modified because nobody knows what is really used. This is the story of what to do next.

What's next is a sequence of converting it all from @EXPORT to @EXPORT_OK and refactoring the contents into saner modules with external configurations using objects. One stage is appreciating the patterns and structure of 600 variables defined in terms of one another, another is extracting that into YAML structs [with comments], another is re-exporting it all via that most beautiful and under-appreciated of Perly tools: Symbol. The final conversion replaces @EXPORT with @EXPORT_OK so that we know what is actually being exported... which is probably a reasonable chunk of code for 40 minutes. Converting @EXPORT_OK imports to configuration-object calls isn't all that complicated. Part of the technique involves global unit testing (see my other talk) that allows tracking down what's missing when @EXPORT becomes just OK.

This matters because too many places are stuck on v5.8 because they don't actually know how to validate their code moving forward; they no longer know what it does. What this one case shows is how to get over the hump and start moving forward on a route to more modern, validated, documented code.

avatar for Steven Lembark

Steven Lembark

Yo!, Workhorse Computing
I've been working with Perl since the 1990's, using it for everything but salads -- texture isn't quite right. Most of my work with Perl has been with web back ends, financial data, bioinformatics, sysadmin/DBA utilities, ETL, automation, and occasionally flying a quad-copter.

Tuesday June 8, 2021 16:30 - 17:20 EDT
Zoom Room 1