String als "normaler" Type

[himitsu]

Morsch'n,

ich hätte ja erwartet, dass es bereits zweimillionen Feature Requests Bug Reports gibt,
wo jemand bittet den string aus den reservierten Wörtern zu entfernen und ein Kamel Dromedar einzubauen.


Aber ich finde irgendwie nichts, wofür ich voten könnte.

[Uwe Raabe]

Was hast du denn an string in seiner jetzigen Form zu bemängeln? (Und was soll das mit dem Dromedar?)

[himitsu]

na ein halbes CamelCase


Ja erstmal das Fett, passt ja sowas von garnicht zu 99,99999999973% aller Typen,
und dann das kleine s, wo alle anderen Typen schon lange erwachsen sind.

[Neutral General]

Zitat von himitsu:

und dann das kleine s, wo alle anderen Typen schon lange erwachsen sind.

Delphi ist ja case insensitiv. Du kannst StRiNg also schreiben wies für dich am besten aussieht

Zitat von himitsu:

Ja erstmal das Fett, passt ja sowas von garnicht zu 99,99999999973% aller Typen,

Delphi-Quellcode:

type
  NonBoldString = String;

Bei dir scheints ja grad ansonsten gut zu laufen

[Stevie]

Zitat von Neutral General:

Delphi-Quellcode:

type
  TNonBoldString = String;

fixed

Gibt's übrigens schon, nennt sich UnicodeString

[Uwe Raabe]

Dann kann man ja auch gleich UnicodeString schreiben.

Zitat:

The type string is an alias for UnicodeString.

[himitsu]

Die böse Codevervollständigung will mir aber immer das Kleine vorschreiben.

Außerdem passt das große String dann nicht mehr zu den anderen kleinen fetten Kindern Wörtern, wie begin (ich dachte man zwingt uns jetzt das mit zwei NN zu schreiben?), end, case, implementation, class usw.



Wie gesagt, ich war mir sicher, dass es sowas schon gibt (hier im Forum gab es auch schon mehrmals was dazu), aber ich finde nichts und wollte jetzt nicht extra ein neue Dupplicat erzeugen.



Witzig, das deutsche Wiki sagt auch, dass String groß geschrieben werden muß. (auch wenn viele Frauen sagen, dass er möglichst klein/dürre zu sein hat)
https://docwiki.embarcadero.com/RADS...mente_(Delphi)

[QuickAndDirty]

Also es gibt ein Problem?
Ich finde irgendwie keins.

@himitsu
Wie steht es mit dem Problem, dass eine Variable vom Functionstyp sich nicht in der Schreibweise unterscheidet, wenn man die Funktion ausführen möchte oder den Variablen Wert auslesen möchte.
Ist das Problem gelöst?

Delphi-Quellcode:

unit Unit1
interface
uses classes, sysutils,usw;
Type
TSimpleFunc = Function:Pointer;

implementation

Function TestF:Pointer;
Begin
  Result := nil;
  Showmessage('tada');
end;

Procedure Do;
var aPointer:Pointer;
    aFunc:TSimpleFunc;
Begin
  aFunc := TestF; // führt es die funktion aus oder speichert es die Adresse der Function in der Functions variable?
  apointer := AFunc as Pointer; // führt es die funktion aus oder liest es den inhalt von der Variable aFunc?
end;

[Uwe Raabe]

Das compiliert schon mal aus diversen Gründen nicht:

1. Do is ein reserved word
2. as kann dort nicht verwendet werden

Weiter gilt: TestF ist zuweisungskompatibel zu aFunc, aber nicht zu aPointer. Der Rückgabewert von TestF ist zuweisungskompatibel zu Pointer, aber nicht zu aFunc. Der Compiler entscheidet entsprechend.

Anders sieht es hier aus:

Delphi-Quellcode:

Function TestF: Pointer;
Begin
  Result := nil;
end;

function TestF1: TSimpleFunc;
begin
  result := TestF;
end;

...
  aFunc := TestF1;   // compiliert nicht
  aFunc := TestF1(); // compiliert

Ich habe mir angewöhnt runde Klammern zu setzen, wenn ich sicherstellen will, dass die Function ausgeführt wird.

Delphi-Quellcode:

  aFunc := TestF;
  apointer := AFunc();

[himitsu]

Ja, man kann könnte &String streiben, dann ist es nicht fett.

* Aber syntaktisch ist es falsch, weil das ja eigentlich besagt, dass es kein reserviertes Wort ist, aber die Hilfe besagt, dass es das ist.
(man will ja den "String" haben und nicht was Anderes, das nur zufällig genaus heißt)

* Und außerdem werden & und [Attribute] von der Codevervollständigung vergessen (Bug wird am WE noch gemeldet).


https://docwiki.embarcadero.com/RADS...mente_(Delphi)

* Einige der reservierten Wörter könnte man endlich mal enternen
* * String
* * und ein paar Andere werden seit 20 Jahren in Pascal DelphiLanguage garnicht mehr genutzt, also sinnlos die noch reserviert zu lassen

* und bei den Direktiven sind Zwei seit über 20 Jahren drin, die eigentlich reservierte Wörter sind (werden zwar nebenbei als Hinweise erwähnt, aber wird Zeit die endlich mal zu verschieben)

* und es gibt garkeinen Grund, dass Direktiven "überall" Fett sind (sind Einige auch nicht) aber im Funktionscode fast alle,
obwohl sie "außschließlich hinter Typen-, Methoden- und Property-Deklarationen eine Funktion haben.
Also nur dort haben sie eine Funktion und überall Anders können sie problemlos als Name (Typen/Varablen/Konstanten/Methoden/Parameter) verwendet werden. (nur der Highlighter ist zu doof es halbwegs richtig zu machen)