internal? shall we dance?

Sep 10, 2010 at 8:42 PM
-1
Sep 10, 2010 at 8:54 PM

This definitely goes along with how we view breaking changes.  When you care about not breaking users, making everything public is not viable.  But if we're going to go down the road where breaking changes are not a concern (as discussed in the interfaces/abstract base thread), then I can see how internal has less value.

Give us a chance to think about this some more.  We have brain implants that scream to us that doing this is bad, so we may need a bit of surgery to see that view point the way you do :)

Sep 10, 2010 at 8:57 PM
a lot of it just has to do with extensibility and testing.
there is nothing saying that we can't flag things as internal by putting them in an internal namespace

-d


On Fri, Sep 10, 2010 at 2:54 PM, davidebb <notifications@codeplex.com> wrote:

From: davidebb

This definitely goes along with how we view breaking changes.  When you care about not breaking users, making everything public is not viable.  But if we're going to go down the road where breaking changes are not a concern (as discussed in the interfaces/abstract base thread), then I can see how internal has less value.

Give us a chance to think about this some more.  We have brain implants that scream to us that doing this is bad, so we may need a bit of surgery to see that view point the way you do :)

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