Lazarus 1.2 veröffentlicht

[QuickAndDirty]

Zitat von schöni:

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 von Patito:

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 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 von schöni:

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 von schöni:

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

Zitat von schöni:

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.