behaviors could... replace ...
setup(){} with start(o){o.active=false}step(){}with update(o){o._scale=[1,2,3]}
Helps THREE.js and Unity coders.
A strong case could be made instead for handlers to prefix with on:
onUpdate()onStart()
and new convenient friends...
onClick(o, inp){ if(inp.isLeft){o.scaleBy([.1,1,1])}; if(inp,isDoubleClick){ }; if(inp.keyDown.Ctrl){ } },
onHover(o, inp){ if(inp.justEntered){ }; if(inp.justExited){ } }
My hypocrisy (keep the old AND out with the old!) knows few bounds in cases where the old way is onerous as with Unity mousing.
Note: Unreal uses BeginPlay() and Tick()
Prior art Unity: MonoBehaviourStart() (in the UI, On Start)
Update() (in the UI, On Update)
FixedUpdate()LateUpdate()OnDisable()OnEnable()OnTriggerEnter()OnDestroy()
Note: first param = this of class i.e. onStart(o){o._active = false}
Such lays groundwork for functional composition patterns.
In an effort to adopt more contributors...
behaviors could... replace ...
setup(){}
withstart(o){o.active=false}
step(){}
withupdate(o){o._scale=[1,2,3]}
Helps THREE.js and Unity coders.
A strong case could be made instead for handlers to prefix with
on
:onUpdate()
onStart()
and new convenient friends...
onClick(o, inp){ if(inp.isLeft){o.scaleBy([.1,1,1])}; if(inp,isDoubleClick){ }; if(inp.keyDown.Ctrl){ } }
,onHover(o, inp){ if(inp.justEntered){ }; if(inp.justExited){ } }
My hypocrisy (keep the old AND out with the old!) knows few bounds in cases where the old way is onerous as with Unity mousing.Note: Unreal uses BeginPlay() and Tick()
Prior art Unity: MonoBehaviour
Start()
(in the UI,On Start
)Update()
(in the UI,On Update
)FixedUpdate()
LateUpdate()
OnDisable()
OnEnable()
OnTriggerEnter()
OnDestroy()
Note: first param = this of class i.e.
onStart(o){o._active = false}
Such lays groundwork for functional composition patterns.