You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Two steps -- sarah.NewRunner() and Runner.Run() -- are required to initialize and execute sarah.Runner with the current implementation, which introduces some potential error-proneness and cumbersomeness.
First, because initialization of Runner and execution is separated, there is a risk that developers may call Run() method multiple times without the care of Runner's state. Sarah's worker solves this problem with a simple approach as below:
Run() does not belong to a Worker instance, but belong to workers package as a global function. When Run() is called, this package initializes a new worker instance, runs this and returns this as a workers.Worker interface. This simplifies initialization process, and furthermore, this prohibits developers from calling execution method of an already running worker. sarah.Runner can also benefit from employing the same approach to lower the potential error-proneness and cumbersomeness.
One more modification is to stash the RunnerOptions in a sarah's package scope variable and refer them on execution. Currently, developers must pass options to sarah.NewRunner() explicitly, so the code before sarah.Runner initialization tends to become relatively longer. The use of sarah.RunnerOptions to stash a group of sarah.RunnerOption helped this, but there still was room to improve:
// RunnerOptions stashes group of RunnerOption for later use with NewRunner().
//
// On typical setup, especially when a process consists of multiple Bots and Commands, each construction step requires more lines of codes.
// Each step ends with creating new RunnerOption instance to be fed to NewRunner(), but as code gets longer it gets harder to keep track of each RunnerOption.
// In that case RunnerOptions becomes a handy helper to temporary stash RunnerOption.
However, this also leads to a new limitation. A single process cannot initialize and run multiple sarah.Runner with different settings because RunnerOptions are going to be stored in a package scope variable and referenced on runner execution. The author thinks this is acceptable because multiple runner executions can simply be achieved by running multiple processes with one runner in each of them.
In exchange for such minor limitation, option registration can be much easier as below:
package main
import (
// Since sarah.CommandProps is directly registered in hello package, this works by simply importing this.
_ "hello"
)
funcmain() {
config:=sarah.NewConfig()
sarah.Run(context.BackGround(), config)
}
The text was updated successfully, but these errors were encountered:
Two steps --
sarah.NewRunner()
andRunner.Run()
-- are required to initialize and executesarah.Runner
with the current implementation, which introduces some potential error-proneness and cumbersomeness.First, because initialization of
Runner
and execution is separated, there is a risk that developers may callRun()
method multiple times without the care ofRunner
's state. Sarah's worker solves this problem with a simple approach as below:go-sarah/workers/worker.go
Lines 95 to 98 in a7408dc
Run()
does not belong to aWorker
instance, but belong toworkers
package as a global function. WhenRun()
is called, this package initializes a new worker instance, runs this and returns this as aworkers.Worker
interface. This simplifies initialization process, and furthermore, this prohibits developers from calling execution method of an already running worker.sarah.Runner
can also benefit from employing the same approach to lower the potential error-proneness and cumbersomeness.One more modification is to stash the
RunnerOption
s in asarah
's package scope variable and refer them on execution. Currently, developers must pass options tosarah.NewRunner()
explicitly, so the code beforesarah.Runner
initialization tends to become relatively longer. The use ofsarah.RunnerOptions
to stash a group ofsarah.RunnerOption
helped this, but there still was room to improve:go-sarah/runner.go
Lines 106 to 140 in a7408dc
However, this also leads to a new limitation. A single process cannot initialize and run multiple
sarah.Runner
with different settings becauseRunnerOption
s are going to be stored in a package scope variable and referenced on runner execution. The author thinks this is acceptable because multiple runner executions can simply be achieved by running multiple processes with one runner in each of them.In exchange for such minor limitation, option registration can be much easier as below:
The text was updated successfully, but these errors were encountered: