On the future Delphi type system

Recent post by Allen Bauer announced that some future Delphi release will introduce “rooted” type system so that every type will be derived from TObject. It does not mean that plain old types like Integer will actually be implemented as TObject descendants. As far as I could understand code like this

Var I: LongInt;
  ...
  I:= 2;
  I:= I * 4;
  ...

will treat the variable I as a plain 32-bit value as before, but code like this

Var I: LongInt;
    S: string;
  ...
  I:= 2;
  S:= I.ToString;
  ...

will probably create a “wrapper” object for integer type internally to implement ToString method.

I want to make two remarks to the above.

The first is about terminology. I never seen it explained in Delphi books or documentation but well, instance of every type is an object. Code

Var I: Integer;

declares object of integer type. There are two different kinds of type – value types and reference types. Byte, Word, Integer, record and many more Delphi types are value types. A variable of a value type is an object itself. Reference types in Delphi are string, dynamic array, class and interface. A variable of reference type is a pointer to object.

Second, rooted type system is not the only possible approach to bring order into the type system. The concept that makes you stunned at the first acquaintance with Haskell is “type classes”. In Haskell every type is an instance of a type class; and a type can be an instance of many type classes at once. For example Integer type in Haskell is an instance of “show” type class, so integers can be converted to strings; Integer type is also an instance of “read” type class so strings can be converted to integers.

Advertisements

6 thoughts on “On the future Delphi type system

  1. > Instance of every type is an object. A variable of a value type is an object itself. A variable of reference type is a pointer to object.

    That’s not how it always was. Objects are pointers to data + associated logic, value types were never objects.

    I do not know if it’s possible to do this right, but I personally would be not amused if everything descended from TObject. Delphi objects are *slow*. They are not like C++ “pay for what you need” objects, where you can make it as fast or as complex as you want. In Delphi, simply by using TObject you incur a speed and memory overhead sufficient enough to not use it for anything heavy (>300-400 items).

    • With introduction of advanced records and class helpers for non-class types (bad name BTW – class helper that have nothing to do with class) every type in Delphi now can have “associated logic”, so no need to reserve the term “object” to class instances only.

  2. Actually, the in-memory presentation of a record structure containing an integer is exactly the same as that of an integer by itself. This is why the “record helper” syntax makes sense (in at least one way) for value types. A class that contains an integer is a record structure containing both the integer and a pointer to the integer class’ VMT.

    I don’t believe Alan’s post insinuated that native types like integer would actually be inheritable types with overridable virtual methods, so there should actually not be all that much overhead in creating the rooted type system.

    In most code, your native type should stay exactly as it is, with the same performance characteristics. In other instances that VMT pointer may be implied, but not actually stored and no form of boxing will be needed (think of the existing record helpers – they are normal function calls with syntactic sugar). Only when the integer is explicitly stored in a TObject variable should boxing occur. Even then, it may not be much of a hit, as it should basically involve copying the integer value to a record structure containing the VMT pointer.

    Personally, I think generics has already lessened the need for the rooted type system. However, since generics are not exactly pervasive throughout the RTL, I can think of places where rooted types can still offer some benefit.

  3. Having methods for types (syntax sugar) has nothing to do with the type system imo. It is just an implementation detail. And actually it looks like the way they choose is not as simple and flexible as it could be. For example there are no helpers for generic types or interfaces which could be achieved easily if it were “just” syntax sugar (i.e. a routine with a matching first parameter maybe marked special can be called as if it were a method of the type)

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s