The problem of initialization

[danidiaz]

Inspired by this comment in the Haskell Discourse.

It feels natural that a "constructor" could have effects, performing some initialization on the component, initialization which might use functionality from the component's dependencies. Think the PostConstruct annotation in Java.

In dep-t, one style of initializers is supported, but there are some catches:

• Dependencies between initializers ("the repository should only be initialized after the logger has been initialized") are not automatic. They could be deduced from the dependency graph, but "reifying" the dependency graph from the Has-style typeclasses seems difficult.
• Components may briefly exist in an "unitialized" state, because you would basically get a (Initializer m, SomeComponent m) pair, not something like Initializer (m (SomeComponent m)).

Possible solutions:

• Bite the bullet and write some Initializer monoid that can be tagged with dependencies and/or priorities, and performs an automatic topological sort (?).
• Always rely on "lazy initialization" of resources. Initialize the component when first accessed.

[danidiaz]

Spring bean creation lifecycle : Why having multiple interaction points?

BeanFactoryPostProcessor and PriorityOrdered.

BeanFactoryPostProcessor beans that are autodetected in an ApplicationContext will be ordered according to PriorityOrdered and Ordered semantics. In contrast, BeanFactoryPostProcessor beans that are registered programmatically with a ConfigurableApplicationContext will be applied in the order of registration; any ordering semantics expressed through implementing the PriorityOrdered or Ordered interface will be ignored for programmatically registered post-processors. Furthermore, the @Order annotation is not taken into account for BeanFactoryPostProcessor beans.

[danidiaz]

See also

• Execution Order of @PostConstruct.

• Spring autowiring order and @PostConstruct

• Executing Code on Spring Boot Application Startup

  The @PostConstruct method is called right after the bean has been created by Spring, so we cannot order it freely with the @Order annotation, as it may depend on other Spring beans that are @Autowired into our bean.

[danidiaz]

Moving to a more registry way of doing things, with constructors that use positional parameters instead of Has, would make functions like lmapConstructor (useful to install named loggers) more difficult to implement.

I also kinda dislike positional parameters for dependencies and would prefer to keep using Has.