Comments (18)
Here's an idea how to solve the different parameters:
// Assuming cb is Error -> String -> Void
var err, result = @async(err, null => cb) some.method()
I've done some testing, it was quite simple to implement, about 20 lines in util/Async.hx
(including useful error messages).
from haxe-js-kit.
Honestly, this @async
stuff is all about making the syntax easier, KISS-er, while keeping the macro basic. So I don't really like either of your proposals as-is.
OTOH, I would also like to see an elegant solution for error handling.
Also, I don't see any situation where cb
shouldn't be Error -> String -> Void
in the first place.
In this case, it's easy to skip the if
and just cb( err, result )
.
Then I think it would be nice to be able to @async cb( err, result ) = some.method();
?
ITOH, maybe the following would be nice too, maybe closer to your first idea :
var cb( err ), result = @async some.method();
or
@async cb( err ), result = some.method();
Random / possibly irrelevant idea :
@async switch Soap.createClient('...') {
case [null, result]: // do something with result
case [err,_]: // handle error
}
I don't like it that much, though, because it adds indentation,
but I like the FP style of it.
Let's discuss :p
from haxe-js-kit.
About the second idea, how about:
@async switch Soap.createClient('...') {
case @success( a , b ): // do something with a and b, given the callback has extra values
case @success( a, b ) if a == "whatever": // guards
case @error( err ): // handle error
case @error( { code : 404, message : message } ): // pattern matching
}
I also don't want to go too far into something too complex,
because I'm pretty sure Juraj's tink_* has something similar, while much more solid and flexible...
from haxe-js-kit.
About the current syntax, and given all this :
I'd actually love to drop the var
.
from haxe-js-kit.
misclicked
from haxe-js-kit.
I this idea, it's nicer than the one I suggested:
var cb( err ), result = @async some.method();
// And for callbacks with multiple parameters
var cb(err, null), result = @async some.method();
Dropping var is fine for me, but I don't think it makes things that much worse, since it's consistent with normal variable declaration.
If you think the syntax is ok, I'll start working on it and will make a PR.
from haxe-js-kit.
Unfortunately that is invalid syntax. :(
from haxe-js-kit.
Oh, the idea was great, So that's a no-no? :/
from haxe-js-kit.
We can probably figure something out ;)
from haxe-js-kit.
Ok, here's another take: Leaving KISS aside for a moment, I think semantics is also a quite important part of expressing yourself in code. So what would an uninitialized reader think about this:
var error = @async(error => callback) some.method();
Maybe: "An asynchronous call, errors goes to callback"
Compared to:
var callback(error) = @async some.method();
This looks more like a method call before the async call?
What would your interpretation be of these? Unbiased, I expect. ;)
Also: @async(error => callback) some.method()
(without var) looks very good, but takes more work.
from haxe-js-kit.
I've been reading the whole thread again, and you're right it's all very confusing.
Back to your first proposal, I think it's already very misleading / error prone, mainly because it's not clear at all that there is a possible return
/ break: most of the time, with @async
you expect the rest of your code to eventually run anyway.
It feels like some kind of hidden try/catch
block...
Also, your proposal somehow assumes the first callback arguments is an error.
But @async
can be used in many other situations, in theory :
{
var req, res = @:async express.get("stuff/:id");
res.end("Hello");
}
(Not really using it like this myself, not sure it even works like it should, but still...)
Also, the more I think about, the more I think having only an error in your callback is an anti-pattern.
I've never used it myself, and pretty much fail to see the benefit.
... except if you want to use promises ;)
So IMHO, the ultimate solution to your problem is in promises, really :p
That's why switch
constructs popped to me at first.
How about that ?
var result = switch @async some.method() {
case [null, result] : result;
case [err, _] : return callback( err ); null;
}
In any case, I think your problem goes far beyond what @async
is about,
and you should look into more complete FP-style solutions.
from haxe-js-kit.
True, it's based on the most frequent use case I have: If something goes wrong, pass it on and exit. It's not a general-purpose solution.
from haxe-js-kit.
PS:
With promisify
, we could :
using Promisify;
var result = @async some.method.promisify()("arg1","arg2").catch( callback ).then();
Not even sure it works in the current @async
implementation, but it should...
from haxe-js-kit.
What happened to KISS? :)
from haxe-js-kit.
Haha simple != concise :p
from haxe-js-kit.
Also true, but that code is rather an example of redundancy than conciseness. And with promises, it even turns into verbosity... I remember this discussion: https://groups.google.com/d/msg/haxelang/OiKbnxX4Wtk/Lh4PS2mSv84J
from haxe-js-kit.
I don't like promises either;
You are the one who brought me to promises with your error callback ;)
from haxe-js-kit.
No I don't want to catch anything really, in this case I want a return value, and a way of handling it in the Node callback style: http://fredkschott.com/post/2014/03/understanding-error-first-callbacks-in-node-js/
from haxe-js-kit.
Related Issues (20)
- Branding/Marketing website HOT 35
- Can I use webpack (or something similar) with these externs? HOT 2
- express route and simple chat with socket.io please HOT 5
- SocketIO clientside error "Uncaught ReferenceError: process is not defined" HOT 9
- Dependency on `hxnodejs` is causing issues with socket.io in browser HOT 9
- Using Map<String,Int> with Mongoose HOT 2
- Running multiple mongo db calls in a for loop HOT 3
- [Express] res.sendfile() is now res.sendFile() HOT 3
- update with $pull HOT 7
- Generate ObjectID before create HOT 4
- SubDocument with nested schema HOT 11
- is haxelib branch still updated? HOT 5
- Mongoose plugin usage HOT 1
- Mongoose arrayFilters in ModelUpdateOptions HOT 1
- Request object not unifying with IncomingMessage HOT 4
- Warning : Extern non-inline function may not have an expression HOT 14
- Uncaught exception "unsupported" from util/CopyMethods HOT 4
- haxe 4 mongoose issue HOT 4
- Mongoose : "Variable requires type-hint or initialization" using schemaOptions HOT 2
Recommend Projects
-
React
A declarative, efficient, and flexible JavaScript library for building user interfaces.
-
Vue.js
🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
-
Typescript
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
-
TensorFlow
An Open Source Machine Learning Framework for Everyone
-
Django
The Web framework for perfectionists with deadlines.
-
Laravel
A PHP framework for web artisans
-
D3
Bring data to life with SVG, Canvas and HTML. 📊📈🎉
-
Recommend Topics
-
javascript
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
-
web
Some thing interesting about web. New door for the world.
-
server
A server is a program made to process requests and deliver data to clients.
-
Machine learning
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
-
Visualization
Some thing interesting about visualization, use data art
-
Game
Some thing interesting about game, make everyone happy.
Recommend Org
-
Facebook
We are working to build community through open source technology. NB: members must have two-factor auth.
-
Microsoft
Open source projects and samples from Microsoft.
-
Google
Google ❤️ Open Source for everyone.
-
Alibaba
Alibaba Open Source for everyone
-
D3
Data-Driven Documents codes.
-
Tencent
China tencent open source team.
from haxe-js-kit.