Unseal Header and HeaderList about mimekit

[jstedfast]

What kind of things do you want to add? You can write extension methods for sealed classes.

Since there aren't any virtual methods (no real point), it doesn't make sense to make them subclassable.

I'd like to hear a valid reason for subclassing before I expend the work to make them subclassable.

[jstedfast]

FWIW, this is a good article on the topic of sealing classes: http://blogs.msdn.com/b/ericlippert/archive/2004/01/22/61803.aspx

[mwpowellhtx]

I'm bringing it to your attention in this forum out of respect for you. Usually I go by SOLID principles; in this instance, open for extension, closed for modification. In this case, by derived class; which I am not modifying behavior, or if I did it would need to be conscious with a new keyword, at my own peril. I'll be blunt: if you don't want to do it, allow me as contributor and I'll do it.

My reason is simple: because I want to expose (at least) a couple of HeaderList details as properties, not as methods, or even as extension method syntactic-sugar. Debugging, etc, flows better when I can see the results as properties. Per se, I don't think Header needs to be extended, since HeaderList appears to be sole the "MessageHeader" concept.

Anyway, I did scan through the HeaderList class, and I'm not buying your excuse the level of effort it would take. Just remove the keyword; that is all. I'm not asking you to touch any of the code that works on or around the HeaderList. Nothing needs to be virtualized that I can tell, but could be if there's any question. I'm not asking you to change the List-of-Header-ness about the class, after all. What purpose would that serve, after all?

Worst case, you may need to reconsider what you are doing for the internal Dictionary, which you've got a duplication of code anyhow. List for Header ordering, and dictionary for easy lookup.

I've cobbled together a near term solution with a HeaderListAdapter which accepts a HeaderList in its ctor and which implicitly converts to and from HeaderList. That will work for now but would flow more smoothly if I could just "see" the adapter as a HeaderList.

[mwpowellhtx]

Okay I take that back; re: scope of impact, possibly need to consider things such as OnChanged ramifications. Possibly. I'll grant you that.

[mwpowellhtx]

Ya know, just an observation with the Changed event, pardon the pun:

internal event EventHandler<HeaderListChangedEventArgs> Changed;

You know there is an ObservableCollection, right?

[jstedfast]

"Well, I might want to debug it and I like all my classes to be grab-bags of objects to make it easier for my style of debugging" isn't a really compelling argument for me.

If you want to write extension methods, just write extension methods. You don't need to subclass for that.

Anyway, thanks for the offer to write the patch but the amount of effort wasn't ever the problem. What I wanted was a good reason for needing to subclass those classes and you don't seem to have one.

If you find that you actually need to debug you HeaderList (I doubt you will), you can just modify your local copy of MimeKit (it's open source after all) and make whatever modifications you need to help you debug the problem.

Good API design principles suggest sealing classes that have no really good reason to be subclassable.

[mwpowellhtx]

Another reason is, there's no real good reason to hold common Header properties that close to the chest. But as you suggested, I can consider merging with a local code base.

[jstedfast]

FWIW, you can't set the HeaderList on a message anyway, so there's really no point in subclassing it.

[mwpowellhtx]

BUZZ! I don't care about setting them. I want to get them. As properties.

[jstedfast]

What good is subclassing a HeaderList if you can't actually set an instance on a message?

Give me an example.

[mwpowellhtx]

Like I said, I just want to get properties of a Header, as properties. Without necessarily loading the entire message. You'll just have to take my word for it, that's a requirement for this service.

[mwpowellhtx]

Professional critique: arguing this much with your customers, it's a wonder you keep business.

[jstedfast]

This isn't a business, this is a personal side-project.

[jstedfast]

I've unsealed a bunch of classes, including Header.

[jstedfast]

I am available for contracting, though. My going rate is $400/hr.

[princeoffoods]

Professional praise: arguing this much with a parody account, it's a wonder you keep your calm.

Jeff, thank you so much for sharing the outstanding work you did on MailKit and MimeKit.
The quality and efficiency of your work is truly an inspiration.

[Muraad]

I totally agree.
Thank you for your great librarys.

[jstedfast]

You're very welcome!

[mwpowellhtx]

It is indeed a fine library.