String als "normaler" Type
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. :gruebel: |
AW: Sting als "normaler" Type
Was hast du denn an string in seiner jetzigen Form zu bemängeln? (Und was soll das mit dem Dromedar?)
|
AW: Sting als "normaler" Type
na ein halbes CamelCase :stupid:
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. |
AW: Sting als "normaler" Type
Zitat:
Zitat:
Delphi-Quellcode:
Bei dir scheints ja grad ansonsten gut zu laufen :duck:
type
NonBoldString = String; |
AW: Sting als "normaler" Type
Zitat:
Gibt's übrigens schon, nennt sich UnicodeString |
AW: Sting als "normaler" Type
Dann kann man ja auch gleich UnicodeString schreiben.
Zitat:
|
AW: Sting als "normaler" Type
Die böse Codevervollständigung will mir aber immer das Kleine vorschreiben. :cry:
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) |
AW: String als "normaler" Type
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; |
AW: String als "normaler" Type
Das compiliert schon mal aus diversen Gründen nicht:
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:
Ich habe mir angewöhnt runde Klammern zu setzen, wenn ich sicherstellen will, dass die Function ausgeführt wird.
Function TestF: Pointer;
Begin Result := nil; end; function TestF1: TSimpleFunc; begin result := TestF; end; ... aFunc := TestF1; // compiliert nicht aFunc := TestF1(); // compiliert
Delphi-Quellcode:
aFunc := TestF;
apointer := AFunc(); |
AW: String als "normaler" Type
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) |
AW: Sting als "normaler" Type
Zitat:
Code:
Was ist denn nun richtig?
System.StringFrom RAD Studio API Documentation
Up to Parent: System Delphi type String = UnicodeString; |
AW: String als "normaler" Type
Auf der Englischen Seite wird es klein geschrieben. Das kann also einfach ein Fehler beim Übersetzen sein.
Grundsätzlich ist die Großschreibung von String als Substantiv im Deutschen Fließtext ja durchaus richtig. Das ändert aber nichts an der kleinen Schreibweise im Programmcode. |
AW: String als "normaler" Type
Zitat:
|
AW: String als "normaler" Type
Klammern (eine "leere" Parameterliste) führen immer aus.
Bei ( bei Methodenzeigern oder . für Record-Pointer wird immer implizit dereferenziert. Normal wird ein Methodenzeiger meistens ausgeführt, außer links steht ein Zeiger/Pointer, also bei Zuweisung an Variable, Property oder Parameter, wo Delphi vorzeugsweise den Zeiger nimmt und nicht ausführt (außer eben wenn mit Klammer). Schwierig wird es nur, wenn die Funktion in dem Zeiger selber einen Zeiger/Pointer als Result liefert ... dann weiß ich ohne () auch nie, ob nun die Funktion ausgeführt wird und dann deren Result genomen wird oder ob die Variable selber zurückgegeben wird. :freak: Wie gesagt, ALLE anderen Variablen sind Groß und nicht fett ... wieso sollte dann der String nicht auch mal "normal" sein? Eigentlich dachte ich ich sei nicht der Einzige ... nur finde ich eben keine bestehende RSP, wo ich mich anhängen wollte, als "schonwieder" es "neu" zu melden und als Dupplikat geschlossen zu werden. :duck: OK, dann erstmal was Anderes, dass auch schon seit Jahren nervt, wobei aber erstmal nichts Bestehendes verändert wird. https://quality.embarcadero.com/browse/RSP-39528 https://quality.embarcadero.com/browse/RSP-39530 |
Alle Zeitangaben in WEZ +1. Es ist jetzt 12:33 Uhr. |
Powered by vBulletin® Copyright ©2000 - 2024, Jelsoft Enterprises Ltd.
LinkBacks Enabled by vBSEO © 2011, Crawlability, Inc.
Delphi-PRAXiS (c) 2002 - 2023 by Daniel R. Wolf, 2024 by Thomas Breitkreuz