On the dangers of giving a product feature the name “new”
Raymond Chen
A customer was having trouble adding a default parameter to their Windows Runtime method. When they used the [defaultvalue] attribute, they got the error
error MIDL2167: [msg]this attribute only allowed with new format type libraries [context]: [defaultvalue()]
“Why does the error tell me that it’s allowed only with the new thing, when I’m using the Windows Runtime, which is the latest thing?”
This is a case of an error message written to a point in time.
Windows 2000 introduced a new type library file format, and you could select whether you wanted the old format or new format by passing the /oldtlb or /newtlb command line switches. The error message is saying that the [defaultvalue] attribute is supported only with new-style TLBs.
Mind you, those “new” TLBs are now over 20 years old. They may have been new once, but they’re not new any more.
I’m not a fan of giving a product feature the name “new”. It may be new at the time you introduce it, but after a while, it won’t be new, and any messages that refer to it as “new” will only end up confusing.¹
For example, the New Executable format is now over 35 years old, originally designed for 16-bit Windows. Like anybody even remembers that. It’s so new that it isn’t supported any more.
Instead of calling your thing “new”, name it after the actual new thing. The “New Executable” could have been called a “Segmented Executable”, for example. If you can’t find a name for the new thing, you can chicken out and call it “v2”. In the above case, the error message would at least say “This attribute is allowed only with version 2 type libraries.”
In the case the customer was running into, they were compiling a Windows Runtime interface, and the [defaultvalue] attribute is simply not supported by the Windows Runtime at all. It’s not listed in the documentation for MIDL 3.0 as a supported keyword.
The Windows Runtime doesn’t support default parameters because not all languages supported by the Windows Runtime have the concept of default parameters. C++ and C# have them, but JavaScript for example does not, or at least it didn’t have them until ES2015. Fortunately, you don’t need default parameters. You can get the same effect with overloads.
runtimeclass Widget
{
// can't do this:
// void Sparkle(SparkleOptions options = SparkleOptions.None);
// Do this instead:
void Sparkle();
void Sparkle(SparkleOptions options);
}
The difference between default parameters and overloads is that default parameters are encoded at the call site and therefore are immutable. On the other hand, the 0-arity overloaded function is implemented by the Widget itself, and it can choose what the default options are, even changing the defaults from version to version.
¹ One of my colleagues told me that when a new shopping mall was built in his home town, the locals called the original one the “old mall” and the new one the “new mall”. These nicknames stuck even after the so-called “new mall” was no longer particularly new. What made things even more confusing is that the “old mall” was renovated, but the locals still call it the “old mall”, leading to the odd situation where the “old mall” is actually newer than the “new mall”.
Light
Dark
24 comments
The same is true when playing a game of Pool recreationally, and someone whips out their two-piece pool cue from a satin lined case. The first few lines of conversation with the new “Hot-Shot” challenger usually go around which rules the next game should be played by. Will they be the “New Rules” or the “Old Rules” or the “New-New-Old Rules”, or the “New-Old-New Rules”?
The hospital near where I live is called the “New St John’s Hospital” even though it was opened in 1898 and the old one was destroyed in the Second World War.
There are lots and lots of examples of this, for example our village church is called the new church because it was built in 1789, much more recently than the old church next to it. Another one that springs to mind is the Altneu Schul, the Old New Synagogue, from 1270. This may be the first case of new becoming old-new as others have commented on.
New College, Oxford is a particularly egregious example; it’s one of the 10 oldest colleges of the University of Oxford, which now has 39 colleges – for every college that’s older than New College, there are 3 that are newer.
Tell that to New Yorkers 🙂
It’s still newer than the city of York in the UK, and to my knowledge no other cites named “* York” sprang up after the founding of NYC, so I’d say that the “new” appellation still applies in this case 😉
Make that “York v2” and the name is future proof.
I always tell my coẅorkers that every time one writes “new” one should slap one’s hands and replace that with the current date. Then pause and think if a more descriptive name is possible.
At my old company we eventually instigated a rule that you weren’t allowed to name anything using the words: new, old, temp or legacy. Precisely because people had done so at times and none of those things now meant what they were originally supposed to.
I wasn’t aware that Javascript supported function overloading either. Must be a new feature.
Haha. Maybe done manually by inspecting `arguments` (https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Functions/arguments)?
This is a lesson that most software devs will learn after a year or two on the job. Naming anything “new” is a recipe for disaster.
Perhaps this blog should now be renamed “The Older Old Thing”.
So… does adding the word “old” negate the mistake of using the word “new”?
Like, I don’t know… “The Old New Thing” ?
Or, following the Win32 legacy old pattern, upgraded to The Old NewEx Thing. Or, I dunno, The Old New ThingEx. 🙂
We have that same problem where I work with the term “next-gen”. Like – what do you call the thing after the “next-gen widget”? The “Next-next-gen widget”?
I grew up in the UK not too far from the New Forest; it’s managed to retain that name for almost 950 years so far.
New New MyProductName v2 final FINAL – copy (2) – USE THIS ONE
New Technology File System
Because Windows NT…
We have a similar problem here in my town with the new housing development area (German: “Neubaugebiet”). There was the new housing development area, which was developed in the late 90s to early 2000s. The area was always referred to as the “Neubaugebiet”. But then a new large area was developed in the late 2010s. So now we have the old new housing development area (“alte Neubaugebiet”) and the new new housing development area (“neue Neubaugebiet”).
I wonder what will happen in 10-20 years if there is a third new housing development area. Maybe the totally new new housing development area (“ganz neue Neubaugebiet”)?
PerlRE:
(neue )*Neubaugebiet.Every time I see the word “new” in a code comment in code I’m reviewing I flag it for basically the reasons you describe. I also flag the word “now” because it usually requires understanding the way something used to work. (Exception: If the comment also explains the way something used to work and why that way was not good.) Semi-relatedly, I’m also a fan of comments for a line of code that’s not there and shouldn’t ever be there for some good reason.
BTW, don’t forget the University of Oxford’s New College. Founded 1379.
I’ve always appreciated how COM interface naming pattern avoided this trap from nearly the get-go:
ICommDlgBrowser,ICommDlgBrowser2,ICommDlgBrowser3… The Win32 API initially tucked onExat the end of the id of next extension of a function or struct, ending in such bogosities asWAVEFORMAT,WAVEFORMATEXandWAVEFORMATEXTENDED. The never APIs seem to have adopted the numeric suffix approach (at least, more often than not), incrementing the number as the object provides more flexibility or functionality, which is much more sensible and future-proof.