Re: [go-nuts] How can I fetch the default locale (server locale not from the request) in Golang
Java’s Locale.getDefault returns (if not overridden) the values from the system
property “user.language” and “user.region”. If these are not set, it simply
returns “en”. See
http://hg.openjdk.java.net/jdk8u/jdk8u60/jdk/file/935758609767/src/share/classes/java/util/Locale.java
For Linux: These system properties (if not overridden) are set on Linux by
interpreting the environment variable “LANG”. See
https://docs.oracle.com/javame/config/cdc/cdc-opt-impl/ojmeec/1.0/runtime/html/localization.htm
Thus the equivalent code in Go would be to access this environment variable.
Thus a simple `locale = os.Getenv("LANG")` or as Jibber-Jabber does it:
```
locale = os.Getenv("LC_ALL")
if locale == "" {
locale = os.Getenv("LANG")
}
```
If it is correct that, as you stated, that you have no access to environment
variables, you won’t be able to conclude more than “en” to be compatible with
Java’s behavior.
--
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] Unexpected type switch case listing & equality behaviour for float64
Apologies for not being more specific with a distilled exampled, the reason
is that I don't understand if this is a bug or expected. Agreed I should
have left the first lines out.
I think Michael Jones summarised it quite well:
> I think the problem is the unexpected type of g. In the "spread out"
switch clauses it is int/float/... but in the "all as one" case it is still
a generic interface.
And Jesse McNelis gave the answer I believe. I misread the specs,
specifically I confused the SimpleStmt with the TypeSwitchGuard.
I am aware that I comparisons here have to be done thoughtful, but the
behaviour between the different styles of switch cases is what felt
unexpected.
On Friday, December 30, 2016 at 5:48:57 PM UTC+1, Jan Mercl wrote:
>
> Can you please reduce the example to a single failing case and state
> what's the expected outcome instead? I, for one, fail to spot where the
> perceived problem is (when reading it on the phone).
>
> On Fri, Dec 30, 2016, 17:26 Uwe Dauernheim <u...@dauernheim.net
> > wrote:
>
>> It seem a float64 of value 0.0 as types interface{} can't be compared
>> equal to 0 in an exhaustive case clause type list, but can be compared
>> equal in almost any other scenario.
>>
>> https://play.golang.org/p/t2u2GGp565
>>
>> I find this unexpected. Could someone explain how case clause type lists
>> in type assertions work?
>>
>> The language specification states:
>>
>> > In clauses with a case listing exactly one type, the variable has that
>> type; otherwise, the variable has the type of the expression in the
>> TypeSwitchGuard.
>>
>> In the provided playground is no TypeSwitchGuard given, so this rule
>> should not affect behaviour.
>>
>>
>> --
>> 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.
>>
> --
>
> -j
>
--
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: Unexpected type switch case listing & equality behaviour for float64
A similarly unexpected behaviour occurs for
int: https://play.golang.org/p/NP8_xHc1Rv
On Friday, December 30, 2016 at 5:26:51 PM UTC+1, Uwe Dauernheim wrote:
>
> It seem a float64 of value 0.0 as types interface{} can't be compared
> equal to 0 in an exhaustive case clause type list, but can be compared
> equal in almost any other scenario.
>
> https://play.golang.org/p/t2u2GGp565
>
> I find this unexpected. Could someone explain how case clause type lists
> in type assertions work?
>
> The language specification states:
>
> > In clauses with a case listing exactly one type, the variable has that
> type; otherwise, the variable has the type of the expression in the
> TypeSwitchGuard.
>
> In the provided playground is no TypeSwitchGuard given, so this rule
> should not affect behaviour.
>
>
>
--
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] Unexpected type switch case listing & equality behaviour for float64
It seem a float64 of value 0.0 as types interface{} can't be compared equal
to 0 in an exhaustive case clause type list, but can be compared equal in
almost any other scenario.
https://play.golang.org/p/t2u2GGp565
I find this unexpected. Could someone explain how case clause type lists in
type assertions work?
The language specification states:
> In clauses with a case listing exactly one type, the variable has that
type; otherwise, the variable has the type of the expression in the
TypeSwitchGuard.
In the provided playground is no TypeSwitchGuard given, so this rule should
not affect behaviour.
--
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] Using xml.Encoder.Encode over xml.Encoder.EncodeElement
Is there a downside in using `xml.Encode` instead of `xml.EncodeElement` when implementing the `xml.Marshaler` interface? I see in the documentation: Using start as the element tag is not required, but doing so will enable Unmarshal to match the XML elements to the correct struct field. But am not sure if not leveraging "will enable..." does have a concrete downside? I marshal a type `Amount` to `42` via `xml.Encoder.Encode`: https://play.golang.org/p/64FC-j0FyA . If I however use `xml.Encoder.EncodeElement` I get: `42` (uppercased). -- 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.
