Flow-Design in Scala

[Denis]

Oh, der letzte Beitrag ist schon echt lange her...
Zeit mal für was Neues: Flow-Design in Scala!

Wer Interesse hat, dem sei der Artikel http://blog.grammarcraft.de/2013/04/26/treppengeplatscher auf meinem Blog empfohlen.

Schönes WE!

Denis

[Denis]

Der nächste Artikel zeigt, wie FD-Funktionseinheiten in Scala zusammengesteckt werden können: http://blog.grammarcraft.de/2013/04/29/steckspiele-flow-design-funktionseinheiten-in-scala-verbinden/.
Denis

[Denis]

... mal was ganz Neues im Zusammenhang mit Flow-Design: Dank des Sprachkonzepts "Trait" lassen sich in Scala die Ein- und Ausgangsports nahezu deklarativ spezifizieren.  Damit kann sich der Programmierer ganz auf die Implementierung der Funktion konzentrieren und die Funktionseinheit wird kompakter und damit auch besser lesbar und zu verstehen. Hier der Artikel wie das in Scala geht: http://blog.grammarcraft.de/2013/05/10/ein-spezieller-charakterzug-traits-fur-flow-design-in-scala/

[Ralf Westphal]

Hm... so ganz überzeugt bin ich noch nicht, dass Traits EBC einfacher machen.

Wo ist der große Overhead zumindest für Input Ports, wenn man einfach nur die Methoden hinschreibt?

Da Scala keine Events wie C# hat, macht der Trait aber zumindest die Output Ports wohl simpler.

--
Sie haben diese Nachricht erhalten, weil Sie der Google Groups-Gruppe Event based Components beigetreten sind.
Um Ihr Abonnement für diese Gruppe zu beenden und keine E-Mails mehr von dieser Gruppe zu erhalten, senden Sie eine Email an event-based-compo...@googlegroups.com.
Weitere Optionen: https://groups.google.com/groups/opt_out
 
 

--

Mein neues Kindle eBook:

 

Clean Code Trainings

Ralf Westphal - One Man Think Tank
Hans-Henny-Jahnn-Weg 44
D-22085 Hamburg
Germany
Tel 0170-3200458
Email in...@ralfw.de

[Denis]

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.

[Denis]

... Hat etwas gedauert, aber jetzt geht es weiter: die interne DSL wird ausgebaut. Wer Interesse hat liest hier: http://blog.grammarcraft.de/2013/06/26/syntactic-sugar-und-gut-umruhren/.
Denis

[Ralf Westphal]

das sieht cool aus! zumindest für EBC.

wäre auch etwas möglich für die verkettung von funktionen?

komposition bzw. "pipes"?

--
Sie haben diese Nachricht erhalten, weil Sie der Google Groups-Gruppe Event based Components beigetreten sind.
Um Ihr Abonnement für diese Gruppe zu beenden und keine E-Mails mehr von dieser Gruppe zu erhalten, senden Sie eine Email an event-based-compo...@googlegroups.com.
Weitere Optionen: https://groups.google.com/groups/opt_out
 
 

[Denis]

Kann ich nicht aus der holen Hand beurteilen. Müsste ich mal ausprobieren.
Eigentlich ist ja

fu1 -> fu2

in Scala nichts anderes als

fu1.->(fu2)

wobei "->" eine Methode ist.
Theoretisch würde ja

fu1.->(fu2).->(fu3)

auch gehen.
Aber ob die Grammatik der Sprache Scala auch

fu1 -> fu2 -> fu3

erlauben würde, übersehe ich eben nicht.

Anderseits ist die jetzige Implementierung für mich ja nur ein Vehikel, eine Flow-Runtime in Scala zu implementieren, um das Konzept dann auch in Java benutzen zu können - Scala läßt sich nicht so einfach mal in eine Organisation einführen, eine "Bibliothek" schon.
Deswegen wollte ich mich darauf konzentrieren EBC "nachzuempfinden". Die interne DSL war nur ein kleines "Abfallprodukt" der Beschäftigung mit den Konzepten von Scala.

Vorher kommen aber noch zwei Artikel, die das jetzige Konzept und seine Implementierung verfeinern - einmal, wie man Boards realsiert, also Funktionseinheiten, deren einzige Funktion ist zu integrieren; zweitens wird die interne DSL um Konstrukte zur Fehlerbehandlung erweitert.

Ausserdem arbeite gerade noch an einer (konstruktiven) Kritik des EBC-Konzeptes, die ein Problem beleuchtet,welches sich auch in der jetzigen Scala-Flow-Design-Implementierung wiederfindet. Es scheint aber nicht in der Flow-Runtime zu existieren und auch für die Scala-Flow-Design-Implementierung scheint es eine Lösung dafür zu geben...

Denis

Um Ihr Abonnement für diese Gruppe zu beenden und keine E-Mails mehr von dieser Gruppe zu erhalten, senden Sie eine Email an event-based-components+unsub...@googlegroups.com.
Weitere Optionen: https://groups.google.com/groups/opt_out
 
 

[Denis]

So, die Sommer-Ferien sind vorbei, zumindest in Berlin. ;-)
Mit dem Flow-Design in Scala geht's jetzt weiter: Diesmal geht es um Boards, Abstraktionsebenen und dem Wechsel zwischen selbigen: http://blog.grammarcraft.de/2013/08/22/auf-den-standpunkt-kommt-es-an-abstraktionsebenen-im-flow-design.
Denis

[Denis]

Der nächste Artikel rundet die Serie zum Flow-Design in Scala ab und beschreibt wie man Fehlerbehandlung realisiert: http://blog.grammarcraft.de/2013/09/20/mit-den-fehlern-leben-fehlerbehandlung-in-scala-flow-design/

Demnächst wird es darum gehen, welche Grenzen diese aktuelle Realisierung von Flow-Design in Scala hat. In der Diskussion zu Ralfs letztem Blog-Artikel wurde das Problem der rekursiven Continuations bereits angerissen -- zirkuläre Flows lassen sich unter Umständen nicht realisieren.
Aber: Das stellt das Konzept des Flow-Designs nicht in Frage! Es ist nur eine Beschränkung durch die jeweilige Implementierung (EBC hat sie auch, NPantaRhei eher nicht). Und ich denke, dass sich das Problem auch für Flow-Design in Scala lösen läßt - wir werden sehen.

Denis

[Ralf Westphal]

toll, dass du dran bleibst am thema!

im seminar neulich waren c#, python und java entwickler. die java-jungs hatten es am schwersten mit EBC/flow-design.

erst mit java 8 wird das wohl besser, weil dann lambdas kommen.

aber scala ist schon jetzt auf einem guten weg. sehr schön.

--
Sie erhalten diese Nachricht, weil Sie Mitglied der Google Groups-Gruppe "Event based Components" sind.

Um Ihr Abonnement für diese Gruppe zu beenden und keine E-Mails mehr von dieser Gruppe zu erhalten, senden Sie eine Email an event-based-compo...@googlegroups.com.
Weitere Optionen: https://groups.google.com/groups/opt_out

--

[Denis]

Ja, in Java ergibt sich sehr viel "Rauschen", wenn man das Event-Konzept von C# mittels Listeners nachempfindet.
Ich habe gerade eine Umsetzung einer alten AppSpace-basierten (erinnerst Du Dich da noch dran ;-) C#-Implementierung in Java gemacht -- man muss schon einige mentale Kopfstände machen, um da nicht durcheinander zu kommen, aber es geht. Man muss nur sehr diszipliniert vorgehen und es schematisch umsetzen.
Das Lambda-Kalkül fehlt hier Java sehr.
Denis

Um Ihr Abonnement für diese Gruppe zu beenden und keine E-Mails mehr von dieser Gruppe zu erhalten, senden Sie eine Email an event-based-components+unsub...@googlegroups.com.
Weitere Optionen: https://groups.google.com/groups/opt_out

[Denis]

Ich habe das jetzt noch mal ausprobiert: Mit der jetzigen Implementierung funktioniert diese Notation nicht, da einerseits der Operator "->" auf zweierlei Art implementiert ist, um die .flow-ähnliche DSL hinzubekommen; anderseits funkt noch eine implizite Scala-Konvertierung rein, die auch diese Operator-Ausprägung benutzt.
Man müsste mal einen anderen Operator probieren...
Denis