AGB  ·  Datenschutz  ·  Impressum  







Anmelden
Nützliche Links
Registrieren

Lazarus 1.2 veröffentlicht

Ein Thema von JamesTKirk · begonnen am 11. Mär 2014 · letzter Beitrag vom 20. Aug 2019
Antwort Antwort
Seite 3 von 4     123 4   
schöni

Registriert seit: 23. Jan 2005
Ort: Dresden
445 Beiträge
 
Delphi 7 Personal
 
#21

AW: Lazarus 1.2 veröffentlicht

  Alt 14. Mär 2014, 12:57
Zitat von QuickAndDirty:
Aber wie willst du von einer nur als Interface verfügbaren Komponente erben?
Hmmm, hab da soeben mal gegoogelt und das hier gefunden:

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.
Damit der Topf nicht explodiert, lässt man es ab und zu mal zischen.
  Mit Zitat antworten Zitat
mjustin

Registriert seit: 14. Apr 2008
2.735 Beiträge
 
Delphi 2009 Professional
 
#22

AW: Lazarus 1.2 veröffentlicht

  Alt 14. Mär 2014, 16:50
Zitat von QuickAndDirty:
Aber wie willst du von einer nur als Interface verfügbaren Komponente erben?
Hmmm, hab da soeben mal gegoogelt und das hier gefunden:

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?
Der Artikel beschreibt nur die Möglichkeiten ein Java Interface durch Vererbung abzuleiten und zu erweitern. Aber auch in Java kann man eine "Komponente" (also eine konkrete, nicht vollständig abstrakte Klasse), von der nur das von ihr implementierte Interface bekannt ist, nicht durch Vererbung des Interface erweitern.

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.
Michael Justin
habarisoft.com
  Mit Zitat antworten Zitat
QuickAndDirty

Registriert seit: 13. Jan 2004
Ort: Hamm(Westf)
1.529 Beiträge
 
Delphi 10.2 Tokyo Professional
 
#23

AW: Lazarus 1.2 veröffentlicht

  Alt 14. Mär 2014, 17:43
Hab das aber jetzt nicht getestet.
Wenn man von einem Interface erbt dann erbt man keine Funktionalität!
Nur Implementierungs-Vorschriften.
Andreas
#PerfMatters
  Mit Zitat antworten Zitat
michaelthuma
(Gast)

n/a Beiträge
 
#24

AW: Lazarus 1.2 veröffentlicht

  Alt 14. Mär 2014, 21:33
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


Zitat von QuickAndDirty:
Aber wie willst du von einer nur als Interface verfügbaren Komponente erben?
Hmmm, hab da soeben mal gegoogelt und das hier gefunden:

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.
  Mit Zitat antworten Zitat
Benutzerbild von JamesTKirk
JamesTKirk

Registriert seit: 9. Sep 2004
Ort: Eberfing
597 Beiträge
 
FreePascal / Lazarus
 
#25

AW: Lazarus 1.2 veröffentlicht

  Alt 16. Mär 2014, 17:08
Die hier zitierten Argumente relativieren das Package Problem nun auch wieder, aber für mich ist und bleibt dieses Problem auch ein interessanter Aspekt. Ich habe nämlich noch immer nicht verstanden, warum hier die totale Neuübersetzung überhaupt erforderlich ist. Mir ist klar, das dies der Fall ist, wenn die Komponenten als neue Units statisch eingebunden werden. ABER: Kann man diese nicht auch als normale Dlls einbinden, per Interfaces?
Lazarus und Delphi instanziieren die Komponenten und rufen deren Methoden auf (das csDesigning in TComponentState 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.

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.

Ein Komponentenmanager könnte so aussehen (nur Interface)

type
IComponentFactory = Interface(IInterface)
function GetComponents(Index: Integer): TComponent;
procedure SetComponents(Index: Integer; value: TComponent);
property Components[Index]: TComponentList read GetComponents write SetComponents;
property ComponentCount: Integer; //Anzahl aktuell in IDE verfügbare Komponenten
end;

Nun müssten die Komponenten von außen per dll angeschlossen werden;

Wo ist da mein Denkfehler, wenn da einer ist?
Ein ganz, ganz wichtiger Denkfehler: Ohne Dynamic Packages gilt, dass TComponent der IDE nicht das selbe TComponent der Bibliothek ist. Das heißt, für eine Komponente, die in der IDE instantiiert wird, aber in einer DLL implementiert ist, wird is TComponent innerhalb der IDE nie true zurück geben. Auch Exceptions in den Komponenten können dadurch nicht abgefangen werden, da selbst ein on e: TObject do {...} fehlschlagen würde, da auch TObject in der IDE und TObject 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 , Exception oder TComponent existiert.

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
Sven
[Free Pascal Entwickler]
this post is printed on 100% recycled electrons
  Mit Zitat antworten Zitat
Namenloser

Registriert seit: 7. Jun 2006
Ort: Karlsruhe
3.724 Beiträge
 
FreePascal / Lazarus
 
#26

AW: Lazarus 1.2 veröffentlicht

  Alt 16. Mär 2014, 19:42
Ein ganz, ganz wichtiger Denkfehler: Ohne Dynamic Packages gilt, dass TComponent der IDE nicht das selbe TComponent der Bibliothek ist. Das heißt, für eine Komponente, die in der IDE instantiiert wird, aber in einer DLL implementiert ist, wird is TComponent innerhalb der IDE nie true zurück geben.
Aber ist das nicht eher ein Implementierungsdetail? Könnte man nicht eine ID aus Klasse, Package und ggf. Versionsnummer bilden und diese in der Klasse als Metainformation ablegen? Dann sollte man die Gleichheit bzw. Kompatiblität auch überprüfen können, wenn die Klassen nicht an der selben Stelle im Speicher stehen.

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.
  Mit Zitat antworten Zitat
Benutzerbild von himitsu
himitsu

Registriert seit: 11. Okt 2003
Ort: Elbflorenz
34.931 Beiträge
 
Delphi 10.2 Tokyo Professional
 
#27

AW: Lazarus 1.2 veröffentlicht

  Alt 16. Mär 2014, 22:05
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.
Garbage Collector ... Delphianer erzeugen keinen Müll, also brauchen sie auch keinen Müllsucher.
Delphi-Tage 2005-2014
  Mit Zitat antworten Zitat
Namenloser

Registriert seit: 7. Jun 2006
Ort: Karlsruhe
3.724 Beiträge
 
FreePascal / Lazarus
 
#28

AW: Lazarus 1.2 veröffentlicht

  Alt 16. Mär 2014, 22:16
In einem Package kann man mehrere Klassen haben, die gleich heißen.
Der Name muss natürlich vollständig qualifiziert sein, also auch die Unit und ggf. die Oberklasse und Routine enthalten, wo die Klasse deklariert wurde.
Und es könnte auch andere Packages geben, welche den selben Namen haben.
Das Problem hat man doch so oder so.
  Mit Zitat antworten Zitat
Benutzerbild von JamesTKirk
JamesTKirk

Registriert seit: 9. Sep 2004
Ort: Eberfing
597 Beiträge
 
FreePascal / Lazarus
 
#29

AW: Lazarus 1.2 veröffentlicht

  Alt 17. Mär 2014, 06:39
Aber ist das nicht eher ein Implementierungsdetail? Könnte man nicht eine ID aus Klasse, Package und ggf. Versionsnummer bilden und diese in der Klasse als Metainformation ablegen? Dann sollte man die Gleichheit bzw. Kompatiblität auch überprüfen können, wenn die Klassen nicht an der selben Stelle im Speicher stehen.
Warum soll man eine ID bilden müssen, wenn man eine perfekte ID bereits hat: der VMT Zeiger. Man sollte ein System nicht unnötig kompliziert machen... Ganz davon abgesehen müsstest du die ganze RTL erstmal anpassen, dass die das verwendet... Außerdem hast du immernoch das Problem mit der RTTI und dem Streaming System.

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.
Der Compiler stopft die Packages mit den nötigen Metainformationen voll, so dass zur Laufzeit überprüft werden kann, ob alles passt. Nicht umsonst gibt es den berühmten Dialog beim Start von Delphi, dass dieses und jenes Package aus irgendeinem Grund nicht geladen werden konnte...

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
Sven
[Free Pascal Entwickler]
this post is printed on 100% recycled electrons
  Mit Zitat antworten Zitat
AlexII

Registriert seit: 28. Apr 2008
1.707 Beiträge
 
FreePascal / Lazarus
 
#30

AW: Lazarus 1.2 veröffentlicht

  Alt 24. Jun 2015, 09:28
Inzwischen haben wir schon Latarus 1.4!
Bin Hobbyprogrammierer! Meine Fragen beziehen sich meistens auf Lazarus!
  Mit Zitat antworten Zitat
Themen-Optionen Thema durchsuchen
Thema durchsuchen:

Erweiterte Suche
Ansicht

Forumregeln

Es ist dir nicht erlaubt, neue Themen zu verfassen.
Es ist dir nicht erlaubt, auf Beiträge zu antworten.
Es ist dir nicht erlaubt, Anhänge hochzuladen.
Es ist dir nicht erlaubt, deine Beiträge zu bearbeiten.

BB-Code ist an.
Smileys sind an.
[IMG] Code ist an.
HTML-Code ist aus.
Trackbacks are an
Pingbacks are an
Refbacks are aus

Gehe zu:

Impressum · AGB · Datenschutz · Nach oben
Alle Zeitangaben in WEZ +1. Es ist jetzt 20:52 Uhr.
Powered by vBulletin® Copyright ©2000 - 2019, Jelsoft Enterprises Ltd.
LinkBacks Enabled by vBSEO © 2011, Crawlability, Inc.
Delphi-PRAXiS (c) 2002 - 2019 by Daniel R. Wolf