DateTime Compatibility Issue

re: DateTime Compatibility Issue

Chance Gillespie — Tue, 17 Feb 2004 18:50:00 GMT

I think if you break it down into a more fundamental meaning then the absolute wrong choice is completely obvious.

What you are essentially asking is “Do we put up a canopy to protect the small amount of ill written code that would be affected by this at the cost of fracturing the framework and causing future code to shift gears to compensate, or do we keep future code as a priority”.

To me at least, the answer is clear… Sacrifice the few for the benefit of the many. Making a change like freezing the enum and introducing a new one just to protect that small amount of code (which honestly should be dealing with the known enum values now and providing error handling for unknown values to future proof against breaking changes) would be far more harmful than beneficial. I don’t think many people would argue that option #1 is out of the question (please, PLEASE don’t let that happen, I beg you!!). If we get caught up in situations like this where we don’t take to heart the changes of the platform as a usable development tool we are going to end up right back where we were with Win32/COM: a big, disgusting, irritable, incomprehensible mess (I used to show pages of DirectX 3 code to kids on Halloween to send them screaming and crying in fear =) ).

The choice between #2 and #3 are not as clear cut, however. I, myself, am firmly on the side of #2. If you leave things open, and just not bother with doing the checks then you have succeeded in sheltering those few from the breaking changes but you have also denied future code of a protection that you would expect from .NET (and WinFX in the future.. decisions like this can have a far greater impact on future decisions than you might first imagine).

So it all boils down to a quantifiable choice. Protect the few at the cost of the many, or sacrifice the few for the benefit of the many. You mention that we (yeah, I feel a part of a community with .NET so I say we =) ) are already at the second revision of the platform with the 3rd on it’s way. Personally I think that v1.0 and v1.1 of the framework are so closely related that v.1.1 really should have been called v1.0.1. From what I have seen of v1.2 the changes are so massive that it is unquestionably deserving of the title v2.0. Generics alone give it that right (who knows, maybe Microsoft will give it that moniker in the end). Since I see the next release of the framework as the second real version, it pains me to think that we may end up setting a precedent by introducing these sorts of splintering changes into a young platform that has so much potential to learn from past mistakes and not take road into API decay.

Then again, maybe I just need to drink another beer and relax =)

Chance

re: DateTime Compatibility Issue

J. Daniel Smith — Tue, 17 Feb 2004 19:53:00 GMT

From reading the various MS blogs, there seems to be almost an undue emphasis on avoiding "breaking changes". I think that I pretty much agree is Chance Gillespie - do things the "right way", even if that means some pain for a handful of people.

And that "pain" is really only going to hurt in fairly isolated cases such as trying to run an old(er) version of an application on a new(er) version of the .NET framework. Otherwise, what's the big deal? We're doing a new release of our app, moving to a new release of Visual Studio, and we've got to change some code. While that sucks, and it would be nice if we didn't have to change anything; it's not the end of the world.

Dan

re: DateTime Compatibility Issue

Michael Teper — Tue, 17 Feb 2004 20:07:00 GMT

+1 on #2. Breaking change is OK when it breaks broken code.

re: DateTime Compatibility Issue

Tom McKearney — Tue, 17 Feb 2004 20:58:00 GMT

Absolutely #2. I can't stand it when people use casting to get around things that were specifically designed to prevent them from entering the wrong value.

re: DateTime Compatibility Issue

Ben Maurer — Tue, 17 Feb 2004 23:02:00 GMT

I see no real reason to test for the values. If someone wants to pass junk to a function, just let them do that (unless it is a security risk). I can't think of any case where someone would be doing this other than just to probe the code.

It would really sadden me to see enum checking become the de facto standard, which is basically what will happen if Microsoft goes this way. It is an issue that will never happen by mistake. You add no value to the API really by checking for the values.

WRT versioning, I think that you should only mark the assembly as compat with a specific version of the fx if you can compile and run against it. This solves any issue with a function acting weirdly on an old version of the fx.

re: DateTime Compatibility Issue

Ian Ringrose — Wed, 18 Feb 2004 10:28:00 GMT

Make the “breaking” change in 1.2, as is may find a bug in software that I am writing. At the same time, stop apps that are compiled against 1.1 from running with 1.2 ales the app.config file says they can. Ship version 1.1 (and 1.0) of the framework with all Microsoft products (including server packs that have version 1.2 of the framework. In other works make side by side running of the framework the normal case.

What happens with the new SQL server, if there are two database in the same instance, and one database want versions 1.2 of the framework and other database wants version 1.3 of the framework?

re: DateTime Compatibility Issue

Tom McKearney — Thu, 19 Feb 2004 14:24:00 GMT

It is an issue that will never happen by mistake

I don't agree. If someone persists a structure or class with an Enum value in it to disk as a text file or XML or a database record and someone else goes and modifies the record manually, the resulting object will have an invalid value for an enumerator. I want to know when that happens!

The whole point to an enumeration is to constrain data to a particular set of values. If the language allows you to get around that, then every piece of code that reads and writes enums or accepts them as parameters has to manually bounds check them! That's completely unacceptable.

When you define an enumerated type as a parameter, that is a contract with the caller. You shouldn't be able to pass anything you want. As far as I'm concerned, in the right circumstances, this COULD be a security issue.

Tom

Back in action

Mungo Knotwise of Michel Delving — Mon, 23 Feb 2004 03:29:00 GMT

re: DateTime Compatibility Issue

Gavin Gregson — Mon, 23 Feb 2004 05:19:00 GMT

One more for #2. Passing illegal values to a function is an error and should be treated as such. Definitely don't do #1, that's a nasty slipperly slope.

Back in action

The Diffracted Developer @ Home — Sat, 20 Mar 2004 20:23:00 GMT

.NET DateTime and Timezone: It Seems Simple, but It's Not

Mark Treadwell — Sat, 22 May 2004 02:37:00 GMT

DateTime and Timezone

Ohad's WebLog — Sat, 17 Jul 2004 17:00:00 GMT

C# Enum.Parse() Bug « The Pursuit of a Life

C# Enum.Parse() Bug « The Pursuit of a Life — Tue, 11 Dec 2007 10:39:16 GMT

PingBack from http://xidey.wordpress.com/2007/12/10/c-enumparse-bug/