Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Implement async API's as generators instead of using callbacks #87

Closed
tyilo opened this issue Jul 1, 2015 · 6 comments
Closed

Implement async API's as generators instead of using callbacks #87

tyilo opened this issue Jul 1, 2015 · 6 comments

Comments

@tyilo
Copy link
Contributor

tyilo commented Jul 1, 2015

Basically like the *Sync API's, but using generators instead, so we don't have to loop through every match if we want to stop early. This will also means that we could get rid of all the *Sync API's.

If we some of the async functions actually runs async*, we may want to use Promises as they are really nice instead of the current needed callback hell.

* So that the output of the following code is 1 3 2:

console.log('1');
FooBar.enumerateFoos({
    onMatch: (foo) => console.log('2'),
    onComplete: () => {}
});
console.log('3');

Before:

var result = null;
Process.enumerateRanges('r--', {
    onMatch: (base, size, protection, file) => {
        Memory.scanRange(base, size, '66 72 69 64 61 20 72 6f 63 6b 73 21', {
            onMatch: function(address, size) {
                result = size;
                return 'stop';
            },
            onError: () => {},
            onComplete: () => {}
        });
        if(result) {
            return 'stop';
        }
    },
    onComplete: () => {}
});
console.log('Found string at address:', result);

After:

var result = null;
loopy: for(var range of Process.enumerateRanges('r--')) {
    for(var match of Memory.scanRange(range.base, range.size, '66 72 69 64 61 20 72 6f 63 6b 73 21')) {
        result = match.address;
        break loopy;
    }
}
console.log('Found string at address:', result);
@oleavr
Copy link
Member

oleavr commented Jul 1, 2015

Yes! ❤️

@tyilo
Copy link
Contributor Author

tyilo commented Jul 1, 2015

Hmm, how would we handle onError?

@oleavr
Copy link
Member

oleavr commented Jul 1, 2015

An exception would be thrown for that case.

@marc1006
Copy link

+1 :)

@ChiChou
Copy link
Contributor

ChiChou commented Feb 24, 2016

👍

@oleavr
Copy link
Member

oleavr commented Jan 19, 2017

Haven't had the bandwidth to focus on this. Let's re-evaluate this down the road.

@oleavr oleavr closed this as completed Jan 19, 2017
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

4 participants