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

-- 
You received this message because you are subscribed to the Google Groups 
"leo-editor" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to [email protected].
To post to this group, send email to [email protected].
Visit this group at https://groups.google.com/group/leo-editor.
For more options, visit https://groups.google.com/d/optout.

Reply via email to