Callbacks as our Generation's Goto Statement

Post by Niten » Fri, Aug 16, 2013, 7:09 AM UTC

pjmlp wrote: post #178

dantle wrote: post #141

(C/OS developer spiel) I'm sick of these app developers assuming that using "goto" is bad practice. The fact is that "goto" is used plenty in great production code you're probably running right now.[1] I'd like to know a cleaner way to abort a function into its cleanup phase when a function call returns an error. And "goto" statements are extremely simple to handle for even the most naive of compilers. [1] https://ww…

Exceptions

Post by lazugod » Fri, Aug 16, 2013, 7:30 AM UTC

manojlds wrote: post #163

cscheid wrote: post #137

Earlier quoted context omitted.

(for whatever's worth, I'm Brazilian)

Aren't you still American? ;) As an Indian I am confused why only people of the US are called Amerians while two entire continents are called America. And also, why we Indians are not considered Asians by the said Americans.

Post by MichaelMoser123 » Fri, Aug 16, 2013, 7:41 AM UTC

MichaelMoser123 wrote: post #154

danabramov wrote: post #8

There is some creative use of C# async/await in this blogpost: http://praeclarum.org/post/45277337108/await-in-the-land-of-... Basically, the author implements a “first time walkthrough” kind of interface a-la iWork very declaratively by using async: async Task ShowTheUserHowToSearch () { await Tutorial.EnterText (searchField, minLength: 3); await Tutorial.Tap (searchButton); await Tutorial.Congratulate ("Now you kno…

What if you have two buttons, search and 'be lucky'? I guess you will have to await for a controller object that wakes up that if either one of the buttons is triggered, and then test what button was pressed. Now what if you have add a search option dialog that can be invoked at any moment? I guess when the 'apply' button of the option dialog got pressed then this is still going to be a callback that sets global vari…

Post by masklinn » Fri, Aug 16, 2013, 7:43 AM UTC

ufo wrote: post #164

shadowmint wrote: post #114

I'm not buying the c# async/await kool-aid. Async, sure, I'm down with that, but I've used the c# async stuff now, and while it makes it the app somewhat faster, it has three major downsides (that I encountered): - Infects everything; suddenly your whole application has to be async. - Debugging becomes a massive headache, because you end up in weird situations where the request has completed before some async operati…

But doing things by hand with callbacks is going to have all of those same issues isnt it? If you dont want to infect everything then you basically need to just write synchronous code instead...

Post by raycmorgan » Fri, Aug 16, 2013, 7:49 AM UTC

danabramov wrote: post #54

ryan-allen wrote: post #37

I don't understand what the big deal is. Callbacks are OK. They're less cumbersome if the language you're using has smaller function definitions. Callbacks 'get crazy' when you've got more than one I think, and thankfully someone smart has made a library you can use to manage them! https://github.com/caolan/async Saying that, I don't mind the way things look with the whole await/async stuff in C# and etc. However I d…

How do you do this with callbacks? foreach (var player in players) { while (true) { var name = await Ask("What's your name"); if (IsValidName(name)) { player.name = name; break; } } } Assuming `Ask` is an asynchronous operation and must not block the UI thread. Note that second player is only asked after the first player has given a valid name. (And the code structure reflects that :-) My point is of course it's doab…

  async.eachSeries(players, askName, function (err) {});

  // this is someplace it should go
  function askName(player, callback) {
    Ask("What's your name", function (err, name) {
      if (err) { return callback(err); }
  
      if (IsValidName(name)) {
        player.name = name;
        callback(null);
      } else {
        askName(player, callback);
      }
    });
  }