Closed kevinresol closed 8 years ago
You should be able to do this like so:
@await
class Test {
@await public function member() {
var closure = @async function() return 1;
}
}
It's not documented because I don't think it should also be called @await :) I'm unsure how I'd like to name this and the exact behaviour it should have.
It doesn't work if it happens that member
is the constructor?
For the name, I don't have an idea either :stuck_out_tongue:. Maybe @transform
? But it seems to generic
Alright because it is using ClassBuilder which excludes the constructor in its members
list.
So I am facing a funny scenario. Buddy only works with constructors and await only won't work on constructors. :joy:
I'll get it fixed :) I didn't know the constructor was not included in the members. I'd like to use the syntax in the tests here as well.
This should work for constructors in 0.1.2.
Getting this to work for the current await testsuite seems to be hard. I bump in to a lot of troubles for getting the syntax to work inside of describe
or it
blocks. There's a bit too much macro stuff going on there currently.
yes, I am trying to work around it. Stay tuned
Tracking here: https://github.com/ciscoheat/buddy/pull/56
About the @await function
issue, I am thinking if we should somehow allow omission of such meta. i.e. convert everything by default
for example:
@await("all")
class Test {
public function sync() { // implicitly becomes `@await public function sync() ...`
var s1 = function() return 1; // implicitly becomes `var s1 = @await function() ...`
var s2 = @notransform function() return 1; // don't transform the contents
}
@async public function async() {
// just as usual
}
}
Well, the issue is for now I don't allow those methods to return.
function test() {
@await something();
return 'ok';
}
An @async function would return a Surprise, but I don't know what do to there. This could become an issue if all of your methods are marked as @await. But then again we could check if an @await is present in the function body and only then throw an error if a return statement is found.
Also it would slow compile time down by having to check all methods, but it might not be that drastic.
That sounds more complicated then I thought. Let's keep it as is for now then. Keep things explicit should be safer.
I have a use case that I need to transform some closures inside a member function while keeping the member function itself intact.
Consider the following code:
In the above example code, I would like to keep
member
aVoid->Void
while transformclosure
toSurprise<Int, Unknown>
.Is it possible to, for example, add a param to
@async
like@async(false)
for such functionality?Note: I am trying to use this with buddy, which has some strict requirements on the syntax.