Delphi grammar quirk of the day: sealed and abstract classes
Delphi’s syntax for sealed and abstract classes is a bit bizarre. The following all compile:
type TFoo = class sealed sealed sealed sealed end; TBar = class abstract abstract abstract abstract end;
If you put the sealed keyword more than once, does that make the class somehow extra-sealed?
Interestingly, sealed and abstract are both what I’m calling “semikeywords” — they only have a special meaning in a particular context. Outside that particular context, they can be used as plain old identifiers. So you could actually have a field in the class called sealed or abstract… as long as it’s not the first thing after the class keyword. Add another field first, or a visibility specifier, and you’re fine:
type TFoo = class sealed Index: Integer; Abstract: Boolean; end; TBar = class abstract strict private Sealed: string; end;
But there is a bit of sense amidst all this oddity. They at least don’t let you mix and match sealed (cannot descend from this class) with abstract (must descend from this class):
type TBaz = class abstract sealed end;[Pascal Error] Project3.dpr(17): E2383 ABSTRACT and SEALED cannot be used together
Now, if they would just make it so that class abstract actually did something… (see QC#24662)
August 30th, 2007 at 1:51 am
I’ve compiled in Turbo Delphi something like this
(sorry, can’t check it now – no delphi nearby):
type
TFoo = class
const Name: string = ‘Foo’ virtual = ‘FooFoo’;
end;
compiler skips this virtual specifier.
August 30th, 2007 at 11:19 am
That code doesn’t compile as-is. Are you missing a semicolon?
type
TFoo = class
const Name: string = ‘Foo’; virtual = ‘FooFoo’;
end;
compiles just fine. (Yes, you can have a field — or scoped constant, in this case — called "virtual", although other coders would be well within their rights to smack you for doing so. Virtual is a semikeyword; it only means something special when it comes after a method declaration.)
August 30th, 2007 at 6:31 pm
The "official" name for a "semikeyword" (according to help, anyway) is a "directive."
August 30th, 2007 at 8:35 pm
Yeah, I know, and for quite a while I was calling them directives for that reason. But there are too many other things that are also called "directives":
1. Compiler directives like $IFDEF
2. The "directive" parser rule that means "things like ‘virtual’ that come after a method declaration"
3. Portability directives (which can be attached to methods, variables, units, etc.)
4. Things that are sometimes keywords and sometimes not
I just chose to come up with a different name for #4 in an attempt to make life a little less bewildering.