I can respect a good riposte

Posted by Jeremy Miller on December 9, 2008

http://davesbox.com/archive/2008/12/09/quot-i-can-t-believe-microsoft-didn-t-make-enter-api-name-here-public-quot.aspx

A.)  I’m a bit embarrassed by the backwards compatibility issue in StructureMap 2.5, but then again, breaking backwards compatibility cleaned a lot of crap up and made for a better user experience.  Most of the things I eliminated were features that probably did more harm than good.

B.)  The ExpressionVisitor thing would be a very handy thing to have in the public with solid documentation.  How ’bout we just make that a feature request for the BCL team?

 

About Jeremy Miller

Jeremy is the Chief Software Architect at Dovetail Software, the coolest ISV in Austin. Jeremy began his IT career writing "Shadow IT" applications to automate his engineering documentation, then wandered into software development because it looked like more fun. Jeremy is the author of the open source StructureMap tool for Dependency Injection with .Net, StoryTeller for supercharged acceptance testing in .Net, and one of the principal developers behind FubuMVC. Jeremy's thoughts on all things software can be found at The Shade Tree Developer at http://codebetter.com/jeremymiller.
This entry was posted in Uncategorized. Bookmark the permalink. Follow any comments here with the RSS feed for this post.
  • http://www.backlinkschecker.ws/backlinks/buylinks.html Purchase High PR Backlink

    Please keep up the great work

  • http://kentb.blogspot.com Kent Boogaart

    Brian,

    I wasn’t suggesting the business should sponsor an upgrade ‘just because’. If there is no compelling reason to upgrade, then don’t. Your application will continue to run on its target platform just fine, and that’s my point. Just because there’s a new, shiny version of the platform available doesn’t mean you should be building against it.

  • Brian Johnston

    Backwards compatibility is important because in my organization I have to work in 3.5, 3.0, 2.0, and 1.1 because the business isn’t going to sponsor the cost of upgrading a 1.1 application to 3.5 ‘just because’, yet when there is a bug we need to fix it, using 1.1 and VS2003.

    In fact every organization I have worked in has been this way. I have a colleague who writes a COTS product that they still have to support VB6 clients – why because if they say ‘you must upgrade to our most recent version’ those customers are going to say ‘no I don’t’ and go somewhere else because they rather stick with their pricing plan and support plan and internal employees who write modules for the VB6 version than have to deal with make all those changes.

    There is a domino effect to all of this, and to say it’s ‘not a big deal’ is extremely myopic.

  • http://kentb.blogspot.com Kent Boogaart

    I’ve never really understood the obsession with backwards compatibility. As a developer consuming version 1 of library X, I would prefer version 2 to clean up any crappy APIs even if it forces me to change my code. I see this as a good thing, as long as every breaking change is documented and justified.

    Yes, this means that if I write an application against .NET version 2.0, I’d be happy for it not to work against .NET 3.0 until I had migrated it. Happy.

    And in those situations where some level of backwards compatibility must be maintained (eg. between a host app and its add-ins) then frameworks such as MAF can provide adapter infrastructure to achieve this compatibility.

  • http://weblogs.asp.net/fbouma Frans Bouma

    I fail to see why the default expression visitor is such a big deal. First of all, the public code isn’t that great: the routines which visit lists of expressions are inefficient and overly complex, the other thing is that it lacks code for several expressions to begin with and it’s not focused on extensibility with custom expressions. (e.g. it doesn’t really implement the visitor pattern)

    I.o.w.: you’ve to spend time on it anyway, and more than you might think with a public visitor. Furthermore, writing a linq provider takes such a long time that writing the visitor is pretty minor.

    Though, if the visitor is seen as an example of a generic point that MS should open up more things to the public as they’re writing a framework, not a product… agreed. The only drawback is… is what MS puts in the framework always good? Take the linked list class. It’s so horrible, you’ve to write your own anyway.

    In the case of Linq: what would have been much better is a generic linq expression interpreter which provided hooks when things were reduced, as most code of a linq provider is simply generic code unrelated to the o/r mapper used.

  • http://codebetter.com/blogs/jeremy.miller Jeremy D. Miller

    @Arnon,

    I even considered it, and described this release, as the “Python 3000″ release

  • http://www.rgoarchitects.com/nblog Arnon Rotem-Gal-Oz

    Maybe breaking compatibility every once in a while is not that bad see http://cafe.elharo.com/programming/java-is-dead-long-live-python/