Packages and modules and files: oh boy

[ajmalton]

We have five packages (missa, horas, horas::Scripting, DivinumOfficium::Main, DivinumOfficium::FileIO) and 13 files (the rest of horas/... and missa/...) which have no package but are required at run time. This is too many packages(!), and most of the globals belong to missa when missa is running but to horas when horas is running.

Fajne to bałagan.

I've been arranging horas/ so that the code runs under stricture and all warnings: and it’s done! although not put in production, of course. It involved adding about 600 new declarations, and about 100 other changes, mostly to distinguish undefined from empty (since in warnings mode, they are different).

But... now everything horas/... is horas:: and that's good and tidy, but of course it doesn't work with missa:: any more because the variables are all rescoped at run time. In fact the division between missa:: and horas:: has given rise to the cloned kalendar and setup and popup etc which have diverged in the two packages, quite unnecessarily.

Either

• missa:: and horas:: have to become a single package (and the files in missa/ and horas/ brought together into one directory, and the URLs change) or
• the uses by missa:: of symbols in horas:: all have to be explicitly marked eg %horas::winner etc etc or
• all modules have to be supplied with Exporter specifications so that e.g. use horas::module imports horas:: symbols implicitly

I'm inclined to the first choice above.

I’d like to discuss it, though.

I don't think we should have so many packages: in fact it seems to me there should be one package and many modules.

[gregordick]

+1 in principle for merging horas:: and missa::. Is there a chance that we'll break third-party applications that rely on the existing URLs? We could always provide a compatibility shim if need be.

horas::Scripting is slightly special in that membership of that package indicates permission to be called using the & syntax in the datafiles. I have no objections to changing that mechanism if it would make the design cleaner, though.

[gregordick]

Correct. I was confusing horas::Scripting and the ScriptFunc annotation; it's the latter that marks a function as script-safe, not the former.

[fiapps]

+1 in principle for merging horas:: and missa::. Is there a chance that we'll break third-party applications that rely on the existing URLs? We could always provide a compatibility shim if need be.

Merging the packages won't break my code. The modernization will probably oblige me to make extensive changes. Changing a package name is the least of my concerns. My app uses code that is similar to Pofficium.pl, but produces HTML with no form elements, and with CSS classes instead of inline formatting. To make that work, I have variants of two other files besides Pofficium.pl. So, depending on how much restructuring happens in the codebase, I may wind up having to reapply my changes to the new codebase rather than simply integrating updates to those files as I've done so far. I would rather not have to do that, because I don't have a lot of time to work on this, but it may be the unavoidable price of modernization.

[ajmalton]

I'd very much like to avoid causing anyone trouble with this “modernization” plan, but only make the future easier.

It should be true that code which requires old style modules can require “modernized” modules with no consequences. It will just be necessary to change a few file names, I think. The new stricture and warnings are not applied to users’ code (yours) but only to the used modules (and the entry points) of master.

I am very willing to look at your code, if it’s open, and try to align my proposed changes with your assumptions to avoid impact to the extent possible.

Note that I am rebasing regularly, so any changes you push upstream are kept behind my ongoing work.

[fiapps]

My code isn't open. Perhaps I'm overestimating the impact of your changes, but part of the problem is that my user code doesn't integrate with the core code in a clean way. For example, I have a variant of horas.pl that replaces every call to setfont with a call to my function to set a CSS class. When changes are made to horas.pl, I use the diffs to patch my variant. But if you make changes so extensive that the diff begins to resemble the whole file, updating with git diff and patch is no longer going to work, and I would have to rebuild my variant by applying my changes to a fresh copy of horas.pl (or finding another way to integrate).

[ajmalton]

Well.

I think you'll be fine, as I look through the current diff with master. There is only one line that touches setfont and so the remaining 26 call sites should be good. My rebasing has been conflict free. (Granted, most changes touch the data not the code: but there have been code changes and they integrated fine.)

My work is open, so if you wish you can make a diff and patch and see what the prospects are currently.

All that said... I am currently using HTML as the "anchor" to ensure my changes are zero or low impact on the functionality. Because right now I'm correcting the code, not changing the design.

But in the future, we’ll want to do some things similar in spirit to what you've done: clean HTML with CSS, separation of concerns (options, choices, content, display), a proper HTTP API, and an actual web framework in place of the old homebrew. These will be more difficult to design without knowing more about your dependence on the current code base.

It might be valuable to see if your integration surface can be narrowed. There is no rush, though!

[mbab]

'missa' can/should be held just as another 'hora'.

[ajmalton]

What does hOneKalendar do exactly?

Is that so that kalendar and Ckalendar use exactly the same code whether from missa or horas?

I think it can be merged with modernization but only by hand.

[mbab]

What does hOneKalendar do exactly?

Is that so that kalendar and Ckalendar use exactly the same code whether from missa or horas?

There is one 'kalendar.pl' for all four current versions.

BTW. I moved the part of post to another thread.

[ajmalton]

Yes, I think this is the right thing to do: the missa logic is quite close enough to the officium logic. One problem might be that the versions for Mass are slightly different, reflecting the history. There is no OP or Monastic missa; and there is no 1965-1967 officium.  AJM