Software “Assurance”?

Our department has Software Assurance for all of our Delphi licenses. So we’re supposed to get all the new releases. Right?

Well, not so much.

We’ve been paying for Software Assurance since we bought Delphi 2005. And it still took us six weeks to get our copies of Delphi 2006. Sure, they were shipping physical product, so fulfillment is going to take a little while, but good grief, six weeks?

It should have been better for Delphi 2007, since they had Electronic Software Delivery by then. You’d think that you’d get the product faster if you don’t have to wait for them to package and ship it. But no. Once again, it took us six weeks to get Delphi 2007. And even after those six weeks, we only got our copies after I e-mailed the CodeGear CEO to complain. (Things happened quickly after that.)

Studio 2007 was released on Monday. If we didn’t have Software Assurance, we could have bought it online on Monday afternoon. But because we do have Software Assurance — you know, the thing that’s supposed to assure that we get new releases — we have to wait.

How long? Well, we called CodeGear to find out. And we were told we’d have to wait a month.

(At least they’re improving.)

Later in the call, it came up that the month would be to get the physical media. Once the guy — apparently a trainee — figured out that we could actually download the software, the estimate was revised to a week.

We’ll see if that actually pans out this time.

When people pay in advance for upgrades — providing your company with a reliable revenue stream, mind you — wouldn’t you think they should get those upgrades when they’re released, or perhaps even slightly before? So they’ll, you know, keep providing your company with a reliable revenue stream? Software Assurance may be a bit less expensive than buying every version when it comes out, but it still isn’t exactly cheap.

As Brian remarked to me this morning, “I don’t feel assured.”

Little-known Delphi grammar feature of the day: control-character syntax

Did you know that you can use caret-letter syntax to define a string literal?

const
CR = ^M;
LF = ^J;
TabDelimited = 'Name'^I'Address'^I'City'^I'State'^I'ZIP';
TwoLines = 'First line'^M^J'Second line';

It reads like the classic syntax for “control-M”. It’s valid Delphi grammar, it compiles, and it works.

That said, I have no plans to support it in my parser. I find the string literals during the tokenizing pass, and at that stage, I can’t tell the difference between the control character (^M) and the pointer type (^J) in this snippet:

const
CR = ^M;

type
J = ...;
PJ = ^J;

Pointer syntax is used a lot more often (translate: I’ve only ever seen one source file with ^M string-literal syntax, and that was in-house), so I’ll give preference to being able to handle pointers correctly.

I have thought about doing some string-literal folding at parse time… for example, to join

'Lorem ipsum dolor sit amet, consectetuer adipiscing elit. Curabitur ' +
'euismod. Cum sociis natoque penatibus et magnis dis parturient monte' +
's, nascetur ridiculus mus. Sed porta, felis at fermentum pretium, pe' +
'de leo ornare eros, ut ullamcorper turpis arcu id metus.'

into a single StringLiteral token in my parse tree. (This would make it possible to write a frontend that provides a “find in string literals” feature, and make it able to find “pede leo” in the above snippet.)

But don’t expect ^M to work anytime soon.

Grammar details of Delphi’s “type type” feature

If you’re a hardcore VCL geek like me, you probably already know about Delphi’s “type type” feature. But I learned some interesting details about it last night while discovering the Delphi grammar.

The documentation doesn’t give a name to this language construct, so “type type” is a name I made up. It’s when you prepend “type” to a type declaration to give it its own type identity:

type
TColor = type Integer;

I won’t go into any details on what you would use this for, because it’s not that useful for anything outside the Object Inspector. You probably wouldn’t even notice it was a different type if you never used it as a var parameter. But it’s more useful than goto, and I’ve got that in my parser…

Anyway, I found some interesting details about “type type” in my research. Specifically, there are only three type constructs that allow you to prepend “type” to them: identifiers, string, and file.

type
TTypeQualId = type System.Integer; // or any (qualified) identifier
TTypeString = type string;
TTypeFile = type file;

No variations on these are allowed, and no other types are allowed (I tried every type in the Delphi grammar):

type
TTypeStringOfLength = type string[42]; // compiler error
TTypeFileOfType = type file of Integer; // compiler error

I suspect the reason for this is that (according to the documentation) every time you declare something like string[42], it’s automatically considered a distinct type from every other string[42] you’ve ever defined — and therefore has its own RTTI identity, and isn’t var-parameter compatible with the others. You don’t need to declare type string[42] because it’s already distinct.

I found type file to be particularly interesting. Even if you’re dealing with an untyped file — the ones where you have to pass that second parameter to Reset and Rewrite to make them even remotely useful, the ones that have been utterly replaced by TStream — you can still make distinct types, and let the compiler make sure you pass the right ones to your var parameters. That’s actually an interesting feature, since file parameters always have to be var. I wonder if anybody has ever used this.

Update: Sébastien Doeraene, alias sjrd, posted some good details about “type type” in the comments, including how this construct affects the IDE’s autocompletion features and the distinction with type aliases.