Ist es eigentlich irgendwie möglich, dem Compiler irgendwelche selbst definierten Abkürzungen (Alias) für lange Funktionsnamen beizubringen?

Mich ärgern so Sachen wie

IncludeTrailingPathDelimiter

oder auch nur ExtractFileName.

Es macht die Zeilen lang und versperrt die Sicht auf eigentliche Funktionalität.

So könnte man Abkürzungen definieren etwa wie EFN (für ExtractFilename ) oder (ITPD)

Bin mir selber nicht ganz sicher, ob das sinnvoll wäre, aber mich würde vor allem interessieren, ob das technisch möglich wäre.

Klingt irgendwie nach einem XY-Problem.

Zitat:

Es macht die Zeilen lang und versperrt die Sicht auf eigentliche Funktionalität.

Deutet für mich auf sowieso unübersichtlichen Code hin, in dem nicht nur bisschen Dateipfade oder so zusammengetüftelt werden sondern noch anderes Zeugs.
Ansonsten könnt man die eigentliche Funktionalität nämlich am Methodennamen ablesen.

Stichwort: Single Level of Abstraction

Für Typen kann man Aliase erstellen,
bei Variablen kann man sie überdecken (absolute),
aber für Funktionen kann man nur pointern oder inlinen.

Nur für Interfaces kann man bei der Implementation eine "Umleitung" auf andere Methodennamen definieren.

Für verschobene/zentralisierte Funktionen hatte ich mir aber auch schon ein/zwei Mal eine Alias-Behandlung oder Umleitung gewünscht.
z.B. in der alten Unit weiterhin den Aufruf im Interface, aber die Implementierung in der neuen Unit. (ohne das durch eine neue Inline-Methode schieben zu müssen, was z.B. bei Array-Property oftmals sich nicht inlinen lässt)

markieren

Delphi-Quellcode:

var kurz: procedure(....);

kurz := @gaaaaaaaaaaanzlang;

Die Variablen kann man auch hinter einem readonly Property oder eventuell auch hinter einer writeable Konstante verstecken.

markieren

Delphi-Quellcode:

procedure kurz(...); inline;
begin
  gaaaaaaaaaaanzlang(...);
end;

@ Stevie: Nö, weder XY-Problem, noch Single Level ob abstraction.

Während sich das XY-Problem ja auf den Fragesteller bezieht, wie nennt man es eigentlich, wenn der Antwortende nicht auf die eigentliche Frage eingeht (technische Machbarkeit), sondern statt dessen Vermutungen über Intentionen des Fragestellers oder gegebene Umstände ("sowieso unübersichtlicher Code") anstellt?

@Harry

Du programmierst doch nicht erst seit gestern und du hast bestimmt schon mal eine procedure oder function geschrieben.

Die Lösung ist so naheliegend (siehe himitsu), dass man echt ins Grübeln kommt, was du eigentlich wirklich fragen willst.

Wenn du nur wissen willst, wie man eine procedure oder function mit einem kurzen Namen schreibt, die dann eine procedure oder function mit langem Namen aufruft, dann kann ich irgendwie nur ungläubig mit dem Kopfe schütteln

@Schokohase: Hast Du die Frage genau gelesen?

Ich habe gefragt:

"Ist es eigentlich irgendwie möglich, dem Compiler irgendwelche selbst definierten Abkürzungen (Alias) für lange Funktionsnamen beizubringen?"

Und: Nicht für eigene, sondern für RTL-Funktionen.

Ich wollte da keine Umwege über Pointer oder Aufruf von anderen Funktionen gehen.

Es geht doch z.B.

Type
str = string;

Daher fragte ich mich, ob es so etwas ähnliches nicht auch für Funktionen gibt. Es geht also eher um eine Art Makro-Funktionalität.

Und nein, ich bin mir nicht zu schade, um im Zweifel auch mal eine Frage zu stellen, wo jemand meinen könnte, den Kopf schütteln zu müssen.

Eine alte chinesische Weisheit sagt da:

Wer fragt, ist vielleicht ein Narr für fünf Minuten. Wer nicht fragt, bleibt ein Narr für immer.

Zitat von Harry Stahl:

@ Stevie: Nö, weder XY-Problem, noch Single Level ob abstraction.

Während sich das XY-Problem ja auf den Fragesteller bezieht, wie nennt man es eigentlich, wenn der Antwortende nicht auf die eigentliche Frage eingeht (technische Machbarkeit), sondern statt dessen Vermutungen über Intentionen des Fragestellers oder gegebene Umstände ("sowieso unübersichtlicher Code") anstellt?

Ich sags mal so: was du in deinem eigenen Code, den nur du lesen und warten musst, machst, ist mir herzlich egal - ich sprach das nur an, weil man ja auch manchmal Code schreiben möchte, der auch für andere verständlich ist, und wenn man da plötzlich nur noch TLAs im Code findet, wo man erstmal grübeln muss, was sie bedeuten, dann fördert das nicht die Lesbarkeit. Also entschuldige bitte, wenn ich auch mal über die eigentliche Fragestellung hinausblicke

@Harry Stahl:

Mir fällt nur eine Lösung ein, nicht ganz was du willst aber ...

Erstelle eine Unit, die du in allen Units unter Uses aufführst und schreibe in diese Unit Prozeduren/Funktionen mit den Namen, die Dir gefallen.

Und diese Funktionen rufen dann die Routinen mit den Dir zu langen Namen auf.

Ich hab mal etwas ähnliches gemacht, allerdings mit einer anderen Zielsetzung.

Bei mir war das die Prozedur ShowMessage.
Ich nutze die oft (so wie vermutlich jeder), um irgendwelche Rechenergebnisse, auszugeben.
Irgendwann war ich es leid immer zu schreiben
ShowMessage(IntToStr(A)+', '+IntToStr(B)+', '+IntToStr(C));
oder
ShowMessage(IntToStr(A)#13+IntToStr(B)+#13+IntToStr(C));
Also schuf ich solch eine Unit die u.A. zwei Prozeduren enthielt konnte dann schreiben

Mess([A,B,C]); oder
Mess([A,B,C], #13); oder auch
Mess(IntToStr(A)+' '+IntToStr(B)+' '+IntToStr(C));

zusammenfalten · markieren

Delphi-Quellcode:

interface

uses
   Vcl.Dialogs;

PROCEDURE Mess(const Args:array of const; const Delimiter:String=', '); overload;
PROCEDURE Mess(const S:String); overload;

implementation

PROCEDURE Mess(const Args:array of const; const Delimiter:String=', ');
var I:Integer; S:String;
begin
   for I:=0 to High(Args) do
      with Args[I] do begin
         case VType of
            vtInteger : S:=S+IntToStr(VInteger);
            vtBoolean : S:=S+BoolToStr(VBoolean);
            vtChar : S:=S+VChar;
            vtExtended : S:=S+FloatToStr(VExtended^);
            vtString : S:=S+VString^;
            vtPointer : S:=S+IntToHex(NativeInt(VPointer),SizeOf(Pointer)*2);
            vtPChar : S:=S+VPChar;
            vtObject : S:=S+VObject.ClassName;
            vtClass : S:=S+VClass.ClassName;
            vtWideChar : S:=S+VWideChar;
            vtPWideChar : S:=S+VPWideChar;
            vtAnsiString: S:=S+string(VAnsiString);
            vtCurrency : S:=S+CurrToStr(VCurrency^);
            vtVariant : S:=S+string(VVariant^);
            vtInterface : S:=S+String(VInterface);
            vtInt64 : S:=S+IntToStr(VInt64^);
            else Continue;
         end;
         S:=S+delimiter;
      end;
   if S<>'' then SetLength(S,Length(S)-Length(Delimiter));
   ShowMessage(S);
end;

PROCEDURE Mess(const S:String);
begin
   ShowMessage(S);
end;

end.

@KodeZwerg und @AmateurProfi: Danke für Eure Antworten. Aber ich würde hier keine Lösungen haben wollen, die

A. Das Programm verlangsamen (Funktion ruft zusätzliche Funktion auf).
B. Das Programm größer machen.

Auch wenn beides im Einzelfall vielleicht nicht sonderlich ins Gewicht fallen würde.

Wenn es so etwas gegeben hätte, wie

markieren

Delphi-Quellcode:

Makro
  EFN = ExtractFilename;

Dann wäre das evtl. von Interesse gewesen, aber so etwas gibt's wohl nicht in Pascal/Delphi. Der Compiler hätte dann alle Stellen, wo EFN steht, durch ExtractFileName ersetzt. Dann gäbe es die oben beschriebenen Nachteile nicht.

Dein Vorhaben riecht doch sehr nach Präprozessor, gut, zu einer IDE-Integration kann ich nichts sagen, aber hier gibt es bestimm den einen oder anderen, der weiß wie man so etwas realisieren kann.

Gruß
K-H