in reply to Re^2: Module design for loadable external modules containing data
in thread Module design for loadable external modules containing data

You are correct in your assessment of File::ShareDir: it is predominantly for access to static data.

Your modules should still contain program logic as usual; tests should still be written as usual. All of your static data (e.g. "discourses, assignements, questions") can be handled by File::ShareDir.

I envisioned some sort of get_text() method implemented at the ParentClass level (from my rough UML example). So, your 001 line would become something like:

001 => { type => 'text', content => 'strict_intro.txt' }

Blocks of embedded text can be removed from the module code and replaced with filenames. These can be accessed along the lines of: get_text($hash{001}{content}).

Now, your text can be available to multiple modules. Changes to that text — whether a simple typo fix, addition of new paragraphs, or a complete rewrite — need only be done in one place (i.e. strict_intro.txt). No code changes are required in any modules. This eliminates a very real source of potential errors: introducing new typos in one or more places; forgetting to modify one or more modules; breaking source code with some newly introduced punctuation character in the text; and so on.

In addition, this will reduce the size of modules and therefore the memory footprint when they are loaded. This can be further improved upon with just-in-time mechanisms; for instance, only accessing strict_intro.txt when the student clicks on "Show the strictures intro" (or otherwise requests that information).

"As you can see it is very ugly."

Removing hard-coded text would certainly be a step in the right direction.

Looking at your pseudocode, another improvement presents itself. You have your steps implemented as an array; the contents of that array is really a hash; the keys of that hash are a sequence of numbers which could easily be derived from the array index. That would look a lot cleaner as:

[ { ... simple text ... }, { ... check script ... }, { ... complex text ... }, ]

While I do appreciated that what you presented was pseudocode, this would be the type of thing to look for on the path to beautification.

— Ken