3 ms·
I was initially very skeptical at first too. Then I noticed that the positioning of the "Busy = false" statements had been reduced to a structured form exactly
by marshray 13y ago
I was initially very skeptical at first too. Then I noticed that the positioning of the "Busy = false" statements had been reduced to a structured form exactly as if we had started with an unstructured GOTO or multiple exit point control flow.
As a C++ guy, I don't like his "Busy = false" system to begin with. It would seem much better (to me) if he used a non-copyable object to represent the outstanding activity. Such an object could naturally reset the "Busy" flag in its destructor. But usually there's a better scheme than using a simple Boolean flag to represent a "busy" state anyway. (How is clearing the flag going to release the next guy waiting for the resource?)
So while I'm still a bit skeptical of drawing conclusions from this, I readily admit it's not so off-the-wall as I'd originally thought.
- danabramov 13y agoI'm sure Busy isn't meant to represent state—it's a property whose setter and getter call a spinning wheel UI element's StartAnimating and StopAnimating. It's a very common practice in iOS view controllers. That's what I read anyway.
- marshray 13y agoThat sounds like state to me.
- danabramov 13y agoDo you have any other method of updating the UI without calling corresponding methods? I'm lost on your argument.
- marshray 13y agoWell if the goal is to have a "spinning wheel UI element" to reflect to the user that the app is in a "busy" state, and the UI element requires calls to modify its animation state, then no I don't have a way to do it without calls to the UI element.