guitarvydas11/01/2023, 12:24 PM
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.
guitarvydas11/01/2023, 2:53 PM
that gets populated by
and rendered by the global
handler of the event loop. •
doesn't know anything about
. All it sees is, there's something in
, 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
, etc. And then define the "visual protocol" in
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
, 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".
guitarvydas11/01/2023, 3:14 PM