AW: Lazarus 1.2 veröffentlicht
Zitat:
http://www.dpunkt.de/java/Die_Sprach...t_Java/57.html Demnach geht das. Sollte das in ObjectPascal wirklich anders sein? Interfaces sind doch eine in Windows integrierte Technik. Warum sollte das dann nur in Java oder C++ klappen? Hab das aber jetzt nicht getestet. |
AW: Lazarus 1.2 veröffentlicht
Zitat:
Interfaces in Java haben mit Interfaces in Windows auch keinerlei Beziehung. Die Java Sprachdefinition ist plattformunabhängig, auf der Windows Plattform werden Java Interfaces nicht durch Windows Interfaces realisiert. |
AW: Lazarus 1.2 veröffentlicht
Zitat:
Nur Implementierungs-Vorschriften. |
AW: Lazarus 1.2 veröffentlicht
C++ hat keine Interfaces. Das 'Interface' das am Windows so herumschwirrt ist ein Konstrukt der MS Welt der gute alte MS-RPC die IDL davon. In der Praxis eine struct mit virtuelle Methoden in MS C/C++.
Die Interfaces der MS kommen ursprünglich aus dem OSD/DCE Umfeld, RPC letztendlich. Im Prinzip geht es um Beschreibungen von Komponenten. Etwas flachsig formuliert in der der C Welt - ein im System registrierte Headerfile in einer anderen Syntax geschrieben. Einsicht wurde genommen am Windows mit dem COM Browser. Die MS hat mal behauptet diese IL weitergetrieben zu haben, damit sie das Office in Griff bekommen. 'Ist die Funktion installier?'. An sich ist ein Interface einer Klasse jener Teil in dem Eigenschaften und das Verhalten deklariert sind. Aus sicht der Sprache. Im Prinzip eine abstrakte Basisklasse ohne Implementierung im Falle Mehrfachvererbung wäre ähnlich. Am einfachsten ist die Vorstellung es Interfaces als Registrierungsinformation gegen die eine Implementierung geprüft wird. 'Gibt es die Funktion überhaupt?'. Interface- und Implementierungsvererbung sind 2 verschiedene Paar Schuhe. Man nimmt heute Interfaces in einem ganz anderen Umfeld als sie ursprünglich gedacht waren. Das Umfeld Abstrakter Datentyp ... die Sehnsucht nach selbigen drückt sich heute in den Generics aus. Die haben mit OO nichts zu tun. Früher war das technisch in Pascal ein Pointer. Container waren der Paradefall für ADTs. Wo findet man heut Generics :thumb: Zitat:
|
AW: Lazarus 1.2 veröffentlicht
Zitat:
Delphi-Quellcode:
in
csDesigning
Delphi-Quellcode:
gibt es nicht zum Spaß). Zum Finden der Ereignisse und zum laden/speichern der LFM/DFM wird die RTTI benötigt und die Klasse muss dem Komponenten Streaming System bekannt sein.
TComponentState
Aus diesem Grund musst du übrigens die Lazarus IDE nur neukompilieren, wenn du entweder ein Package installierst, welches die IDE erweitert, oder, wenn du Komponenten im Formdesigner verwenden möchtest. Legst du die Komponenten nur zur Laufzeit an, dann reicht es, wenn Lazarus das Package kennt (soll heißen: du hast einmal die LPK-Datei geöffnet) und du die entsprechende Abhängigkeit im Projektinspektor einstellst. Zitat:
Delphi-Quellcode:
der IDE nicht das selbe
TComponent
Delphi-Quellcode:
der Bibliothek ist. Das heißt, für eine Komponente, die in der IDE instantiiert wird, aber in einer DLL implementiert ist, wird
TComponent
Delphi-Quellcode:
innerhalb der IDE nie
is TComponent
Delphi-Quellcode:
zurück geben. Auch Exceptions in den Komponenten können dadurch nicht abgefangen werden, da selbst ein
true
Delphi-Quellcode:
fehlschlagen würde, da auch
on e: TObject do {...}
Delphi-Quellcode:
in der IDE und
TObject
Delphi-Quellcode:
in der DLL unterschliedliche Typen sind. Das ist einer der Hauptgründe, weswegen Dynamic Packages entwickelt wurden: dabei wird die RTL in eine eigene Bibliothek (Package) ausgelagert und sowohl IDE, als auch die Komponenten Bibliothek (Package) können diese verwenden und der Compiler kümmert sich darum, dass bezüglich Abhängigkeiten alles passt und somit auch nur eine einzige Art von
TObject
Delphi-Quellcode:
,
TObject
Delphi-Quellcode:
oder
Exception
Delphi-Quellcode:
existiert.
TComponent
Ganz davon abgesehen würde dies dazu führen, dass die Komponente extra für Lazarus angepasst werden müsste (ich sehe jetzt hier mal von anderen Problemen mit der Kompatibilität ab), was hieße, dass es noch weniger Komponenten für Lazarus gäbe, als es eh schon der Fall ist. Gruß, Sven |
AW: Lazarus 1.2 veröffentlicht
Zitat:
So ähnlich macht man es ja bei Interfaces mit den GUIDs auch. Prinzipiell sollte das doch auch bei Klassen funktionieren, oder nicht? Ein Problem sehe ich nur, wenn verschiedene Packages von unterschiedlichen Versionen eines gemeinsam genutzten Packages ausgehen. Aber das dürfte dann bei dynamischen Packages ebenfalls Probleme geben, denke ich mal. |
AW: Lazarus 1.2 veröffentlicht
Nein.
In einem Package kann man mehrere Klassen haben, die gleich heißen. Und es könnte auch andere Packages geben, welche den selben Namen haben. |
AW: Lazarus 1.2 veröffentlicht
Zitat:
Zitat:
|
AW: Lazarus 1.2 veröffentlicht
Zitat:
Zitat:
Warum etwas neues erfinden, wenn es etwas Funktionierendes bereits gibt, dass nur noch implementiert werden muss? Und wie gesagt, so aufwendig ist das neukompilieren von Lazarus auch nicht... Gruß, Sven |
AW: Lazarus 1.2 veröffentlicht
Inzwischen haben wir schon Latarus 1.4!
|
Alle Zeitangaben in WEZ +1. Es ist jetzt 15:21 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