-
-
Notifications
You must be signed in to change notification settings - Fork 255
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
Version 2 Review #56
Comments
Regarding Emitter, I do not see any case where that branch ever shall be hit … looks like dead code to me which we can remove. Agree on timeout() and Pause regarding keep-alive. Why shall Coroutines accept callables? It is only appending The difference between wrap() and coroutine() is that the one calls rethrow() and the other returns the promise. I'm not sure here. Having wrap reduces possibility that it's forgotten to manually rethrow on the caller side, but at the same time it's more confusing. I wish to hear others opinion here. / For the other functions, better ask @trowski |
@bwoebi Just the same reason why we accept |
I do not think that was a good decision back then and the status quo [in v2] presents a better solution. |
If you argue that way, we should probably also remove all wrappers like |
The annotation in I agree with @bwoebi, the The path in
I agree, The value for
|
@trowski I'm not sure whether observables should completely fail if one emit fails. Regarding
I have seen the use of I don't know whether I used |
The API looks really good. Great review too @kelunik. Regarding the proxy functions - such as E.g. execute($fn);
// vs
Loop::execute(wrap($fn)); Calling the Loop methods directly also seems much more explicit to me, whereas |
I disagree that it is additional stuff to learn. Developers don't need to learn the Loop stuff unless they want to do very advanced things. Thus the only thing devs have to learn is the proxy functions which handily auto-wrap for you. |
@bwoebi They have to, assuming Amp isn't the only implementation. It's two ways of doing the exact same thing without providing real benefit. Most |
@kelunik Why? Other implementations will need to use their own proxy/the loop funcs directly, but someone who uses Amp can use libraries from other impls without needing to know about the loop funcs?? |
I'd say people should know about
Any library you use and might dig into might use another async helper library. |
@bwoebi In general the discussion should be why we should have them instead of why we might not need them. The public API should be as minimal as possible. That's not only less to document, less bugs, it's also less to read and learn when starting. |
We're talking about the same - We should have it, because it isn't an extra API (i.e. I disagree people should need to know about Loop) and is the most useful API for people. |
@bwoebi We're not talking about the same. I want to remove those functions, you want to keep them. |
Are you suggesting 1) people shouldn't need to know that the loop is there or 2) that they simply shouldn't need to know the interop loop API? If 1) then what do we expect people to think If 2) then what makes these proxy functions superior to the interop Loop methods? Are they simply there to provide insulation or are they there to add coroutine support? As a user I think I'd always code against interop so that I could swap out implementations, but using amp I'd be a bit confused about why I had an additional way of operating on the loop. |
I mean 2), and it has both benefits, a bit of insulation (e.g. in case the spec ever changes!?) Both. Also, you anyway won't be able to swap simply. the Promise API. The helper functions. The coroutine class. Too many dependencies. |
That gains us nothing. The spec should be pretty stable at this point.
I still think we should separate those into separate packages. The helper functions and coroutine class are useful for any promise implementation. |
That gains us nothing. People may include amp without using all the available functions and classes. |
It does. We can update observables should a need to standardize them arise without requiring all packages using coroutines to upgrade to a new major version. |
That's an utopian dream. We could then as well just create a separate repo for every single function, because they might need to be changed somewhen. Realistically, you end up having observables at least as an indirect dependency if you use anything from amphp. |
I think observables are a separate problem to the proxy functions because they have a clear reason to exist, but I certainly think they would benefit from being standardised in the same way that Promises have been (i.e. an interface). |
I think the proxy functions are unnecessary magic and largely just fluff (as in the case of We currently have a situation where callbacks are sometimes able to be coroutines, but usually they are treated as regular functions. It's difficult to remember under what circumstances a function will be run as a coroutine, so I'd rather remove this magic and require users to be explicit by wrapping callbacks with |
I think we should separate the stream functions into either their own namespace of give them a prefix. |
All important issues have been resolved. |
@trowski @bwoebi @rdlowrey I reviewed Amp v2.0 and here are my comments.
Internal\WhenQueue
How important is the layer of indirection? If we're worried about the call stack, should we instead resolve promises asynchronously?
It could also be renamed to a more generic name like
CallbackQueue
orCallQueue
.Internal\Placeholder
Annotation for
$onResolved
iscallable|\Amp\Internal\WhenQueue|null
, should be?WhenQueue
or ?WhenQueue|null
instead.Coroutine
Why does it not accept a callable as constructor parameter in addition of generators?
Emitter
^ Does that ignore double resolution silently?
Pause
Do we really need $value there? What about
keep_alive = false
?Internal\LazyPromise
Why is this one internal? Why is Amp\lazy suggested to be used only? Why do we even have
Amp\lazy
? Instead of using arguments to Amp\lazy, those parameters can just be use'd in a closure by the user instead of providing them as arguments.Amp\wrap
vs.Amp\coroutine
It is weird to have both and usage will be confusion for users.
Amp\timeout
I think
Amp\timeout
shouldn't keep the loop running. The watchers should probably be unreferenced.Amp\lift
Do we need
lift
? I always ask that when reading the docs regarding it.Amp\filter
Amp\filter
filters observables now instead of promises.The text was updated successfully, but these errors were encountered: