Blog

Code

Type-Inference in Generic Methods

Due to an interesting code example, behind which Kim Madsen first suspected a possible bug in the Delphi compiler, I took a closer look at the calling behavior of overloaded methods that also contain generic type parameters. I was surprised by the possible bug since I use overloads with combinations of generic and non-generic methods in current projects without any obvious errors.

Here is a simplified version of Kim’s code:

TFoo = class(TObject)
  public
    function DoSomething(SomeObject: TValue): string; overload;
    function DoSomething<T>(SomeObject: T): string; overload;
  end;

TBar = class(TObject)
end;

//...

var Foo := TFoo.Create;
var Bar := TBar.Create;

Foo.DoSomething(Bar);

Which of the two possible variants of DoSomething should be called by Foo.DoSomething(Bar)?

At a first glance, I was inclined to say that the non-generic variant, i.e. function DoSomething(SomeObject: TValue): string; should be called, since after all no type parameter is specified and therefore the first variant matches best.

But in fact, the generic, second variant is called. I initially suspected „TValue“ of „blocking“ the overload resolution here, since TValue is actually an „artificial“ RTTI.driven type.

Stefan Glienke came up with the correct hint:

Generic parameters are actually optional and the type is automatically inferred by the type of the variable that is passed. This „type inference“ takes precedence over overload resolution and thus produces a better match than the „TValue“ method.

Type-inference of generic methods is documented here btw.

So the following code actually calls a generic implementation, although no type parameter is specified in the call:

function DoSomething<T>(SomeObject: T): string;
//...
Foo.DoSomething(Bar); //<T> is inferred from "Bar"

Here is a Gist with full code to try:

https://gist.github.com/omonien/24b9b4ba64d46bdfa478615e8e9b0ae6

Code

Typableitung in generischen Methoden

Durch ein interessantes Code-Beispiel, hinter dem von Kim Madsen zunächst ein möglicher Bug im Delphi Compiler vermutet wurde, habe ich mir das Aufruf-Verhalten von überladenen Methoden, die auch generische Typ Parameter enthalten, genauer angesehen. Ich war von dem möglichen Fehler nämlich überrascht, da ich ziemlich sicher in aktuellen Projekten Overloads mit Kombinationen aus generischen und nicht-generischen Methoden verwende, ohne das offensichtliche Fehler auftreten.

Hier eine vereinfachte Darstellung von Kim’s Code:

TFoo = class(TObject)
  public
    function DoSomething(SomeObject: TValue): string; overload;
    function DoSomething<T>(SomeObject: T): string; overload;
  end;

TBar = class(TObject)
end;

//...

var Foo := TFoo.Create;
var Bar := TBar.Create;

Foo.DoSomething(Bar);

Welche der beiden möglichen Varianten von DoSomething sollte durch Foo.DoSomething(Bar) aufgerufen werden?

Im ersten Ansatz war ich geneigt zu sagen, dass die nicht-generische Variante, also function DoSomething(SomeObject: TValue): string; aufgrufen werden sollte, da ja schliesslich kein Typ-Parameter angegeben ist und daher die erste Variante die am ehesten passende ist.

Tatsächlich wird aber die generische, zweite Variante aufgerufen. Ich hatte zunächst „TValue“ im Verdacht, hier die Overload-Auflösung zu „blockieren“, da TValue ja quasi ein „künstlicher“ RTTI-.getriebener Typ ist.

Stefan Glienke hatte aber letztlich den passenden Hinweis:

Generische Parameter sind tatsächlich optional und der Typ wird durch den Typ der Variablen, die übergeben wird, automatisch abgeleitet. Diese „Type-Inferrence“ hat Vorrang vor dem Auflösen von Overloads und erzeugt damit einen besseren Match als die Methode mit „TValue“.

Die Typableitung bei generischen Methoden ist übrigens hier dokumentiert.

Der folgende Code ruft also tatsächlich eine generische Implementation auf, obwohl kein Typ-Parameter im Aufruf angegeben ist:

function DoSomething<T>(SomeObject: T): string;
//...
Foo.DoSomething(Bar); //<T> is inferred from "Bar"

Hier ein Gist mit komplettem Code zum Ausprobieren:

https://gist.github.com/omonien/24b9b4ba64d46bdfa478615e8e9b0ae6

Embarcadero sponsert Open Source Projekte

Mit dem in Kürze erscheinenden RAD Studio 10.4 Sydney, wird Embarcadero ein Sponosringprogramm für Open Source Bibliotheken auflegen.

Im wesentlichen gibt es zwei Grund-Voraussetzungen:

  • Das Projekt muss auf Github publiziert werden
  • Das Projekt muss in Delphi oder C++Builder Code vorliegen und mit 10.4 funktionieren

Das Sponsoring beschränkt sich ausdrücklich nicht nur auf „warme Worte“ sondern es wird auch eine finanzielle Förderung zugesagt. Ich gehe davon aus, dass man davon nicht reich werden wird, aber es wird ausdrücklich nach einem Entwicklungsplan und den damit verbundenen Kosten gefragt.

Im folgenden Google Dokuemtn finden sich alle Details:

https://docs.google.com/document/d/e/2PACX-1vRSZwkszUzgFeEFyZXS2Q6N88XDz6JpdiJxxLXktRGUTWzHcR6zyRRXprAH-dqSl91gW-HfeaxUWtGc/pub

Embarcadero to Sponsor Open Source Projects

With the upcoming RAD Studio 10.4 Sydney, Embarcadero will launch a sponoring program for open source libraries.

There are essentially two basic requirements:

  • The project must be published on Github
  • The project must be in Delphi or C++Builder code and work with 10.4

The sponsoring is explicitly not only limited to „warm words“ but financial support is also promised. I assume that you won’t get rich from it, but they explicitly ask for a development plan and the costs involved.

In the following Google Document you will find all details:

https://docs.google.com/document/d/e/2PACX-1vRSZwkszUzgFeEFyZXS2Q6N88XDz6JpdiJxxLXktRGUTWzHcR6zyRRXprAH-dqSl91gW-HfeaxUWtGc/pub

MVP des Jahres 2019 – DACH Region – Das Ergebnis

Wir haben alle Stimmen der, in der vergangenen Woche durchgeführten, Abstimmung zum MVP des Jahres 2019 für die deutschsprachige Region ausgezählt und der Gewinner steht nun fest:

MVP Emblem

Uwe Raabe

Nach dem klar war, dass Uwe die Abstimmung gewonnen hatte, ist er sozusagen vom Wahl-Komitee zurückgetreten, so dass mir nun die Aufgabe bleibt, Uwe zu würdigen.

Zunächst einmal möchte ich erwähnen, dass Uwe mit 32% der Stimmen deutlich vor dem Zweitplatzierten lag, der 21% der Stimmen erzielen konnte.

Uwes Wahl ist sicherlich ein Resultat seines unermüdlichen Einsatzes, um der Delphi-Community seine beiden wichtigsten Tools, MMX Code Explorer und Project Magician kostenlos zur Verfügung stellen zu können. Beide Tools gehören sozusagen zum Standard-Werkzeugkasten eines jeden Delphi Entwicklers.

Daneben ist Uwe auch regelmäßig in Webinaren, insbesondere bei der Coderage anzutreffen.

Ich habe Jim McKeeth nun Uwe als unseren Kandidaten für den weltweiten MVP des Jahres 2019 vorgeschlagen.

Also: Daumen drücken 🙂

Embarcadero MVP des Jahres 2019 – DACH Region

Uwe Raabe und ich sind die MVP Koordinatoren der DACH Region und haben u.a. die Aufgabe, einen MVP des Jahres auszuwählen.

Da wir dies nicht irgendwie ausklüngeln wollen, haben wir uns entschlossen, der Delphi Community die demokratische Möglichkeit zu geben, den MVP des Jahres zu wählen.

Auf dieser Seite könnt ihr ab sofort, bis zum kommenden Freitag, den 13. Dezember 2019, eure Stimme für den MVP abgeben, der euch im – schon fast vergangenen – Jahre 2019 am meisten beeindruckt hat, dessen Blogs ihr am informativsten fandet oder von dem ihr einfach denkt, er soll Titel für dieses Jahr erhalten.

Was gewinnt der MVP des Jahres? Ganz viel Ruhm – mit „h“ 🙂

Jim McKeeth, sozusagen der MVP Oberaufseher, wird entsprechende Posts verfassen und den Gewinner damit entsprechend würdigen. Flugreisen, Fernseher oder Millionen von Dollar zu spendieren, davon konnten wir Jim leider nicht überzeugen …

Die Abstimmung erfolgt anonym. Jeder, der sich der Embarcadero Community zugehörig fühlt, hat eine Stimme. MVPs können selbstverständlich mit abstimmen und dürfen sich natürlich auch selbst wählen.

Uwe und ich sind auch wählbar – auch wenn wir uns hier eher als Organisatoren sehen.

Das Ergebnis werden wir nach Ablauf der Abstimmung hier veröffentlichen. Wir werden nur den Sieger benennen, also kein Ranking erstellen.

Update: die Abstimmung ist inzwischen beendet. Das Ergebnis findet sich hier.

Handling JSON NULL values in Delphi

There is a quite frequent question about how to correctly handle NULL values in Delphi using System.Json.TJSONObject.

Handling existing values, in this example, the array of „customers“ is fairly easy:

{"customers":[{"name":"Olaf"},{"name":"Big Bird"}]}

But what, if the array is „null“?

{"customers":null}

Workaround: TActionManager broken in Delphi 10.3.3

UPDATE 2019-12-16: Official patch available.

Unfortunately, the long-awaited Delphi 10.3.3 release also brought a few new issues. One of them is that TActionManager is broken in a way, that prevents projects, using it, from compiling.

Because of some scope issue, the IDE keeps adding a unit named „IDETheme.ActnCtrls.pas“ to any form unit, that contains a TActionManager, once you save that form unit. „IDETheme.ActnCtrls“ is invalid, does not exist, thus the whole project will not compile anymore.

Fortunately, until EMBT releases a hotfix, there is a relatively easy workaround:

  • Add „VCL.ActnCtrls“ to any affected form unit
  • Create and add a completely empty unit to your project and name that unit „IDETheme.ActnCtrls.pas“
  • Compile

Publishing Delphi Apps to the Microsoft Store Episode 2

As promised my first video tutorial about the Microsoft Store, here are some additional steps I would like to share with you:

  • Publishing 32 & 64-bit packages
  • Version numbers
  • MS really reads Privacy URLs 🙂

This is the link to version 1.0.1 of HashExpert.

Publishing Delphi Apps to the Microsoft Store Episode 2

As promised my first video tutorial about the Microsoft Store, here are some additional steps I would like to share with you:

  • Publishing 32 & 64-bit packages
  • Version numbers
  • MS really reads Privacy URLs 🙂

This is the link to version 1.0.1 of HashExpert.

Wir benutzen Cookies um die Nutzerfreundlichkeit der Webseite zu verbessen. Durch Deinen Besuch stimmst Du dem zu.