AGB  ·  Datenschutz  ·  Impressum  







Anmelden
Nützliche Links
Registrieren
Zurück Delphi-PRAXiS Suchfunktion Ergebnis der Suchanfrage

Ergebnis der Suchanfrage


Datum des Suchindex: Heute, 12:02

Parameter dieser Suchanfrage:

Suche in Thema: "Fehler" bei Überschreiben von Properties
Suche alle Beiträge, die von "3_of_8" geschrieben wurden
• Suchmethode: "Suche nach allen Begriffen"
• Nach Datum (firstpost) sortiert
• Zeige Treffer als Beiträge
Zeige 7 von insges. 7 Treffern
Suche benötigte 0.004s

Es liegen Ergebnisse in folgenden Bereichen vor:

  • Forum: Sonstige Fragen zu Delphi

    Re: "Fehler" bei Überschreiben von Properties

      Delphi
      by 3_of_8, 6. Feb 2007
    *kratz*

    Naja egal. Welche Workaround gibt es da? Einfach die Property in der Oberklasse statt mit Direktzugriff auf die Felder mit einem Setter deklarieren?
  • Forum: Sonstige Fragen zu Delphi

    Re: "Fehler" bei Überschreiben von Properties

      Delphi
      by 3_of_8, 5. Feb 2007
    Ich meinte ja auch, er solle es nur tun, wenn man ansonsten Ärger mit den überschriebenen Properties bekommt.

    Wie gesagt, es ist für mich äußerst... befremdlich/seltsam/gewohnheitsbedürftig, dass TB(a).Foo:=42 etwas anderes bewirkt als a.Foo:=42. Intuitiv würde ich sagen, das widerspricht der "dynamischen Bindung", wenn man so verschiedene Effekte durch Typencasting bei Klassen erreicht.
  • Forum: Sonstige Fragen zu Delphi

    Re: "Fehler" bei Überschreiben von Properties

      Delphi
      by 3_of_8, 5. Feb 2007
    Klar. Aber Delphi kennt virtuelle Methoden, also könnte der Compiler einen virtuellen Setter anlegen anstatt das "write FFoo" wörtlich zu nehmen. Ich habe jedenfalls relativ lange gebraucht, um diesen Fehler zu finden, vor allem deshalb, weil ich an der falschen Stelle gesucht habe. Ich habe mir gedacht "ich habe hier die Property überschrieben, also passt das" und habe Hunderte andere Codezeilen...
  • Forum: Sonstige Fragen zu Delphi

    Re: "Fehler" bei Überschreiben von Properties

      Delphi
      by 3_of_8, 5. Feb 2007
    Das ist mir klar. Deswegen sagte ich ja auch, der Compiler soll in diesem Fall einen VMT-Eintrag anlegen, damit er es weiß.
  • Forum: Sonstige Fragen zu Delphi

    Re: "Fehler" bei Überschreiben von Properties

      Delphi
      by 3_of_8, 5. Feb 2007
    Ja, aber die Instanz ist eine Instanz der Unterklasse. Nur der Instanzenpointer ist halt als Pointer auf die Instanz der Oberklasse deklariert.

    Für mich ist es leicht sinnlos, wenn TB(a).Foo:=42; ein anderes Ergebnis bringt als a.Foo:=42.

    EDIT: Mir ist klar, dass das kein Bug ist, sondern "as designed", aber ich halte das trotzdem für nicht OOP-konzeptgemäß.
  • Forum: Sonstige Fragen zu Delphi

    Re: "Fehler" bei Überschreiben von Properties

      Delphi
      by 3_of_8, 5. Feb 2007
    Das ist es ja: Die soll der Compiler implizit anlegen. Sinngemäß würde ich sagen: Wenn ich die Property in der Unterklasse überschreibe und eine Instanz dieser Unterklasse habe, dann soll der Compiler auch die überschriebene Property aufrufen.
  • Forum: Sonstige Fragen zu Delphi

    "Fehler" bei Überschreiben von Properties

      Delphi
      by 3_of_8, 5. Feb 2007
    Morgen.

    Ich habe gerade eine recht... seltsame Entdeckung bei der Überschreibung von Properties gemacht.

    Es sieht so aus, als würde der Compiler sich gar nicht erst überlegen, ob er die Property der Oberklasse oder die der Unterklasse nimmt. Ich kann das Vorgehen des Compilers zwar verstehen, aber eigentlich müsste er doch bei einer Situation wie der in meinem Testprojekt einen eigenen...


URL zu dieser Suchanfrage:

https://www.delphipraxis.net/dp_search.php?do=usersearch&search_username=3_of_8&search_exact_username=1&search_sortby=dateline&search_resulttype=post&search_matchmode=0&searchthreadid=85851
Impressum · AGB · Datenschutz · Nach oben
Alle Zeitangaben in WEZ +1. Es ist jetzt 12:19 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