Making $hl7Globals truly global

[skeemer]

The basic idea is to make HL7::$hl7Globals static, adding HL7::set*() (similar to the with* methods) and also using it in Message.

1. This would make it easier to set the global options once at application boot rather than having to specify it every time we use HL7 or Message.
2. I don't think this would be a breaking change except in cases where people are doing something non-standard.

I'm willing to do a PR if this is something that might be accepted.

[senaranya]

It's a good idea, but statics sometimes lead to some unwanted and hard-to-troubleshoot issues (like it did for the set* methods for which I had to add resetIndices()). For example, if we need to initialize HL7 with different globals at different points in the codebase, the state might be unpredictable based on which part of the code is setting those last.

Instead I'd consider singleton or some other creational design pattern, so it can be bootstrapped with a given set of globals, but can also be overridden as needed. This should eliminate the unpredictability

[skeemer]

The more I've thought about it and learned the codebase I'm of a similar mind.

There are really two sets of settings that exist as well, those defined in the MSH and those that are implementation based. Right now they are kind of mashed together. For example, when parsing a message, it rightfully uses and overwrites the separators from the MSH definition, but now those settings that we wanted for output are lost. Fortunately that's probably a rare edge case, but having explicitly set options just disappear isn't great. It looks like a good improvement to this part of the system would probably be a rewrite of the API for the package, however. That's a whole different discussion and pro/con list.