Brainstorming Programmiersprache

[antisteo]

Noch immer leuchtet mir in Bezug auf aspektorientierte Programmierung jedoch nicht ein, wieso ich allgemein Code in die Methoden unzähliger Klassen streuen sollte. Instrumentierung und Tracing mal beiseite, wo soll das nützlich sein? Code, der automatisch in jede Methode gestreut werden muss, gehört doch ziemlich sicher überhaupt nicht dorthin, sondern entweder eine Ebene höher oder tiefer?!

In gwScript streut man keinen Code, sondern propagiert nur Bezeichner, die für den Aspekt geeignet sind. Innerhalb der applytemplate-Klammer legt man dann den Code fest, der um den Bezeichner herum gebaut wird. Code injection halte ich selbst für fragwürdig, da man dann die innere Struktur des Zielcodes kennen muss und sich dieser möglichst wenig ändern darf.

Aber eine Frage: wie implementiert ihr die Interface-Pools in C++? Da müsste man ja einen Meta-Header aufbauen, der alle verwendeten Header lädt, die die Definitionen enthalten.

[CodingCat]

Aber eine Frage: wie implementiert ihr die Interface-Pools in C++? Da müsste man ja einen Meta-Header aufbauen, der alle verwendeten Header lädt, die die Definitionen enthalten.

Einfaches Plugin Framework:

Code: Alles auswählen

#include <vector>
#include <algorithm>

// Ja, dass sowas nicht in der STL zu finden ist, ist höchst ärgerlich ;-)
template <class Container, class Value>
inline void container_remove(Container &c, const Value &v)
{
	c.erase(std::remove(c.begin(), c.end(), v), c.end());
}

template <class Plugin>
class PluginCollection
{
	std::vector<Plugin*> plugins;
	
public:
	void add(Plugin *plugin)
	{
		plugins.push_back(plugin);
	}
	void remove(Plugin *plugin)
	{
		container_remove(plugins, plugin);
	}
	Plugin*const* begin() const
	{
		return plugins.data();
	}
	Plugin*const* end() const
	{
		return plugins.data() + plugins.size();
	}
};

template <class Plugin>
PluginCollection<Plugin>& getPlugins()
{
	static PluginCollection<Plugin> c;
	return c;
}

template <class Implementation, class Interface>
struct RegisterPlugin
{
	Implementation impl;

	RegisterPlugin()
	{
		getPlugins<Interface>().add(&impl);
	}
	~RegisterPlugin()
	{
		getPlugins<Interface>().remove(&impl);
	}
};

Beispiel für konkreten Plugin-Typ:

Code: Alles auswählen

class FooPlugin
{
public:
	virtual void foo() = 0;
};

template <class Implementation>
struct RegisterFooPlugin : public RegisterPlugin<Implementation, FooPlugin> { };

Beispiel für die Definition von Plugins:

Code: Alles auswählen

class FooPluginA : public FooPlugin
{
public:
	void foo()
	{
		// Tu was
	}
};
RegisterFooPlugin<FooPluginA> RegisteredFooPluginA;

class FooPluginB : public FooPlugin
{
public:
	void foo()
	{
		// Tu was anderes
	}
};
RegisterFooPlugin<FooPluginB> RegisteredFooPluginB;

Beispiel für Aufruf aller Plugins eines bestimmten Typs:

Code: Alles auswählen

int main()
{
	// Alle FooPlugins anrufen
	for(auto plugin : getPlugins<FooPlugin>())
		plugin->foo();
		
	return 0;
}

[Chromanoid]

In Java geht das übrigens so: http://openbook.galileodesign.de/javain ... 07_003.htm (oder mit einem der dutzenden Frameworks).

[antisteo]

Aber man muss in C++ die registerXYZ-Funktion doch trotzdem noch aufrufen, oder verstehe ich das falsch?
In Java ist klar, da macht man einfach eine Annotation dran und geht dann durch alle geladenen Klassen.

[CodingCat]

Aber man muss in C++ die registerXYZ-Funktion doch trotzdem noch aufrufen, oder verstehe ich das falsch?

Nein, die wird bei Programmstart in obigem Beispiel automatisch durch die dezentrale Instantiierung des RegisterFooPlugin-Klassen-Templates aufgerufen (z.B. RegisterFooPlugin<FooPluginA> RegisteredFooPluginA; im Modul von FooPluginA). Die Deregistrierung läuft durch die automatische Destruktion dieser Instanzen übrigens genauso automatisch und in der richtigen Reihenfolge (umgekehrt zur Instantiierungsreihenfolge bei Programmstart).

RegisterFooPlugin<FooPluginA> RegisteredFooPluginA; entspricht also ziemlich exakt deiner template FooPluginA : FooPlugin-Deklaration.
Das mit dem extra RegisterFooPlugin ist auch nicht unbedingt notwendig, RegisterPlugin<FooPluginA, FooPlugin> RegisteredFooPluginA; wäre vollkommen ausreichend und eventuell sogar schöner. (Es würde auf jeden Fall noch eher deiner template-Syntax entsprechen.)

Mit Makros (was auch nicht schlimmer als ein eigenes Schlüsselwort in der Sprache wäre) käme man sogar zu REGISTER_PLUGIN(FooPluginA, FooPlugin);. Aber das ist wohl ziemlich unnötig.

In Java ist klar, da macht man einfach eine Annotation dran und geht dann durch alle geladenen Klassen.

Na super, über alle geladenen Klassen ... wieder einmal muss man in Java auf dumme Hacks ausweichen. :P

[Chromanoid]

Würde ich in Java nicht so machen. Die Klassen, die es so gibt sind sowieso nur schwer ermittelbar. Und es werden ja nicht einfach so alle Klassen geladen... Wie gesagt dafür gibt es seit Java 6 was aus der Standard-Bibliothek (ServiceLoader). Die Dienste, die man dann so anbietet muss man dann allerdings in eine Datei im META-INF Unterverzeichnis der Jar auflisten...