assets/developer-notes/stephanie-gawroriski/2017/02/02.mkd

   1 # 2017/02/02
   2
   3 ## 11:47
   4
   5 Maybe for the configuration, I will have a node of sorts that supplies
   6 options. Basically, there is an interface which exposes options that can be
   7 used.
   8
   9 ## 11:50
  10
  11 Then these nodes would have serialization as such. Then for deserialization
  12 the nodes can refer to a class which can deserialize by just creating a new
  13 instance and passing it through. This is the only way within the current
  14 limitatons to have a more dynamic configuration system with a static base.
  15 The nodes can be layered also with their own configuration set. The only
  16 issue I need to think of is obtaining options. I would have to have a get node
  17 for the options. However, the base settings would always be in the
  18 configuration. So the node would have a `get(String __key, String __val)`
  19 which can parse the value to return the correct value.
  20
  21 ## 11:55
  22
  23 To prevent magic from happening, it would just initialize the values on
  24 construction time.
  25
  26 ## 11:56
  27
  28 That however, would complicate usage of the JIT configuration class though.
  29
  30 ## 11:57
  31
  32 So how about just get rid of configurations then, at least the base class and
  33 stick with the nodes. There would still be the serializer and such.
  34
  35 ## 12:18
  36
  37 The translation engine should provide the configuration rather than passing it
  38 to the JIT.