Lazarus 1.2 veröffentlicht

[Namenloser]

Zitat von JamesTKirk:

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.

[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 von himitsu:

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

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

Das Problem hat man doch so oder so.

[JamesTKirk]

Zitat von Namenloser:

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

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

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.