Re: [go-nuts] The If Statement: Switches are better except for a single condition (change my mind)
Goto isn't used often in Go because it has to be invoked on its own line inside a conditional statement block, which often can perform the same decision if you think it through, as well as moving shared elements into functions that share the receiver or have common interfaces, outside of the function. Goto based on a prior statement setting an error would be far more useful, which gets back to my conditional return idea (and then maybe this could be a pattern applied to these scope jumping functions in general, that they can be aborted by a false boolean. Goto is already bound within function scope anyway, so making it more useful couldn't do any real harm, and conditional branching would be the one. It's kinda ironic to me that such a simple idea is so infrequent in high level languages yet everywhere from the assembler macro preprocessor on down. Break, continue, goto, return, all of them would become amazing with conditional execution. For me, the novel if and for syntax was the biggest stand-out thing I noticed about Go, at the beginning. I had already got familiar with closures , and it took some time to absorb exactly what interfaces are about. They are amazing but the various cool features of if's pre-condition statement and the condition-only for (removing the need for the semicolons especially), these are a break outside of the very tired conventions of for if while wend foreach, etc etc, and let you structure the logic flow more intuitively and visually. Switches look nice and read well, but the keyword and block boundary raise the cost of casual use. On Tuesday, 25 September 2018 04:15:02 UTC+2, Robert Engels wrote: > > Pretty sure that is what I said... duplicate the work in every case is > silly, thus the goto... if no work, no need for goto > > > On Sep 24, 2018, at 9:10 PM, Dan Kortschak > wrote: > > > > Rule: All rules are bad (including this one). > > > > goto is useful when there is a need to do some elaborate clean up (or > > other work) at the postamble of a function, but in many cases it > > becomes clearer to have the work done at the location (say in the > > switch in the example in this thread). Use of judgement is worthwhile > > as to whether this is true for any particular situation. > > > >> On Mon, 2018-09-24 at 20:11 -0500, robert engels wrote: > >> You should always return from the place of return, or goto > >> return_label, when a result/error needs to be formatted. > >> > >> See the Knuth paper I posted a while ago on using goto... > > > > -- > > 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] The If Statement: Switches are better except for a single condition (change my mind)
There are two extremes: lots of work, most likely use goto or factor into a returning function (this is probably more commonly used in Go unless there is locally scoped data that would make a call onerous); no work - probably use a return at the site. However, where does the boundary exists. Is fmt.Errorf enough work? maybe there are three (for some value of three) places where this happens but a sparsely distributed enough that it makes sense to do the work at the site. The issue is that a simple rule does not take into account the situation's context. On Mon, 2018-09-24 at 21:14 -0500, Robert Engels wrote: > Pretty sure that is what I said... duplicate the work in every case > is silly, thus the goto... if no work, no need for goto -- 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] The If Statement: Switches are better except for a single condition (change my mind)
Pretty sure that is what I said... duplicate the work in every case is silly, thus the goto... if no work, no need for goto > On Sep 24, 2018, at 9:10 PM, Dan Kortschak > wrote: > > Rule: All rules are bad (including this one). > > goto is useful when there is a need to do some elaborate clean up (or > other work) at the postamble of a function, but in many cases it > becomes clearer to have the work done at the location (say in the > switch in the example in this thread). Use of judgement is worthwhile > as to whether this is true for any particular situation. > >> On Mon, 2018-09-24 at 20:11 -0500, robert engels wrote: >> You should always return from the place of return, or goto >> return_label, when a result/error needs to be formatted. >> >> See the Knuth paper I posted a while ago on using goto... > > -- > 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] The If Statement: Switches are better except for a single condition (change my mind)
Rule: All rules are bad (including this one). goto is useful when there is a need to do some elaborate clean up (or other work) at the postamble of a function, but in many cases it becomes clearer to have the work done at the location (say in the switch in the example in this thread). Use of judgement is worthwhile as to whether this is true for any particular situation. On Mon, 2018-09-24 at 20:11 -0500, robert engels wrote: > You should always return from the place of return, or goto > return_label, when a result/error needs to be formatted. > > See the Knuth paper I posted a while ago on using goto... -- 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] The If Statement: Switches are better except for a single condition (change my mind)
You should always return from the place of return, or goto return_label, when a
result/error needs to be formatted.
See the Knuth paper I posted a while ago on using goto...
> On Sep 24, 2018, at 7:22 PM, Louki Sumirniy
> wrote:
>
> Using named return values and this construction you can drop all those
> returns in each case block to outside the block. You only need to spend an
> extra line if you have to break out of it by return or break.
>
> On Monday, 24 September 2018 16:01:23 UTC+2, Lucio wrote:
> You never used:
>
> switch {
> case err == io.EOF:
>...
>return
> case err != nil:
> ...
> return
> default:
> ...
> }
>
> or similar (the default portion has a few, slightly different options,
> depending on preceding code)???
>
> Lucio.
>
>
> --
> 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] The If Statement: Switches are better except for a single condition (change my mind)
On Tuesday, 25 September 2018 10:22:52 UTC+10, Louki Sumirniy wrote: > > Using named return values and this construction you can drop all those > returns in each case block to outside the block. You only need to spend an > extra line if you have to break out of it by return or break. > Go is not a language that trades clarity for brevity. -- 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] The If Statement: Switches are better except for a single condition (change my mind)
Using named return values and this construction you can drop all those
returns in each case block to outside the block. You only need to spend an
extra line if you have to break out of it by return or break.
On Monday, 24 September 2018 16:01:23 UTC+2, Lucio wrote:
>
> You never used:
>
> switch {
> case err == io.EOF:
>...
>return
> case err != nil:
> ...
> return
> default:
> ...
> }
>
> or similar (the default portion has a few, slightly different options,
> depending on preceding code)???
>
> Lucio.
>
>>
>>>
--
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] The If Statement: Switches are better except for a single condition (change my mind)
You never used:
switch {
case err == io.EOF:
...
return
case err != nil:
...
return
default:
...
}
or similar (the default portion has a few, slightly different options,
depending on preceding code)???
Lucio.
>
>>
--
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] The If Statement: Switches are better except for a single condition (change my mind)
Ah, I wasn't quite clear on that. That does make them a lot even more useful. On Monday, 24 September 2018 11:12:38 UTC+2, ohir wrote: > > On Mon, 24 Sep 2018 01:37:56 -0700 (PDT) > Louki Sumirniy > wrote: > > > I am quite a fan of switch statements, they can make a list of responses > to > > a change in state very readable and orderly. > > But you have to remember a few things about them. > > > They don't evaluate in any definite order, > > I did not quite follow the whole post but expression switch > **is evaluated in an exact order**: > > [Switch Statements](https://golang.org/ref/spec#Switch_statements) > :: In an expression switch, the switch expression is evaluated and the > case > :: expressions, which need not be constants, are evaluated left-to-right > and > :: top-to-bottom; the first one that equals the switch expression triggers > :: execution of the statements of the associated case; the other cases are > :: skipped. If no case matches and there is a "default" case, its > statements > :: are executed. There can be at most one default case and it may appear > :: anywhere in the "switch" statement. A missing switch expression is > :: equivalent to the boolean value true. > > > -- > Wojciech S. Czarnecki > << ^oo^ >> OHIR-RIPE > -- 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] The If Statement: Switches are better except for a single condition (change my mind)
On Mon, 24 Sep 2018 01:37:56 -0700 (PDT) Louki Sumirniy wrote: > I am quite a fan of switch statements, they can make a list of responses to > a change in state very readable and orderly. > But you have to remember a few things about them. > They don't evaluate in any definite order, I did not quite follow the whole post but expression switch **is evaluated in an exact order**: [Switch Statements](https://golang.org/ref/spec#Switch_statements) :: In an expression switch, the switch expression is evaluated and the case :: expressions, which need not be constants, are evaluated left-to-right and :: top-to-bottom; the first one that equals the switch expression triggers :: execution of the statements of the associated case; the other cases are :: skipped. If no case matches and there is a "default" case, its statements :: are executed. There can be at most one default case and it may appear :: anywhere in the "switch" statement. A missing switch expression is :: equivalent to the boolean value true. -- Wojciech S. Czarnecki << ^oo^ >> OHIR-RIPE -- 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] The If Statement: Switches are better except for a single condition (change my mind)
I am quite a fan of switch statements, they can make a list of responses to
a change in state very readable and orderly. But you have to remember a few
things about them. They don't evaluate in any definite order, so any
conditions that need more than one response need to use a fallthrough,
which evens out the gap between if and switch.
But for precedent or exclusive conditions, and more than one condition in
general, it's neater to use a switch:
if {
} else {
}
versus
switch {
case
default:
}
It takes the same number of lines and about the same number of characters
but the switch makes the relationship between conditions more obvious (no
fallthroughs, meaning each case is exclusive) and from there on, exclusive
cases save one line compared to a more wordy chain of if {} else if {}.
In libraries I am writing at the moment, there is also another issue to
deal with. Working with pointers means always being at risk of receiving an
unallocated variable. As this would be a fallthrough case, it does not
benefit from the use of a case, nor does it really do it detriment. But
what I have found is that instead I can export the function of allocating
on demand and perhaps registering the receiver was nil in a status/error,
and a case with 3 lines of statement collapses to one assignment that hides
the conditional in the function, drastically reducing the repetition. Even
when the nil condition requires a different response (such as an array
length query) it's not harmful to use this to avoid the nil panic.
These kinds of repeated test-and-calls are a reason why I have proposed
conditional returns and a third switch section header that implies
fallthrough instead of requiring this additionally. Conditional returns
function like an if statement with a return, and fallthrough keyword for a
case type would make this conditional embedded in the function for
triggering allocation mostly redundant since its case can be concisely
specified to fall through, and it's more obvious what is meant compared to
my hackish solution.
--
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.
