Kartik Agaram
guitarvydas
11/01/2023, 12:24 PMKartik Agaram
sum
from the example over 10 numbers. I now have to adjust where I render the results of each call. Which is overhead when debugging a problem.
This mirrors the classic problem with globals: functions that use them are no longer reentrant. Locals are robust to arbitrary (scales of) calling patterns.
I'm really curious to hear if you have any solutions here.guitarvydas
11/01/2023, 2:53 PMKartik Agaram
Result
that gets populated by sum
and rendered by the global draw
handler of the event loop.
• draw
doesn't know anything about sum
. All it sees is, there's something in Result
, and it draws it at a certain point on screen.
• I don't show this in the video, but my hazy plan for larger computations is to add deeper subcomputations into new variables, say Result_local1
, Result_local2
, etc. And then define the "visual protocol" in draw
to say where and how (bar graph, point coordinate, etc.) to render each of them.
• But now consider if I want to start rendering n points on screen. I might want the intermediate results in different locations depending on whether I'm computing one or a hundred.
Hmm, as I write this out I realize perhaps this isn't an issue with the globals. Any time I reorganize my computation I'm going to have to tweak my visual protocol. If a caller wants to juggle 10 invocations of sum
, it's the caller's job to save the results to some other new global, with its own visual protocol.
Ok, I can live with this! It's a lot like having a database of globals in a web app. It's a minor transform to go from lots of little globals scattered everywhere to a single global table called "intermediate results within subsystem foo".guitarvydas
11/01/2023, 3:14 PM