Skip to content

Latest commit

 

History

History
107 lines (53 loc) · 2.74 KB

thoughts.md

File metadata and controls

107 lines (53 loc) · 2.74 KB
Raw

74e58d0db7f2b7cfa7b7e0a9e47281a75b971e3a - deletes Monitor.purs da4b9ce59aa52343796327a12e87231d06b8bed0 - deletes Timer.purs

Why is Process.runProcess called runProcess? it doesn't have any side effect, it just extracts a Pid.

Why is the constructor for the Process newtype directly public?? surely we should have an unsafeProcessFromPid function or something?

GenStatem should return GenStatemProcess (GenStatemType info internal timerName timerContent commonData stateId state)

where GenStatemType is a newtype of Void GenStatemProcess is a newtype of Process info

GenStatemProcess exposes HasRawPid (getRawPid) HasProcess (getProcess) (not sure if this should be an unwrap?)

StartLinkResult success should be not ServerPid serverType but serverProcess, ServerPid should be removed.

Sup should constrain serverProcess to a HasRawPid type class so that it can get the pid to monitor - the same for StartChild

data InstanceRef serverType
  = ByName (RegistryName serverType)
    ByPid (ServerPid serverType)

becomes

data InstanceRef serverType serverProcess
  = ByName (RegistryName serverType)
  | ByProcess (ServerProcess serverType)

Now the Statem/Server has complete control over its own Pid and can surface what it likes with it, because it can just newtype of the core Statem/Server type - for a Sup, it merely needs to support HasRawPid which can be generated using newtype deriving

Timers operate over (HasProcess)

Monitors operate over (HasRawPid)

Why?

Because the statem/server needs to provide facilities to take its "pid" and do useful things with it (e.g. for timers), and those APIs are callable by anyone, so whatever pid the statem/server provides should not be returned directly by the statem/server implementation to API consumers, they should return their own thing so that they can control what an API consumer can do with it.

For example, just because a server/statem implementation is using info, it doesn't mean that they want an API consumer to be able to send those info messages to the server/statem.

Process mapping? spawn a small process that receives messages, transforms them, and forwards them?

Should GenStatem/GenServer expose their own monitor functions?

Consistency

  • ServerSpec vs Spec (for Statem) - it's unlikely folks would be using both in a single module, so the short names are better?

Unfinished

  • Terminate handling
  • Monitor handling should be the same I think

newtype Blah = Blah Void

newtype FooPid statemType = FooPid Void

class HasInfoType statemType infoType | statemType -> infoType

f :: forall statemType infoType. HasInfoType statemType infoType => FooPid statemType -> infoType -> Effect Unit

f statemPid info = pure unit