classes privateness

  • John van der Kamp


    I'd like to argue for a change in the end classes being private. The intermediate classes vmime internally uses are all ready to be derived from, but the end classes presented to programs are all private. This makes vmime less flexible than it needs to be.

    I'll try to clarify with an example. I wanted to be able to know which recipient failed, and which succeeded in the SMTPTransport class.
    This information isn't available in the mailboxList parameter after sending, to I needed to add something to the SMTPTransport class. But since there is private data, I can't derive from the class and fix the send() function the way I wanted.
    I ended up copying and renaming the complete class, and fixing the code there, but this introduced alot of duplicate code.

    Another example is with the htmlTextPart class, where I wanted to be able to optionally add a third body with custom a content type. Same problem there, so I needed to copy/rename the class again.

    If all the private stuff would be protected, I wouldn't have this problem. The change will probably be API incompatible, but it would be totally worth it to make vmime more flexible.



  • Vincent Richard

    Vincent Richard - 2010-03-16

    Hello John!

    Nice idea, we should work on identifying which classes should be affected.
    Changing API is not a big deal for now, as no stable (ie. "1.0") version has been released yet.



Log in to post a comment.