Interfaces, Abstract base classes, and breaking changes

Sep 10, 2010 at 1:44 AM

Goal here is not to start a big debate on Interfaces vs Abstract base classes :)

Generally, interfaces tend to be cleaner, but they don't rev well.  So we often use abstract base classes (e.g. Package instead of IPackage).  This is important when the breaking change bar is very high, which it generally is for Microsoft products.

However, it may very well be that NuPack doesn't need to play by those rules of super high breaking change bar.  If we make the statement that there will be breaking changes from v1 to v2, then we have a lot more flexibility.  One argument in favor of this is that NuPack is primarily a tool rather than an API.  Of course, it is an API too, but few will write directly to it (hence be exposed to breaks).

Bottom line: we're discussing the possibility of switching to using interfaces and accepting that we will likely have breaking changes.

Thoughts?

Sep 10, 2010 at 1:46 AM

+1 - interfaces ftw!

____
Rob
"Be passionate in all you do"

http://devlicio.us/blogs/rob_reynolds
http://ferventcoder.com
http://twitter.com/ferventcoder

Sep 10, 2010 at 5:38 AM
I am a big fan of interfaces.. I agree that the internals of the tool do not need to conform to some of the same constraints your team normally must deal with. It could be a good time to try out the interfaces.
 
This may be a different thread, It would probably would be good to define the areas where we want to avoid breaking changes... ie.  nuspec schema, powershell commandlets.  anything else????
Coordinator
Sep 10, 2010 at 5:38 AM
+1 for interfaces. If this were a .Net framework product, I might say otherwise, but considering our audience, interfaces FTW!
>
Developer
Sep 10, 2010 at 5:43 AM

Do we want to make a decision and use more interfaces then. If we decide we're ok with these breaking changes then I'd like to make some changes :).

Editor
Sep 10, 2010 at 5:44 AM

And OData FTW! Wait, what are we saying? ;)

From: Haacked [mailto:notifications@codeplex.com]
Sent: Thursday, September 09, 2010 9:39 PM
To: Scott Hanselman
Subject: Re: Interfaces, Abstract base classes, and breaking changes [nupack:226682]

From: Haacked

+1 for interfaces. If this were a .Net framework product, I might say otherwise, but considering our audience, interfaces FTW!
>

Read the full discussion online.

To add a post to this discussion, reply to this email (nupack@discussions.codeplex.com)

To start a new discussion for this project, email nupack@discussions.codeplex.com

You are receiving this email because you subscribed to this discussion on CodePlex. You can unsubscribe or change your settings on codePlex.com.

Please note: Images and attachments will be removed from emails. Any posts to this discussion will also be available online at codeplex.com

Sep 10, 2010 at 7:24 AM

Ok, let's move forward with this change.  It is unusual for us to go with an approach that will likely lead to breaking changes, but I think it's the right call here.

And as an aside, it should make oData either given the crazy things Fowler had to do when he experimented.

Sep 10, 2010 at 1:51 PM

+1 on interfaces. I can't mock out abstract classes (very well)

Sep 10, 2010 at 8:03 PM
+1 for interfaces
+1 for breaking changes between major revisions (again looking at the SemVer policies here)

Next question:
Are we going to mark anything internal? (i hope not) that is another MSFT'ism

-d

On Fri, Sep 10, 2010 at 7:51 AM, bsimser <notifications@codeplex.com> wrote:

From: bsimser

+1 on interfaces. I can't mock out abstract classes (very well)

Read the full discussion online.

To add a post to this discussion, reply to this email (nupack@discussions.codeplex.com)

To start a new discussion for this project, email nupack@discussions.codeplex.com

You are receiving this email because you subscribed to this discussion on CodePlex. You can unsubscribe or change your settings on codePlex.com.

Please note: Images and attachments will be removed from emails. Any posts to this discussion will also be available online at codeplex.com


Sep 10, 2010 at 8:40 PM

'internal' is another interesting topic.  I say we start a new thread for it :)