[PATCH] Re: introducing xattrMaildir: a Maildir repository where message files have all IMAP flags in an extended attribute

Nicolas Sebrecht nicolas.s-dev at laposte.net
Tue Mar 12 18:32:36 GMT 2013


On Tue, Mar 12, 2013 at 10:54:01AM +0100, Erik Quaeghebeur wrote:
> Dear Nicolas,
> 
> First of all, I must stress that this patch cannot work without my 
> earlier one “Let OfflineIMAP sync all flags between IMAP servers, not 
> just Maildir-compatible flags”, which is far more invasive, but—I 
> think—also useful to a much wider audience; formulated differently: I 
> think it corrects a historically understandable but wrong design choice 
> and is the more important of the two, needing close scrutiny.

Could you elaborate about this "wrong design choice", please? I don't see what
you're talking about and how you enhance it.

> Ok, I'll try to do that when preparing a new patch that modifies Maildir 
> to take an xattr option instead of adding a separate repository type.

<...>

> Um, not knowingly, but xattrMaildir does essentially just derive from 
> Maildir and then applies some changes to a few functions. The class 
> __init__ functions are not modified but inherited.

<...>

> I avoided refactoring to not make the patch too big and the deviation 
> from the current code as small as possible.

Here is a detailed explanation as I was not clear enough. What I'm
suggesting is the exact oposite: refactoring in order to have as small
as possible duplicated code in the inherited object.

Here is a sample. Starting from

A():
  def original_method(arg1, arg2):
    statement1(arg1)
    statement2(arg2)
    statement3
    return result


I suggest something like this:

A():
  #
  # Refactored new "private/hidden" method (might have a better name!).
  #
  def _original_method(arg1, arg2, new_arg3=optionnal):
    # Don't focus of the following statements, it's out of concern.
    statement1(arg1)
    statement2(arg2)
    if new_arg3:
      statement4  # refactored piece has to honor the new_arg3 argument
    else:
      statement3  # does not differs from original behaviour
    return result

  #
  # Keep the object interface intact.
  #
  def original_method(arg1, arg2):
    return _original_method(arg1, arg2, False)


NewInheritedB(A):
  #
  # Keep the object interface intact.
  #
  def original_method(arg1, arg2)
    #
    # Last argument could also be a variable coming from a
    # original_method() optional argument.
    #
    return _original_method(arg1, arg2, whatever_third_arg)


> > I think the new repository type approach is good because of the library
> > dependency issue.
> 
> Would it be ok to add the functionality to Maildir if the extra 
> dependency is hidden behind an option-controlled dependency,

Not sure what you mean by "option-controlled dependency".  You already
have the option for that: the maildir type you just introduced.

If you mean to have the import statement womewhere inside the original
method itself: this is crappy.  And yes, I know we have such thing in
offlineimap/threadutil.py:161.

Back to my above sample, you could do something like this (with a
comment on top of the file where imports are expected):

NewInheritedB(A):
  #
  # Keep the object interface intact.
  #
  def original_method(arg1, arg2)
    try:
      import BLAH
      #
      # Last argument could also be a variable coming from a
      # original_method() optional argument.
      #
      return _original_method(arg1, arg2, whatever_third_arg)
    except ImportError:
      # Handle missing dependency


>                                                              as i had 
> the impression you suggested above> (I now think this is the cleanest 
> way to add the functionality, given that xattrMaildir differs so little 
> from Maildir.)

Not a problem to use polymorphism (aka a dedicated object) for that
purpose. The other good thing I see with this approach is to have a
dedicated-inherited object for a /not usual/ OfflineIMAP repository
type.

Now, I don't have strong opinion on this as long as the import thing
does not need to be in a random place somewhere in the code.

Thanks!

-- 
Nicolas Sebrecht




More information about the OfflineIMAP-project mailing list