Re: [go-nuts] Re: context.C and context.BG

['Axel Wagner' via golang-nuts]

Given that there should be exactly one call to context.Background per
binary (in func main()), I don't understand the problem this is trying to
solve. Similarly, context.TODO might be used, but should be used
temporarily, as a migration tool, so it shouldn't matter that much.

(Regarding context.C, I don't have an opinion.)

On Sat, Nov 18, 2017 at 7:55 PM, Alex Buchanan 
wrote:

> So, context.Bg could be a value then? context.TODO could stay a function.
>
> On Saturday, November 18, 2017 at 6:01:07 AM UTC-8, Sameer Ajmani wrote:
>>
>> Context.TODO and Background have different String values; see
>> emptyCtx.String.
>> On Fri, Nov 17, 2017 at 9:25 PM me via golang-nuts <
>> golan...@googlegroups.com> wrote:
>>
>>> I've found a hint. Apparently, both context.TODO and context.Background
>>> share a common implementation but they need distinct addresses.
>>>
>>> See https://golang.org/src/context/context.go#L168
>>>
>>> So they cannot be constants because then they would not have an address.
>>> They cannot be variables because then you could modify them. Therefore the
>>> only solution left is to make them a function that returns a variable.
>>>
>>> Then again, maybe you could make Background and TODO of an unexported
>>> type to prevent setting them. I think that was not chosen because it leaks
>>> the internals of the package.
>>>
>>> But I'm not sure why they need distinct addresses in the first place.
>>> I'm guessing its for debugging or just what makes sense? context.TODO and
>>> context.Background are two different contexts and should be treated as such.
>>>
>>>
>>> On Friday, November 17, 2017 at 10:43:29 AM UTC-5, Alex Buchanan wrote:

 I don't have numbers, but context must be one of the most commonly used
 imports/types in my code. It shows up many function signatures. We try to
 use it for all cancelation.

 Would it make sense to add an alias "C" to the type "Context"? And
 maybe "BG" for Background()?

 Also, is there a specific reason Background is a function and not a
 value?

 Cheers,
 Alex

>>> --
>>> 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...@googlegroups.com.
>>> For more options, visit https://groups.google.com/d/optout.
>>>
>> --
> 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.
> For more options, visit https://groups.google.com/d/optout.
>

-- 
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.
For more options, visit https://groups.google.com/d/optout.

Re: [go-nuts] Re: context.C and context.BG

[Alex Buchanan]

So, context.Bg could be a value then? context.TODO could stay a function.

On Saturday, November 18, 2017 at 6:01:07 AM UTC-8, Sameer Ajmani wrote:
>
> Context.TODO and Background have different String values; see 
> emptyCtx.String.
> On Fri, Nov 17, 2017 at 9:25 PM me via golang-nuts <
> golan...@googlegroups.com > wrote:
>
>> I've found a hint. Apparently, both context.TODO and context.Background 
>> share a common implementation but they need distinct addresses.
>>
>> See https://golang.org/src/context/context.go#L168
>>
>> So they cannot be constants because then they would not have an address. 
>> They cannot be variables because then you could modify them. Therefore the 
>> only solution left is to make them a function that returns a variable.
>>
>> Then again, maybe you could make Background and TODO of an unexported 
>> type to prevent setting them. I think that was not chosen because it leaks 
>> the internals of the package.
>>
>> But I'm not sure why they need distinct addresses in the first place. I'm 
>> guessing its for debugging or just what makes sense? context.TODO and 
>> context.Background are two different contexts and should be treated as such.
>>
>>
>> On Friday, November 17, 2017 at 10:43:29 AM UTC-5, Alex Buchanan wrote:
>>>
>>> I don't have numbers, but context must be one of the most commonly used 
>>> imports/types in my code. It shows up many function signatures. We try to 
>>> use it for all cancelation.
>>>
>>> Would it make sense to add an alias "C" to the type "Context"? And maybe 
>>> "BG" for Background()? 
>>>
>>> Also, is there a specific reason Background is a function and not a 
>>> value?
>>>
>>> Cheers,
>>> Alex
>>>
>> -- 
>> 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...@googlegroups.com .
>> For more options, visit https://groups.google.com/d/optout.
>>
>

-- 
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.
For more options, visit https://groups.google.com/d/optout.

Re: [go-nuts] Re: context.C and context.BG

['Anmol Sethi' via golang-nuts]

Ah, thanks!

> On Nov 18, 2017, at 9:00 AM, Sameer Ajmani  wrote:
> 
> Context.TODO and Background have different String values; see emptyCtx.String.
> On Fri, Nov 17, 2017 at 9:25 PM me via golang-nuts 
> > wrote:
> I've found a hint. Apparently, both context.TODO and context.Background share 
> a common implementation but they need distinct addresses.
> 
> See https://golang.org/src/context/context.go#L168 
> 
> 
> So they cannot be constants because then they would not have an address. They 
> cannot be variables because then you could modify them. Therefore the only 
> solution left is to make them a function that returns a variable.
> 
> Then again, maybe you could make Background and TODO of an unexported type to 
> prevent setting them. I think that was not chosen because it leaks the 
> internals of the package.
> 
> But I'm not sure why they need distinct addresses in the first place. I'm 
> guessing its for debugging or just what makes sense? context.TODO and 
> context.Background are two different contexts and should be treated as such.
> 
> 
> On Friday, November 17, 2017 at 10:43:29 AM UTC-5, Alex Buchanan wrote:
> I don't have numbers, but context must be one of the most commonly used 
> imports/types in my code. It shows up many function signatures. We try to use 
> it for all cancelation.
> 
> Would it make sense to add an alias "C" to the type "Context"? And maybe "BG" 
> for Background()? 
> 
> Also, is there a specific reason Background is a function and not a value?
> 
> Cheers,
> Alex
> 
> -- 
> 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 
> .
> For more options, visit https://groups.google.com/d/optout 
> .

-- 
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.
For more options, visit https://groups.google.com/d/optout.

Re: [go-nuts] Re: context.C and context.BG

[Sameer Ajmani]

Context.TODO and Background have different String values; see
emptyCtx.String.
On Fri, Nov 17, 2017 at 9:25 PM me via golang-nuts <
golang-nuts@googlegroups.com> wrote:

> I've found a hint. Apparently, both context.TODO and context.Background
> share a common implementation but they need distinct addresses.
>
> See https://golang.org/src/context/context.go#L168
>
> So they cannot be constants because then they would not have an address.
> They cannot be variables because then you could modify them. Therefore the
> only solution left is to make them a function that returns a variable.
>
> Then again, maybe you could make Background and TODO of an unexported type
> to prevent setting them. I think that was not chosen because it leaks the
> internals of the package.
>
> But I'm not sure why they need distinct addresses in the first place. I'm
> guessing its for debugging or just what makes sense? context.TODO and
> context.Background are two different contexts and should be treated as such.
>
>
> On Friday, November 17, 2017 at 10:43:29 AM UTC-5, Alex Buchanan wrote:
>>
>> I don't have numbers, but context must be one of the most commonly used
>> imports/types in my code. It shows up many function signatures. We try to
>> use it for all cancelation.
>>
>> Would it make sense to add an alias "C" to the type "Context"? And maybe
>> "BG" for Background()?
>>
>> Also, is there a specific reason Background is a function and not a value?
>>
>> Cheers,
>> Alex
>>
> --
> 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.
> For more options, visit https://groups.google.com/d/optout.
>

-- 
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.
For more options, visit https://groups.google.com/d/optout.

[go-nuts] Re: context.C and context.BG

[me via golang-nuts]

I've found a hint. Apparently, both context.TODO and context.Background 
share a common implementation but they need distinct addresses.

See https://golang.org/src/context/context.go#L168

So they cannot be constants because then they would not have an address. 
They cannot be variables because then you could modify them. Therefore the 
only solution left is to make them a function that returns a variable.

Then again, maybe you could make Background and TODO of an unexported type 
to prevent setting them. I think that was not chosen because it leaks the 
internals of the package.

But I'm not sure why they need distinct addresses in the first place. I'm 
guessing its for debugging or just what makes sense? context.TODO and 
context.Background are two different contexts and should be treated as such.

On Friday, November 17, 2017 at 10:43:29 AM UTC-5, Alex Buchanan wrote:
>
> I don't have numbers, but context must be one of the most commonly used 
> imports/types in my code. It shows up many function signatures. We try to 
> use it for all cancelation.
>
> Would it make sense to add an alias "C" to the type "Context"? And maybe 
> "BG" for Background()? 
>
> Also, is there a specific reason Background is a function and not a value?
>
> Cheers,
> Alex
>

-- 
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.
For more options, visit https://groups.google.com/d/optout.