Lazarus 1.2 veröffentlicht

[JamesTKirk]

Hallo zusammen!

Vor kurzem wurde Lazarus 1.2 veröffentlicht und ich gebe hier mal die inoffiziell von mir übersetzte Mitteilung wieder.

Zitat:

Das Lazarus Team freut sich die Veröffentlichung von Lazarus 1.2 bekannt zu geben.

Das Release wurde mit fpc 2.6.2 gebaut.

Hier ist die Liste der Änderungen für Lazarus und Free Pascal:
http://wiki.lazarus.freepascal.org/L..._release_notes

Unter Windows erlaubt der Installer nun 2 unabhängige Installationen.
http://wiki.lazarus.freepascal.org/M...ltiple_Lazarus

Der Download des Release steht unter SourceForge zur Verfügung:
http://sourceforge.net/projects/lazarus/files/

Wähle deine CPU, OS, Distribution and dann das "Lazarus 1.2" Verzeichnis.
Windows x64 Anwender: bitte benutze den 32 Bit Installer wenn möglich. Siehe http://wiki.lazarus.freepascal.org/W...ort_for_SEH.29 für weitere Informationen.

Mindestanforderungen:
Windows: 98
FreeBSD/Linux: gtk 2.8 oder qt4.5, 32 oder 64 Bit
Mac OS X: 10.5 für Intel CPUs, 10.4 für PowerPC, LCL nur 32bit, non-LCL Anwendungen können auch 64 Bit sein

Der SVN Tag ist
http://svn.freepascal.org/svn/lazarus/tags/lazarus_1_2

Für Leute die keinen Zugriff auf SF haben sind die Lazarus Releases von SourceForge hier gespiegelt:
ftp://freepascal.dfmk.hu/pub/lazarus/releases/
und später unter (nach einiger Zeit für die Synchronisation)
http://michael-ep3.physik.uni-halle....arus/releases/
und
http://mirrors.iwi.me/lazarus/

Gruß,
Sven

PS: Würde bitte jemand den 1.0 Sticky entfernen? Danke. :)

[Sir Rufo]

Klitzekleiner Wermutstropfen

Zitat:

LazUtils CreateRelativePath behaviour changed

• Old behaviour: if a relative path could be constructed, this was sometimes appended with a pathdelimiter, and sometimes not.
• New behaviour: no pathdelimiter is appended.

Hmmm, ein Path ist deswegen ein Path, weil am Ende ein PathDelimiter ist.
Ohne ist es ein Directory oder File. :roll:

Na dafür ist es jetzt aber wohl durchgängig falsch im Sinne des Kontexts/der Benennung :)

[michaelthuma]

Läuft ganz gut. Auf jeden Fall in den Linux Boxen ...

Zitat:

Zitat von JamesTKirk (Beitrag 1251477)

Hallo zusammen!

[JamesTKirk]

Zitat:

Zitat von Sir Rufo (Beitrag 1251481)

Klitzekleiner Wermutstropfen

Zitat:

LazUtils CreateRelativePath behaviour changed

• Old behaviour: if a relative path could be constructed, this was sometimes appended with a pathdelimiter, and sometimes not.
• New behaviour: no pathdelimiter is appended.

Hmmm, ein Path ist deswegen ein Path, weil am Ende ein PathDelimiter ist.
Ohne ist es ein Directory oder File. :roll:

Na dafür ist es jetzt aber wohl durchgängig falsch im Sinne des Kontexts/der Benennung :)

Ich glaub der Grund war, dass

Delphi-Quellcode:

CreateRelativePath

durchaus auch mit Dateinamen verwendet wird und die Funktion kann nicht unterscheiden, ob es sich dabei jetzt um ein Verzeichnis oder eine Datei handelt (die Datei/das Verzeichnis könnte zum Beispiel noch gar nicht existieren und "Dateinamen haben immer nen Punkt"/"Verzeichnisse haben nie einen" gelten als Heuristik nicht...). Deswegen wurde entschieden besser nichts anzuhängen.

Gruß,
Sven

[Sir Rufo]

Wenn ich es jetzt nochmal lese und es wirklich so umgesetzt wurde, wie es dort beschrieben ist,

Zitat:

LazUtils CreateRelativePath behaviour changed

• Old behaviour: if a relative path could be constructed, this was sometimes appended with a pathdelimiter, and sometimes not.
• New behaviour: no pathdelimiter is appended.

dann wäre es sogar korrekt ...

Code:

PATH: C:\foo\bar\ => ..\bar\
FILE: C:\foo\bar\testfile.txt => ..\bar\testfile.txt
DIR : C:\foo\bar\testdir => ..\bar\testdir
FILE: C:\foo\bar\testfile => ..\bar\testfile

Und die Unterscheidung ob Datei oder Verzeichnis ist sowieso egal, der PathDelimiter am Ende darf einfach nicht entfernt oder angehängt werden.

[AlexII]

Lazarus ist inzwischen sehr gut geworden und reif für die eine oder andere Anwendung. Ich denke Lazarus ist bereits für Schulen gut geeignet. :thumb: Schon bald ist es auch für Unis reif.

[QuickAndDirty]

Zitat:

Zitat von AlexII (Beitrag 1251658)

Lazarus ist inzwischen sehr gut geworden und reif für die eine oder andere Anwendung. Ich denke Lazarus ist bereits für Schulen gut geeignet. :thumb: Schon bald ist es auch für Unis reif.

Ich arbeite gerne damit. Allerdings fehlt wirklich sowas wie ein Package-Konzept(dynamisch gelinkte Packages) für FreePascal! Es fehlt doch noch?
Es kann doch nicht angehen das man für jede Komponente die komplette IDE neu kompilieren muss.
Das erschwert unnötig einen Professionellen Ansatz mit massig zugekaufter Vorleistung.

[JamesTKirk]

Zitat:

Zitat von Sir Rufo (Beitrag 1251605)

Und die Unterscheidung ob Datei oder Verzeichnis ist sowieso egal, der PathDelimiter am Ende darf einfach nicht entfernt oder angehängt werden.

Ich weiß grad leider nicht, wie's konkrekt umgesetzt wurde. Das müsste man also ausprobieren...

Zitat:

Zitat von QuickAndDirty (Beitrag 1251680)

Ich arbeite gerne damit. Allerdings fehlt wirklich sowas wie ein Package-Konzept(dynamisch gelinkte Packages) für FreePascal! Es fehlt doch noch?

Ja, das fehlt noch. Ich habe letztes Jahr mal damit begonnen, dass umzusetzen, aber überraschenderweise ist besonders die Unterstützung unter Windows recht schwierig (wegen indirekter Auflösung von globalen Variablen, die unterschiedlichen Code für Package/nicht-Package benötigt...)

Zitat:

Es kann doch nicht angehen das man für jede Komponente die komplette IDE neu kompilieren muss.

Wieso? Angenehmer geht es doch kaum: Klick auf den passenden Menüeintrag und fertig. Im Normalfall werden sogar nur die neuen Packages neu kompiliert und dann die IDE neu gelinkt. Das geht selbst auf meinem betagten 800 MHz/1 GB Rechner relativ flott (zumindest schneller als das Kompilieren von manchen C Projekt :P ).

Gruß,
Sven

[QuickAndDirty]

Zitat:

Zitat von JamesTKirk (Beitrag 1251813)

Zitat:

Zitat von QuickAndDirty (Beitrag 1251680)

Ich arbeite gerne damit. Allerdings fehlt wirklich sowas wie ein Package-Konzept(dynamisch gelinkte Packages) für FreePascal! Es fehlt doch noch?

Ja, das fehlt noch. Ich habe letztes Jahr mal damit begonnen, dass umzusetzen, aber überraschenderweise ist besonders die Unterstützung unter Windows recht schwierig (wegen indirekter Auflösung von globalen Variablen, die unterschiedlichen Code für Package/nicht-Package benötigt...)

Wenn man erstmal die LCL in 'nem Dynamisch linkbaren Package hat, ist es dann nicht auch möglich ein Freepascal+LCL Plugin für Visualstudio und Eclipse zu bauen?
:duck:

[Patito]

Zitat:

Zitat von QuickAndDirty (Beitrag 1251680)

Ich arbeite gerne damit. Allerdings fehlt wirklich sowas wie ein Package-Konzept(dynamisch gelinkte Packages) für FreePascal!

Das erschwert unnötig einen Professionellen Ansatz mit massig zugekaufter Vorleistung.

Das habe ich früher auch mal gedacht, aber qualitativ gute 3rd-Party Libraries (für Excel, Word, pdf, CAD, Geräte-Steuersoftware...)
gibt es doch eher selten als (proprietäres versionsabhähgiges) Delphi-Packages, normalerweise kauft man so ein qualitativ hochwertiges
Ding als DLL. Dafür gibt es dann einen freien Open-Source Pascal-Wrapper und gut.

Nur Hersteller von GUI-Komponenten haben natürlich ein Problem, wenn sie eine Trial-Version herausgeben wollen.
Richtig kaufen sollte man solche Komponenten ja sowieso nicht ohne Source.

Da müssen die Leute eben kreativ sein und sich was einfallen lassen. Letztenendes ist es aber nur ein DRM-Problem (wie verschleiere ich mein Produkt)
und kein technologisches (wie wird das Produkt besser) - und daher sind mir Packages für ein OpenSource-Projekt wie FreePascal inzwischen sowas von egal...

[michaelthuma]

Für IntelliJ gibt es zumindest ein FPC Plugin ... zumindest FPC.PasIdea Grad auch in der community edition die Android support hat. Ist bestimmt noch einiges zu tun.

Zitat:

Zitat von QuickAndDirty (Beitrag 1251847)

Wenn man erstmal die LCL in 'nem Dynamisch linkbaren Package hat, ist es dann nicht auch möglich ein Freepascal+LCL Plugin für Visualstudio und Eclipse zu bauen?
:duck:

[Sir Rufo]

Zitat:

Zitat von JamesTKirk (Beitrag 1251813)

Zitat:

Zitat von Sir Rufo (Beitrag 1251605)

Und die Unterscheidung ob Datei oder Verzeichnis ist sowieso egal, der PathDelimiter am Ende darf einfach nicht entfernt oder angehängt werden.

Ich weiß grad leider nicht, wie's konkrekt umgesetzt wurde. Das müsste man also ausprobieren...

Nö, es kommt immer ein Ergebnis ohne PathDelimiter raus, egal was man da rein gibt ... kann doch nicht so schwer sein ... obwohl, evtl. war das vorher so und haben die das geändert, weil die meisten damit nicht zurechtkamen ;)

[QuickAndDirty]

Zitat:

Zitat von michaelthuma (Beitrag 1251857)

Für IntelliJ gibt es zumindest ein FPC Plugin ... zumindest FPC.PasIdea Grad auch in der community edition die Android support hat. Ist bestimmt noch einiges zu tun.

Zitat:

Zitat von QuickAndDirty (Beitrag 1251847)

Wenn man erstmal die LCL in 'nem Dynamisch linkbaren Package hat, ist es dann nicht auch möglich ein Freepascal+LCL Plugin für Visualstudio und Eclipse zu bauen?
:duck:

Super, aber wie bekommen wir da unseren visuellen GUI Editor?
Ich denke dazu braucht es dynamisch linkbare Packages.

[michaelthuma]

Wäre sehr ungewöhnlich würde ein GUI Editor in dem Umfeld mitgeliefert werden. Wer nimmt Java und Anverwandtes für visuelle Entwicklung... Das wird wohl für Lazarus oder ähnliche Alternativen reserviert bleiben. Ich finde allein recht nett, dass auch mal eine andere IDE überhaupt mal ein Pascal mitberücksichtigt.

Auch wenn bspw. sehr viel geschimpft wird über den FM. Das potentielle Interesse von jenen die solch eine erquickliche Kombi benötigen ist schon da oder wird zumindest als spannend bis praktisch empfunden. Genauso wie die DB Anbindung von FPC oder Delphi allgemein ...

Zitat:

Zitat von QuickAndDirty (Beitrag 1251881)

Zitat:

Zitat von michaelthuma (Beitrag 1251857)

Für IntelliJ gibt es zumindest ein FPC Plugin ... zumindest FPC.PasIdea Grad auch in der community edition die Android support hat. Ist bestimmt noch einiges zu tun.

Zitat:

Zitat von QuickAndDirty (Beitrag 1251847)

Wenn man erstmal die LCL in 'nem Dynamisch linkbaren Package hat, ist es dann nicht auch möglich ein Freepascal+LCL Plugin für Visualstudio und Eclipse zu bauen?
:duck:

Super, aber wie bekommen wir da unseren visuellen GUI Editor?
Ich denke dazu braucht es dynamisch linkbare Packages.

[Popov]

Zitat:

Zitat von Sir Rufo (Beitrag 1251864)

Nö, es kommt immer ein Ergebnis ohne PathDelimiter raus, egal was man da rein gibt ... kann doch nicht so schwer sein ... obwohl, evtl. war das vorher so und haben die das geändert, weil die meisten damit nicht zurechtkamen ;)

Ich persönlich vertraue nie drauf, dass da wo Path steht, immer auch ein PathDelimiter am Ende steht. Ich weiß, dass es bei ExtractFilePath so ist und dementsprechend bei ExtractFileDir nicht, also alles der Regel nach. Das sind aber auch die einzigen Funktionen denen ich blind vertraue, muss ich auch, denn das muß ja funktionieren: ExtractFilePath(s) + 'Datei.dat'. Ansonsten sind in meinen Codes tausende von IncludeTrailingPathDelimiter Funktionen verteilt. Selbst meinen Funktionen traue ich nicht, obwohl ich mich an die Konvention halt. Man kann es mal vergessen. Aber sicher ist sicher.

[himitsu]

Wobei ExtractFilePath und ExtractFileDir auch ihre Bugs haben.

Denn bei den Rootpfaden muß auch ein DIR den Backslash am Ende haben!

C: ist das Laufwerk, aber C:\ ist der Path/Dir, denn C: ist relativ zum CurrentDir des Laufwerks.

[Sir Rufo]

Zitat:

Zitat von himitsu (Beitrag 1251911)

Wobei ExtractFilePath und ExtractFileDir auch ihre Bugs haben.

Denn bei den Rootpfaden muß auch ein DIR den Backslash am Ende haben!

C: ist das Laufwerk, aber C:\ ist der Path/Dir, denn C: ist relativ zum CurrentDir des Laufwerks.

Das Root-Verzeichnis nimmt hier eine Sonderrolle ein, da es keinen Namen dafür gibt (Root ist nur eine Bezeichnung).
Es wird lediglich durch den Laufwerksbuchstaben (C:) bzw. Freigabe (\\myserver\data) und dem darauf folgenden PathDelimiter bestimmt.

[JamesTKirk]

Zitat:

Zitat von QuickAndDirty (Beitrag 1251847)

Wenn man erstmal die LCL in 'nem Dynamisch linkbaren Package hat, ist es dann nicht auch möglich ein Freepascal+LCL Plugin für Visualstudio und Eclipse zu bauen?

Warum sollte ich mir dieses schwergewichtige Eclipse antun, wenn Lazarus um ein vielfaches performanter ist? Und die Unterstützung von Pascal Code (Refactoring, etc.) ist sicherlich auch nicht auf nem ähnlichen Level wie in Lazarus, da in letzterem die Entwickler selbst in Lazarus arbeiten und dadurch fehlende Featues leicht ins Auge fallen. Von Visual Studio will ich da noch gar nicht mal reden, das hat ja nichtmal rudimentären Pascal Support (das Oxygene Plugin mal ausgenommen).

Nichtsdestotrotz würde technisch natürlich nichts dagegen sprechen...

Zitat:

Zitat von Patito (Beitrag 1251851)

Nur Hersteller von GUI-Komponenten haben natürlich ein Problem, wenn sie eine Trial-Version herausgeben wollen.
Richtig kaufen sollte man solche Komponenten ja sowieso nicht ohne Source.

Ich glaub DevArt bietet ne Trial seiner *DAC Komponenten an, welche dann halt für ne bestimmte Free Pascal Version ist (wenn keine IDE-Integration benötigt wird, dann muss man es nichtmal von der Lazarus Version abhängig machen).

Gruß,
Sven

[schöni]

Zitat:

Zitat von JamesTKirk

Ja, das fehlt noch. Ich habe letztes Jahr mal damit begonnen, dass umzusetzen, aber überraschenderweise ist besonders die Unterstützung unter Windows recht schwierig (wegen indirekter Auflösung von globalen Variablen, die unterschiedlichen Code für Package/nicht-Package benötigt...)

Zitat:

Zitat von Patito

Zitat:

Zitat von QuickAndDirty

]
Ich arbeite gerne damit. Allerdings fehlt wirklich sowas wie ein Package-Konzept(dynamisch gelinkte Packages) für FreePascal!
Das erschwert unnötig einen Professionellen Ansatz mit massig zugekaufter Vorleistung.

Das habe ich früher auch mal gedacht, aber qualitativ gute 3rd-Party Libraries (für Excel, Word, pdf, CAD, Geräte-Steuersoftware...)
gibt es doch eher selten als (proprietäres versionsabhähgiges) Delphi-Packages, normalerweise kauft man so ein qualitativ hochwertiges
Ding als DLL. Dafür gibt es dann einen freien Open-Source Pascal-Wrapper und gut.

Hmmmm, so extrem lange dauert solche Neuübersetzung auch wieder nicht, aber es gibt bei fehlerhafter Programmierung den gravierenden Nachteil, das dann die Übersetzung fehl schlägt. Hatte das bei Lazarus 1.0.6. Jetzt hab ich die Version 1.0 installiert, mit derich sehr zufrieden bin. Die 1.2er Version hab ich noch nicht getestet. Werde das nur machen, wenn ich das unabhängig von meiner 1.0 Version machen kann.

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?

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? In den Eigenschaftseditoren gibt es doch auch Methoden wie Get/SetVerb u.a. die könnte man doch veranlassen, passenden Quelltext in den Codeeditor zu schreiben. Dabei sollte es egal sein, ob das von der IDE oder von der geladenen Dll aus passiert. Ich stelle die Frage jetzt mal hier. Bei genügend Interesse am Thema darf das auch in einen separaten Thread ausgelagert werden oder Ihr teilt hier mit, das ich bitte einen separaten Thread dazu auf machen soll. Soll ich?

[QuickAndDirty]

Zitat:

Zitat von schöni (Beitrag 1251975)

Zitat:

Zitat von JamesTKirk

Ja, das fehlt noch. Ich habe letztes Jahr mal damit begonnen, dass umzusetzen, aber überraschenderweise ist besonders die Unterstützung unter Windows recht schwierig (wegen indirekter Auflösung von globalen Variablen, die unterschiedlichen Code für Package/nicht-Package benötigt...)

Zitat:

Zitat von Patito

Zitat:

Zitat von QuickAndDirty

]
Ich arbeite gerne damit. Allerdings fehlt wirklich sowas wie ein Package-Konzept(dynamisch gelinkte Packages) für FreePascal!
Das erschwert unnötig einen Professionellen Ansatz mit massig zugekaufter Vorleistung.

Das habe ich früher auch mal gedacht, aber qualitativ gute 3rd-Party Libraries (für Excel, Word, pdf, CAD, Geräte-Steuersoftware...)
gibt es doch eher selten als (proprietäres versionsabhähgiges) Delphi-Packages, normalerweise kauft man so ein qualitativ hochwertiges
Ding als DLL. Dafür gibt es dann einen freien Open-Source Pascal-Wrapper und gut.

Hmmmm, so extrem lange dauert solche Neuübersetzung auch wieder nicht, aber es gibt bei fehlerhafter Programmierung den gravierenden Nachteil, das dann die Übersetzung fehl schlägt. Hatte das bei Lazarus 1.0.6. Jetzt hab ich die Version 1.0 installiert, mit derich sehr zufrieden bin. Die 1.2er Version hab ich noch nicht getestet. Werde das nur machen, wenn ich das unabhängig von meiner 1.0 Version machen kann.

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?

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? In den Eigenschaftseditoren gibt es doch auch Methoden wie Get/SetVerb u.a. die könnte man doch veranlassen, passenden Quelltext in den Codeeditor zu schreiben. Dabei sollte es egal sein, ob das von der IDE oder von der geladenen Dll aus passiert. Ich stelle die Frage jetzt mal hier. Bei genügend Interesse am Thema darf das auch in einen separaten Thread ausgelagert werden oder Ihr teilt hier mit, das ich bitte einen separaten Thread dazu auf machen soll. Soll ich?

1. Relativiert das nichts, denn wenn ich eine Trial für meine Komponenten ausliefern will geht das nicht! Genau so sieht es aus wenn ich closed source Komponenten verkaufen möchte.

2. Packages sind DLLs nur das sie sich beim Laden in die VMT der Anwendung einfügen. Wenn du das Problem umgehen willst das eine DLL eine eigene VMT hat, kannst du natürlich idealerweise alle Komponten auf Interfaces umstellen, das muss dann auch für alle Bezüge der Kompenenten untereinander gelten. Jedes property, jede Funktion oder Prozedur. Ich fände es aber gut so, vor allem wenn es KEINE Pascall DLLs sind sondern Stdcall DLLS.
Aber wie willst du von einer nur als Interface verfügbaren Komponente erben?

[schöni]

Zitat:

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.

[mjustin]

Zitat:

Zitat von schöni (Beitrag 1252002)

Zitat:

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.

[QuickAndDirty]

Zitat:

Zitat von schöni (Beitrag 1252002)

Hab das aber jetzt nicht getestet.

Wenn man von einem Interface erbt dann erbt man keine Funktionalität!
Nur Implementierungs-Vorschriften.

[michaelthuma]

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:

Zitat von schöni (Beitrag 1252002)

Zitat:

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.

[JamesTKirk]

Zitat:

Zitat von schöni (Beitrag 1251975)

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

Delphi-Quellcode:

csDesigning

in

Delphi-Quellcode:

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.

Zitat:

Zitat von schöni (Beitrag 1251975)

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

Delphi-Quellcode:

TComponent

der IDE nicht das selbe

Delphi-Quellcode:

TComponent

der Bibliothek ist. Das heißt, für eine Komponente, die in der IDE instantiiert wird, aber in einer DLL implementiert ist, wird

Delphi-Quellcode:

is TComponent

innerhalb der IDE nie

Delphi-Quellcode:

true

zurück geben. Auch Exceptions in den Komponenten können dadurch nicht abgefangen werden, da selbst ein

Delphi-Quellcode:

on e: TObject do {...}

fehlschlagen würde, da auch

Delphi-Quellcode:

TObject

in der IDE und

Delphi-Quellcode:

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

Delphi-Quellcode:

TObject

,

Delphi-Quellcode:

Exception

oder

Delphi-Quellcode:

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

[Namenloser]

Zitat:

Zitat von JamesTKirk (Beitrag 1252163)

Ein ganz, ganz wichtiger Denkfehler: Ohne Dynamic Packages gilt, dass

Delphi-Quellcode:

TComponent

der IDE nicht das selbe

Delphi-Quellcode:

TComponent

der Bibliothek ist. Das heißt, für eine Komponente, die in der IDE instantiiert wird, aber in einer DLL implementiert ist, wird

Delphi-Quellcode:

is TComponent

innerhalb der IDE nie

Delphi-Quellcode:

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.

[himitsu]

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.

[Namenloser]

Zitat:

Zitat von himitsu (Beitrag 1252188)

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.

Zitat:

Zitat von himitsu (Beitrag 1252188)

Und es könnte auch andere Packages geben, welche den selben Namen haben.

Das Problem hat man doch so oder so.

[JamesTKirk]

Zitat:

Zitat von Namenloser (Beitrag 1252183)

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.

Zitat:

Zitat von Namenloser (Beitrag 1252183)

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

[AlexII]

Inzwischen haben wir schon Latarus 1.4!

[QuickAndDirty]

Zitat:

Zitat von AlexII (Beitrag 1306382)

Inzwischen haben wir schon Latarus 1.4!

Haben sie Packages?

[Insider2004]

FPC 3.1 und Lazarus 1.4 laufen wie geölt!

[warschonweg]

Lazarus 2.0 ist auch performant und (mit dem Dockingpaket) gut benutzbar. :)