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.  

 

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?

 

 

 

 

Published 24 September 03 12:32 by BradA

Comments

# Len Weaver said on September 24, 2003 2:24 AM:
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.
# Dominic Hopton said on September 24, 2003 5:01 AM:
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?
# Paul said on September 24, 2003 6:18 AM:
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.
# Josh Christie said on September 24, 2003 9:15 AM:
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.
# chris said on September 24, 2003 10:32 AM:
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?
# Mark Levison said on September 24, 2003 12:50 PM:
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.
# Subramaniyan N said on September 24, 2003 3:04 PM:
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=1787 In 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
# Corrado Cavalli said on September 24, 2003 3:17 PM:
I'm with Chris idea.
# Matthew Reynolds said on September 24, 2003 5:57 PM:
I blogged my comments here: http://weblogs.asp.net/mreynolds/posts/29019.aspx
# Yves Reynhout said on September 25, 2003 10:22 AM:
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).
# Ian Ringrose said on September 28, 2003 12:59 PM:
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).
# Fabrice's weblog said on January 22, 2004 5:29 AM:
# Fabrice's weblog said on January 22, 2004 5:33 AM:
# Fabrice's weblog said on January 22, 2004 5:57 AM:
# Fabrice's weblog said on January 22, 2004 12:07 PM:
# Judah H. said on April 10, 2004 7:52 PM:
Ack! Brad please please please convince the team NOT to use Ex or numbering. That's one thing I hated about COM, one thing that would dirty the nice FCL. Don't do it!

I'd say just break it. Break the interface. Yes, it's a temporary pain to recompile my app -- but hey, we've got .NET versions running side-by-side, something not previously possible with COM, meaning that if my app uses IFoo in version 1.1, then .NET 2 makes breaking changes IFoo, big shit - my app won't break as long as .NET 1.1 is installed on the target machine. So if you guys break an interface, it's a minor itch to scratch for me. But if you instead make a new interface, you're dirtying the FCL forever. Don't do that.

So please no numbering systems or Ex postfixes! Let's not devolve back into the days of COM.
# Simon Mourier said on April 11, 2004 12:30 AM:
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.
# Fyodor Sheremetyev said on April 12, 2004 11:02 PM:
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?
# secretGeek said on April 14, 2004 9:26 PM:
Althought I don't like it when comments just say: Ditto, I agree...
well, ditto with Judah H and most other commentors, I do indeed agree.

Judah H in particular says:
"hey, we've got .NET versions running side-by-side, something not previously possible with COM, meaning that if my app uses IFoo in version 1.1, then .NET 2 makes breaking changes IFoo, big shit - my app won't break as long as .NET 1.1 is installed on the target machine. So if you guys break an interface, it's a minor itch to scratch for me. "

very true!

Simon says:
>We are humans after all.
Huh? Did I miss something?

nanoo! nanoo!

# Luke Stevens said on April 20, 2004 1:47 AM:
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.
# ASP.NET Team Blogs said on October 10, 2006 12:08 PM:

I noticed a good debate going on the BCL blog (and now Krzysztof Cwalina’s blog) about the naming of

New Comments to this post are disabled

Search

Go

This Blog

本博客中文版 (View in Chinese)

These postings are provided "AS IS" with no warranties, and confer no rights.

Syndication

Page view tracker