Should Humans Be Called Ape2?

News

Omer has been professionally developing applications over the past 8 years, both at the IDF’s IT corps and later at the Sela Technology Center, but has had the programming bug ever since he can remember himself.
As a senior developer at NuConomy, a leading web analytics and advertising startup, he leads a wide range of technologies for its flagship products.

Navigation

.NET Resources

Lutz Roeder's Reflector

Articles :: CodeDom

Articles :: nGineer

Culture

Projects

Ever since Kathy Kam announced on her weblog that a new type named TimeZone2 will be introduced into the Orcas release of .NET, the community has been in an uproar, claiming the new name is horrible and that we're going back to the days of Win32 and COM with types like TimeZone3 and DateTimeEx not far down the line.

TimeZone2 comes to replace TimeZone in order to support Vista's Dynamic Time Zone APIs and offer some other new functionality.
According to Krzysztof, the team had several options:

Deprecate the current TimeZone using ObsoleteAttribute and use the same type for the new functionality, but this, according to Krzysztof, will simply not happen.
Use a new namespace, but this will cause confusion, since the type name would have to be fully qualified.
Find a better name, yet no one has been able to come up with one that would satisfy the team.
Call it TimeZone2.

Unfortunately, they decided on the last option, backed by an invocation of a Design Guideline (And none other than one of the very few guidelines I wholeheartedly disagree with).

I, personally, am with the Break Camp: Simply take the old functionality and deprecate it or just remove it altogether. The Orcas framework is to be released at version 3.* (a change of the major version since the last release), which means to users that breaking changes are acceptable and even expected. I have never heard known of a single serious software developer that has taken for granted that their applications will simply work when moving from .NET 1.0 to .NET 2.0 and I don't think I'll ever hear of one blindly moving to .NET 3.0.
Want to make it easier on your customers? Create an automatic tool (maybe as part of Visual Studio Orcas) that translates current behaviour to 3.0 behaviour.

Invoking the Red-Bits-In-Place-Service-Pack excuse is moot here, since it was the wrong call to make in the first place. Backwards compatability is not the Holy Grail.

This is the very first step on the road to making the .NET Framework an unusable patch-work. Just imagine a developer new to .NET which starts with version 3.0 and sees TimeZone and TimeZone2.

The CLR Team's posts about this in chronological order:

Orcas September CTP available... Hello "System.TimeZone2"!
System.TimeZone2 Starter Guide [Kathy Kam]
Designing System.TimeZone2 - Part 1 (API naming and new class or not)
Designing System.TimeZone2 - Part 2 (Dynamic Time Zone support)
System.TimeZone2 Naming ... and related design guidelines
Naming Guideline Discussion
When there is no good name...

[Update: The team went back to the whiteboard and renamed it TimeZoneInfo.]

Posted: Oct 10 2006, 11:17 PM by Omer van Kloeten | with 11 comment(s)

Filed under: Karma, 2 ⅛s, Community, Orcas

Comments

AndrewSeven said:

I would tend to lean towards the break camp, but I think the thing that really muddies the issue is the fact thet .Net Framwork 3.0 is not really a "Major Version", its 2.0 with version 1 of some Major extensions.

# October 10, 2006 4:39 PM

Omer van Kloeten said:

That's another decision I don't get, but since it's already been decided and doesn't bother me that much, I'll use it for the good of the discussion.

# October 10, 2006 4:53 PM

Gabriel Lozano-Morán - The .NET Aficionado said:

These last couple of days a discussion has been started on how to call the new TimeZone datatype in the

# October 10, 2006 5:23 PM

foobar said:

Just call it WorldTimeZone.

# October 10, 2006 5:30 PM

chronos said:

While I am not found of the name, it does not bother me that much. What do you do done the line when the next version comes out? TimeZoneExEx? How long does that continue? I am not happy with the current TimeZone or new TimeZone2 classes, and especially dislike the design of DateTime. I want to replace them, but Microsoft has sealed the classes and will not provide an interface. I am all for breaking changes when the original is poorly designed and / or to be replaced. A developer should not blindly assume that their application will run, untested, on a new version. I support a breaking change here; however, there are so many other more important types that need to be fixed as well. TimeZone is not very high on my priority list, but it would be a good start.

# October 10, 2006 8:23 PM

urig said:

I agree with you Omer. TimeZone2 is a mistake and opens the door to terrible Win32-like naming conventions just like you said. Is there any way to make a difference in this decision? Any blog where I can post a comment and hopefully be noted by the actual developers?

# October 11, 2006 5:07 AM

Omer van Kloeten said:

Uri -

You can use any of the links I have in the post to reach the blogs of members from the CLR/BCL team.

# October 11, 2006 12:45 PM

Arnon Rotem-Gal-Oz said:

I agree, TimeZone2 is horrible If it deals with Dynamic Time Zones - just call it DynamicTimeZone..?!? by the way regarding the post title - some people would probably only qualify as Ape 0.5 - but that's another story :) Arnon

# October 12, 2006 6:59 AM

TrackBack said:

# October 14, 2006 10:32 AM

None said:

I'm really impressed!

# January 5, 2007 4:15 PM

terraslate said:

yeah and how many of you complained about X509Certificate2?

there is nothing wrong with this as long as we can expect retirement on the third cycle. to that end i would like to see for instance the plans for .net 4 to reintroduce TimeZone as a derivative of TimeZone2 and then to deprecate Timezone2 with warnings.

by 5 TimeZone2 should be deprecated with errors and TimeZone codebase should become entirely that of TimeZone2.

it is well known that .net 2 is versioned at the assembly level. to have an improved version of a class named .net 2 doesn't look as nice but not every change shoudl require a new assembly! as for DynamicTimeZone that is useless - its the same as TimeZone2 but harder to find. Next we'll have BritishTimeZone and USTimeZone and CustomTimeZone and you'll think they are ok - just because they have a longer name.

The classNameN principle works extremely well to convey a step forward. dynamictimezone conveys no such hint.

# August 3, 2007 3:38 AM

Omer van Kloeten's .NET Zen

Recent Posts

Tags