That is a good reason as to why putting timeouts and cancellation in the “context” always felt wrong to me. These are per request notions - and creating a new context to specify them seems off. But as I mentioned in the other post, without a concept of security context it doesn’t matter much - just throw anything and everything into the context and pass it around. On Feb 21, 2024, at 4:33 AM, 'Sean Liao' via golang-nuts <golang-nuts@googlegroups.com> wrote:
Alright, well thanks for your input.
I do think these questions can be answered; exploring the use
cases in a proposal format should hopefully show that the impact
of closures would not normally be an issue. Possibly the worst
case is if you had a library to some external service, and at some
low layer you're using a closure, well you might need to refactor
that if you wanted to add cross–service tracing support. But to
be honest, it's probably better that the state you're depending on
is captured in a struct instead of being scattered about loosely
in a scope as with a closure. And the common practice in Go is to
return types that satisfy interfaces, not function references that
you blind call.
I think I will submit a proposal, but please don't take that to
imply that I think you're "wrong, or mistaken". Your concerns are
legitimate and the proposal should answer them cleanly. In the
proposal format, hopefully the "litigation", or more exploration
of possible uses and abuses of the system, along with performance
concerns, can be addressed. I don't want to be dismissive of
them, I just want to understand them.
I had a brief look on the Golang issues in Github and could not
find any prior proposals along this line using "context" and
"dynamic scope" as search terms, so I'll submit this as a "new"
proposal for now.
Thanks again, and truly—thanks for responding, >100% better
than people who just rolled eyes and marked thread as read.
Cheers,
Sam
On 2/20/24 3:35 PM, Axel Wagner wrote:
If I may quote myself:
> And no matter which choice you make for the language -
it means that if the programmers wanted the other, they'd have
to jump through annoying hoops and get confusing and hard to
debug problems.
Having a mechanism to get one or the other semantic doesn't
change the fact that it's easy to choose wrongly by accident,
as long as the effect is implicit. In fact, the mechanism you
propose (AIUI) seems extra confusing: Having a function value
sometimes create a new dynamic scope and sometimes not, is
weird and seems like a recipe for frustration.
But really, convincing me isn't really the point, which is
why I'm not super invested in litigating this (otherwise I
might try to come up with realistic examples, for instance. Or
explain further why I'm still not sure that this can be
implemented efficiently). I'm just re-stating what, in the
past, where the reasons why things like this have been
rejected. In order to predict what I would consider a likely
outcome of a proposal like this.
If you think I am wrong or misunderstanding you, you can
always file a proposal to get a more official response.
On 2/17/24 1:32 AM, Axel Wagner wrote:
I would argue that the matter can be simply
decided by choosing the calling stack, not
the destination stack.
I agree that this is *one choice*. But the point
is, that *sometimes* you'd want one and *sometimes*
the other. And no matter which choice you make for
the language - it means that if the programmers
wanted the other, they'd have to jump through
annoying hoops and get confusing and hard to debug
problems. So if you want to justify either choice,
you have to make an argument that it is so
overwhelmingly more common what people would want,
that the cost of running into these problems is
small enough to be justified by the benefit.
I think that's a hard case to make.
Alex, I agree that there are cases where you might prefer
one versus the other. However, you cut out the part of my
reply where I pointed out it was possible to choose
semantics by either returning a closure (context is the
source stack) or a bound method (context is the
destination stack). Both of these values can be used
interchangeably, as they have the same type, func ..., and so the caller does
not need to care whether the function they are calling
uses the calling context or the original context. Were
you not convinced by the argument?
Sam
--
Sam
--
You received this message because you are subscribed to the Google Groups "golang-nuts" group.
To unsubscribe from this group and stop receiving emails from it, send an email to golang-nuts+unsubscr...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/golang-nuts/aec85a83-9497-469c-8369-2c9e60d0ca05%40vilain.net.
--
You received this message because you are subscribed to the Google Groups "golang-nuts" group.
To unsubscribe from this group and stop receiving emails from it, send an email to golang-nuts+unsubscr...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/golang-nuts/CAGabyPpcxiexqPqmcFT-RNP8KZv5p8vUFw1%3DHfMwE87puCcGQg%40mail.gmail.com.
--
You received this message because you are subscribed to the Google Groups "golang-nuts" group.
To unsubscribe from this group and stop receiving emails from it, send an email to golang-nuts+unsubscr...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/golang-nuts/A3F9D79D-B287-4047-9775-522475B9850D%40ix.netcom.com.
|
