[Explanation] State In & Out, Pads, Execution Order, Classes & Records

[gregsn]

Let me write this down as it is not always intuitive.

One of the first language design decisions was that we want to make it easy to define immutable data types. And we wanted to make sure that switching between immutable and mutable datatype definitions would be very easy.

In order to make that work we focused on the constraints that are inherent to the immutable data type definition:

• A record operation has to be able to return a new snapshot of the object (a new instance of the datatype) since the incoming state shall not be changed.
• Another way of saying the same is this: All instance operations on records end with an implicit Join operation.
• So the idea was that any operation on a record under the hood roughly works like this:
  • Split the incoming State entering via the State Input pin of the node application and feed that information to the pads on definition side
  • Do everything else expressed by the user
  • Take the pads that have been written to, Join that information into a new instance and let that one flow out of the State Output pin of the node application. (if not changed: use old state)

This is quite different from what you know of imperative languages like C# where you can write into a field whenever you like.

We didn't want different ways of expression. As a result Records and Classes both come with the idea that per operation a field can only be written once. And for now, classes only differ in one regard:

• When leaving the operation: instead of potentially creating a new snapshot, the incoming instance gets modified. So: after all operations in the patch have been executed.

[gregsn]

This has changed a bit: you now CAN write fields on the fly. See #19

Closing as it is OUTDATED