IDispatchEx2 here we come...

I have spent the last few years
making fun of the ugly, indecipherable names COM used as it aged and now I am
starting to see it in our own platform. I am doing some API reviews for Whidbey
and I ran across IDataReader2…. Not to far from IDataReaderEx3 in a couple of
years. Fear of this situation is
one of the things that lead me to recommend using base classes over interfaces.
"urn:schemas-microsoft-com:office:office" />

But, this is where we are, so
suggestions on naming? Should I
gave in and adopt the Ex or [2, 3, 4] suffix pattern or force only slightly more
meaningful name? such as IDataReaderFoo for a IDataReader that also supports
Fooness?

Comments

• Anonymous
  September 23, 2003
  Have you considered leaving IDataReader the way it is and adding a second interface that just contains the new stuff? Yeah, I know that in a few years that would mean inheriting from half a dozen interfaces instead of one IDateReaderEx6, but I could live with half a dozen well named interfaces. IDataReaderObjectSpaces for example.

• Anonymous
  September 23, 2003
  Why even worry about it? Your moveing to a new version of the run time which facilitates Side by Side in the same way previous versions do. Just mutate the Interface and keep the name. This is what other API's have done (System.Net springs to mind), why can't you? It's running on the new runtime, you get IDataReaderMagicCookie version. If it's only the old, you get current ones. Simple.... Or is this a case of spouting rubbish when they shipped .net? They said this wouldnt happen because you could change the API and run Side By SIde, without having all this horrible naming stuff. The problems of supporting "legacy" code were gone because they could continue to run the old code using the old runtime. Or am I missing something?

• Anonymous
  September 23, 2003
  Please keep using meaningfull names, indicating the differences between API's. Being able to guess what a api does based on it's (consistent) naming has been the best thing i've seen in .Net. Adding Ex or 2,3,4 is not going to make my development experience any better.

• Anonymous
  September 24, 2003
  I'm with Dominic.... If I want to compile my 1.1 apps on Whidbey I think it's fair to expect some changes to some interfaces and method signatures. I would much rather fix my app to work with Whidbey's changes than end up with a convoluted base class library.

• Anonymous
  September 24, 2003
  why not have the new interface extend the existing one? as in,interface IPoint3D:IPoint { int z { get; set; }}?then, existing code that expects an IPoint will still work... if there are changes to existing method signatures, then add them as overloads... can't that work?

• Anonymous
  September 24, 2003
  I would be perfectly comfortable with breaking changes, from one version to the next. I would prefer to keep interfaces neat and well named, even if that costs us a little short term pain. In addition why not get the dev team to implement an abstract base class that provides the preffered way for developers to implement this interface, then you won't be faced with IDataRead3 in a couple of years.Finally, if you must add new interfaces make the names clear.

• Anonymous
  September 24, 2003
  It is better to follow the Chris idea than going for base classes.Going with base class route is even more evil and dangerous route than interface route. One, alreadly lots of .Net BCL library requires base class inheritance. For example, MarshalByref and System.IO.Stream. More the requirement of base class inheritance instances; more the problem.The problem with going by base class implementaion is that at one point you would be end up with no way to move forward. That is, in during future feature enhancement; requirement of merging the functionalities would create a scenario where in you would be forced inherit from two base classes which is not possible.This future is not far away. Just year or two you will end up with facing the dead-end.The following two issues would highlight the merits and demerits of both ways.http://discuss.microsoft.com/SCRIPTS/WA-MSD.EXE?A2=ind0309&L=dotnet-language-devs&T=0&F=&S=&X=3807A36C52FC626373&Y=subramaniyann%40hotmail%2Ecom&P=1787In the below link go to the bottom where I talk about IDataValue & IDataRecordEx interface. Note: Maybe, this is what the IDataReader2 is about ;-).http://discuss.microsoft.com/SCRIPTS/WA-MSD.EXE?A2=ind0308&L=dotnet-language-devs&T=0&F=&S=&X=60C28F7B462F63C361&Y=subramaniyann%40hotmail%2Ecom&P=1975

• Anonymous
  September 24, 2003
  I'm with Chris idea.

• Anonymous
  September 24, 2003
  I blogged my comments here: http://weblogs.asp.net/mreynolds/posts/29019.aspx

• Anonymous
  September 25, 2003
  Go for the breaking changes from v.X to v.Y. Maybe provide a tool (in the nearby future) that analyzes an assembly against a specific runtime version and tells us developers why it won't run on that version. As long as the OS keeps supporting the runtime versions, I don't forsee too much trouble. I think it should have never been allowed to run "build against v1" on v1.1 (which got us into this trouble in the first place - but hey, that's just my opnion).

• Anonymous
  September 28, 2003
  I would much rather just have you make a breaking change. E.g. add the new methods to IDataReader, very few people implement the interfaces, so make it easy for people that USE the interface (most of us).

• Anonymous
  April 10, 2004
  The comment has been removed

• Anonymous
  April 10, 2004
  I have been using COM for 10 years, and I really don't care how the interfaces are named, provided they are well documented. (oh, yes, just avoid the stupid Ex + number scheme :-)
  
  The first example that comes to my mind is IHtmlDocument in MSHTML. I have used the 6 versions of it (IHtmlDocument1, 2, 3, 4, 5, 6...) and I don't have any problem with it. I'm probably a pragmatic guy. It just works.
  
  We are humans after all.
  Simon.
  

• Anonymous
  April 12, 2004
  Why not to leave the old name and just mark changed interface with some attribute to get compile-time warning while moving codebase to the next framework version?

• Anonymous
  April 14, 2004
  The comment has been removed

• Anonymous
  April 19, 2004
  Breaking changes?! That's fine for the authors of SqlDataReader or whatever who ship their new versions within the Framework itself, but what about all us poor souls who have written classes implementing the old IDataReader? Everything that used to take the old IDataReader should still accept these classes. You can't just change it. Extending an interface is no sweat for callers, but it breaks implementers!
  
  I for one would rather not see interfaces continue to grow more and more bloated. Interfaces should be designed thinking primarily of future implementers, not the convenience of callers. Small, cohesive groups of methods serve that purpose, not behemoths. If whatever new method is being added to the new DataReader classes absolutely does not make sense without all the old methods also being defined, then fine, create a new interface inheriting from the old. Otherwise, please do everyone a favor and split it off into an independent interface.
  
  I suspect that a big part of what drives these enormous conglomerate interfaces is just an aversion to casting. If a caller wants to call two methods on the same object from different interfaces, without tightly coupling to its particular class and abandoning the benefits of interfaces, the caller would prefer some single thing to hold on to that guarantees the presence of both methods, rather than using one interface and then having to cast to the other and worry about whether the cast might fail. .NET does have the nice feature of interfaces inheriting from multiple other interfaces, which can address this problem neatly, but where this naturally leads is forming every reasonable combination of existing interfaces into a new interface and struggling to give each of these a meaningful name. I say if you can't think of a meaningful name you probably don't have a meaningful interface.

• Anonymous
  October 10, 2006
  I noticed a good debate going on the BCL blog (and now Krzysztof Cwalina’s blog) about the naming of

• Anonymous
  June 12, 2009
  PingBack from http://cellulitecreamsite.info/story.php?id=1675