Replies: 6 comments
-
Mark interfaces as pure/unpureProblem - interface can have many implementationsE.g. mocking network requests in tests |
Beta Was this translation helpful? Give feedback.
-
Mark all components with DI as inpureProblem - such component can be actually pure |
Beta Was this translation helpful? Give feedback.
-
Make pureness a property of node, not a componentNode is an instance of a component (BTW shouldn't we use term "instance" instead?) so it's possible for compiler to infer whether node is pure or not - a node is pure if
Problem 1. How to use it? |
Beta Was this translation helpful? Give feedback.
-
Ask chatGPTEspeccialy about #228 (comment) and how is this works in languages with explicit purity (like Haskell?) and what are examples of such languages |
Beta Was this translation helpful? Give feedback.
-
DirectivesCould be implemented via compiler directives #354 |
Beta Was this translation helpful? Give feedback.
-
Purity rules. Interfaces are always "pure"
This approach could help e.g. separate business logic from adapters. Business logic could be pure and completely depend on interfaces which is good for testing. Examples: |
Beta Was this translation helpful? Give feedback.
-
Is it a good idea to mark runtime functions as "pure" and "non-pure" so any component that uses them is also pure/unpure so we can somehow separate side-effects from the rest of the program? Do we have to use something like IO monad (whatever that is)?
Problems
Interface nodes
If component uses DI (has abstract nodes) then it's not clear will it be pure or not
Beta Was this translation helpful? Give feedback.
All reactions