minimal progress
This commit is contained in:
parent
7799d5f43f
commit
f033295ae8
|
@ -74,13 +74,28 @@ other services, and have an internal state.
|
||||||
|
|
||||||
So in the end your application should look like an acyclic graph of services.
|
So in the end your application should look like an acyclic graph of services.
|
||||||
|
|
||||||
Every service has an init phase, then a living phase, then a stop phase.
|
Every service has an initialization phase, then a living phase, then a stop phase.
|
||||||
Every service declare a set of methods to be used and every service will
|
Every service declare a set of methods to be used and every service will
|
||||||
keep an internal implicit state.
|
keep an internal implicit state.
|
||||||
|
|
||||||
Even if this look a lot like Object oriented programming.
|
Even if this look a lot like Object oriented programming.
|
||||||
It is in fact a quite radical functional programming architecture.
|
It is in fact a quite radical functional programming architecture.
|
||||||
|
|
||||||
|
|
||||||
|
First you declare an /interface/ a bit like in Java. So a lot less powerful
|
||||||
|
than type classes.
|
||||||
|
Really, just a declaration that the symbol ~my-interface~ represents a set of
|
||||||
|
values and functions with some properties (like the number of arguments,
|
||||||
|
the types, etc...)
|
||||||
|
|
||||||
|
Once that is done, you will be able to provide different /instances/ for this /interface/.
|
||||||
|
|
||||||
|
This will be useful to have a production instance and one or many test
|
||||||
|
instances that will be useful to provide reproducible tests.
|
||||||
|
|
||||||
|
Then you declare a service as depending on other services a bit like this
|
||||||
|
(in Clojure syntax):
|
||||||
|
|
||||||
#+begin_src clojure
|
#+begin_src clojure
|
||||||
(def Interface
|
(def Interface
|
||||||
(function-1 [arg-1 arg-2] "a function"))
|
(function-1 [arg-1 arg-2] "a function"))
|
||||||
|
@ -114,5 +129,29 @@ It is in fact a quite radical functional programming architecture.
|
||||||
|
|
||||||
(function-1 [ctx arg-1 arg-2]
|
(function-1 [ctx arg-1 arg-2]
|
||||||
(test/function-1 ctx arg-1 arg-2)))
|
(test/function-1 ctx arg-1 arg-2)))
|
||||||
|
|
||||||
#+end_src
|
#+end_src
|
||||||
|
|
||||||
|
If you were to do that with say, javascript
|
||||||
|
|
||||||
|
|
||||||
|
#+begin_src clojure
|
||||||
|
let myInterface = {"function-1": undefined};
|
||||||
|
let myService =
|
||||||
|
instanciateService (myInterface,
|
||||||
|
[subService1,subService2],
|
||||||
|
function()
|
||||||
|
{return {"init": function(state) {state.subService1 = subService1;
|
||||||
|
state.subService2 = subService2;
|
||||||
|
state.someConfigValue = subService1.getConfig("port")
|
||||||
|
return state;
|
||||||
|
},
|
||||||
|
"function-1": function( arg1 ){ myFunction1( getServiceState(), arg1) }}};
|
||||||
|
#+end_src
|
||||||
|
|
||||||
|
Mainly we need a mechanism to check the returned instanciation really
|
||||||
|
instanciate all the entries. Depending on the programming language, you
|
||||||
|
could go more or less far away, add checks at compile time or runtime.
|
||||||
|
|
||||||
|
We need a mechanism that will initialize an internal state, and a function
|
||||||
|
~getServiceState~ that will be used as first parameter of all real
|
||||||
|
implementation of these functions.
|
||||||
|
|
Loading…
Reference in a new issue