Initing the atFile read/write code is always going to be tricky, but perhaps not so tricky as it is at present.
A few days ago I rejoiced to eliminate the atAuto ivar, keyword args and related code.
A few minutes ago, I was tempted to add it back. This is clearly a bad idea, for two reasons:
1. Switches should be as specific as possible.
In this case, the switch will be called, allow_undefined_section_references.
General switches may also be reasonable. For example, a "toString" switch,
when passed to any AtFile write method, will never create a "huh?" when I read it. Ditto for the at.toString ivar.
2. When possible, switches should avoid polluting function signatures.
This can be done using the following pattern:
ivar= 'allow_undefined_section_references'
setattr(self, ivar, True)
try:
<< call the code that uses this ivar >>
finally:
delattr(self, ivar)
The following code will test this switch:
if getattr(self, 'allow_undefined_section_references'):
I have never seen this Python pattern before, but here it makes sense. It does complicate the calling and "using" code, but the complications are minor. Crucially, the complications are localized. The new pattern simplifies the rest of the AtFile class, which need not be aware of this switch at all! Furthermore, this switch can be tested anywhere in the AtFile class.
This is a big win. At present, various switches "infect" the signatures of too many methods. The infection spreads to the at.initCommonIvars, at.initReadIvars and at.initWriteIvars methods.
I suspect one or two other fairly mysterious switches pollute AtFile signatures. If so, I'll remove them and the corresponding 'huh?' they evoke in the reader.
Edward