Ja, der Overhead für Input Ports ist vernachlässigbar, bei Output Ports aber durchaus relevant.
Input Ports sind vor allem aus einem Grund ins Design rein gekommen --
wegen der Symmetrie. Wenn man OutputPorts deklarativ hinschreiben kann,
gehören da irgendwie auch InputPorts deklarativ spezifiziert. Vielleicht
bin ich da nicht pragmatisch genug - die Symmetrie drängt sich hier
geradezu auf, deswegen habe ich sie für ein "schönes Design" (im
allgemeinsten Sinne) mit rein genommen. Aber wer pragmatischer ist, kann
das ja auch weglassen. Es funktioniert im jetzigen Zustand der
Bibliothek auch ohne.
Generell muss festgehalten werden, dass EBC für C# ja mehr ein Schema
ist Code zu organisieren, wenn auch ein geniales :-). Dieses Schema
stützt sich vor allem auf das C#-Sprachkonstrukt der Events und kommt
damit ohne Infrastrukturlogik aus. Alles was notwendig ist, bringt C#
mit. Aufgrund der fehlenden Events ist in Scala jedoch eine Bibliothek
notwendig, um Flow-Design-Anwender zu ersparen, immer wiederkehrenden
Infrastruktur-Code implementieren zu müssen. Da Scala eh darauf
ausgelegt ist, über internen DSLs, erweiterbar zu sein, warum nicht noch
weitergehen, als nur den Event-Mechanismus nachzuempfinden, und eine
Flow-Design-DSL in der Bibliothek anlegen?
Im nächsten Artikel wird erst mal diese eingeführt bzw. die partiell vorhandene "verschönert".
Ich habe den Gedanke auch noch nicht aufgegeben Scalas Actors-Konzept zu
integrieren, und da könnten dann die InputPorts interessant werden, um
dort Actor-basierte Infrastruktur-Logik unterzubringen, mal sehen.