Re: [go-nuts] Re: Short Variable Declarations Are Oversold
If you use Go’s “accept interfaces return concrete types” the dev/ide knows to
declare the concrete type.
Type inference can actually cause more issues during refactorings - not
alleviate them.
Personally, I find types make the code easier to read. But when I write ago I
don’t use them. I find when I review old code it is a bit harder.
In Java I think it is less of an issue (on refactoring) because you normally
use the interface and due to implements you have more safety.
> On Apr 24, 2023, at 2:14 AM, a2800276 wrote:
>
>
> import “os”
> func main() {
> file, _ := os.Open(os.Args[1])
> myfunc(file)
> }
>
> func myfunc(file ???) {
> }
>
> What type should I use to declare “file” in the parameter list for myfunc()?
>
> This argument doesn't seem logical to me. If I fully declare `file` in this
> case, I also have to know which type to declare it as:
>
> var file ???;
> file, _ = os.Open(...)
>
> This will also be a "distraction and waste time". I'm all for explicit
> declarations in cases where they add clarity, but in idiomatic cases, I don't
> feel it adds anything useful.
>
> Additionally, in cases where I am creating a new function to work with the
> variable, surely I'm aware of more context concerning the API, e.g. in the
> example, I'll assume `file` has `Read` and `Close`, but passing the variable
> along, I would assume the operation on the variable will be more involved and
> requiring reading the documentation anyway ...
>
> -tim
>
>
>
>
>
>
> --
> 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/f6c9bafb-50a9-4e40-b091-59988417ebffn%40googlegroups.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/81837BA2-D643-4526-9C79-FAEDD91C1BBA%40ix.netcom.com.
[go-nuts] Re: Short Variable Declarations Are Oversold
import “os”
func main() {
file, _ := os.Open(os.Args[1])
myfunc(file)
}
func myfunc(file ???) {
}
What type should I use to declare “file” in the parameter list for
myfunc()?
This argument doesn't seem logical to me. If I fully declare `file` in this
case, I also have to know which type to declare it as:
var file ???;
file, _ = os.Open(...)
This will also be a "distraction and waste time". I'm all for explicit
declarations in cases where they add clarity, but in idiomatic cases, I
don't feel it adds anything useful.
Additionally, in cases where I am creating a new function to work with the
variable, surely I'm aware of more context concerning the API, e.g. in the
example, I'll assume `file` has `Read` and `Close`, but passing the
variable along, I would assume the operation on the variable will be more
involved and requiring reading the documentation anyway ...
-tim
--
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/f6c9bafb-50a9-4e40-b091-59988417ebffn%40googlegroups.com.
[go-nuts] Re: Short Variable Declarations Are Oversold
Type inference is not the main purpose (or even the purpose) of short
declarations.
I do agree that the negative impact of short declarations is larger than
its positive impact,
for reasons different from the one you described. Some reasons:
* short declarations causes confusions (esp, for new gophers) at some
situations.
* short declarations overlap too much functionalities with normal
declarations.
* short declarations indeed hurt readabilities at some situations (but not
the ones as you described).
On Sunday, April 23, 2023 at 6:31:11 AM UTC+8 jlfo...@berkeley.edu wrote:
> As a beginning Go programmer, I was initially attracted to the short
> variable declaration syntax.
>
> It’s great for declaring variables of a simple type. What could be wrong
> with letting the Go compiler infer a variable type by looking at what’s
> being assigned to the variable, such as:
>
> func main() {
>
> x := 10
>
> }
>
> Nothing. This is trivially the same as
>
> func main() {
>
> var x int
>
> x = 10
>
> }
>
> I didn’t have to waste my precious time by entering an explicit type
> declaration for “x” when the compiler already knew what it was.
>
> But what about something like
>
> import “os”
>
> func main() {
>
> file, _ := os.Open(os.Args[1])
>
> }
>
> Again, nothing is wrong, at least not until I have to pass “file” to
> another function. For example
>
> import “os”
>
> func main() {
>
> file, _ := os.Open(os.Args[1])
>
> myfunc(file)
>
> }
>
> func myfunc(file ???) {
>
> }
>
> What type should I use to declare “file” in the parameter list for
> myfunc()? As a new Go programmer I have to admit that I haven’t memorized
> all the types used in the Go standard library. So, I have to break off
> working on myfunc() to look up the type returned by os.Open(). This isn’t a
> huge deal, but it’s a distraction and can waste time. I suppose that as I
> gain experience with Go, I’ll have to do this less and less.
>
> But, it doesn’t matter how experienced I am with Go when I start using
> user-defined types from packages that aren’t in the Go standard library.
> For example (from Ben Hoyt’s excellent goawk program):
>
> import "github.com/benhoyt/goawk/parser"
>
> func main() {
>
> prog, err := parser.ParseProgram(fileReader.Source(), parserConfig)
>
> myfunc(prog)
>
> }
>
> func myfunc(prog ???) {
>
> }
>
> Since I’m going to have to look up the returned types of
> parse.ParseProgram anyway, what’s the advantage of using a short variable
> declaration? They just delay the inevitable.
>
> Short definitions detract from one of Go’s primary goals - readability. I
> started using Go in the first place because I wanted a strongly typed
> language with explicit type declarations.
>
> As a result of all this, I’ve started to avoid short variable
> declarations, except when I’m initializing a variable inside an "if"
> , "for"
> , or "switch
> ” statement, such as
>
> if v := math.Pow(x, n); v < lim {
>
> }
>
> for i := 0; i < 10; i++ {
>
> }
>
> switch os := runtime.GOOS; os {
>
> }
>
> In these cases I have no choice if I want to declare local temporary
> variables since long declarations aren’t syntactically allowed.
>
> I doubt if this note will change anybody’s mind but it’s something to
> think about.
>
--
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/8c5aeb04-bcd7-45c3-94a1-d128f9cb0834n%40googlegroups.com.
[go-nuts] Re: Short Variable Declarations Are Oversold
I disagree. I don't have your problem. Most (just about all) Go code I read
uses short variable declarations.
There are several popular assistive technologies that you should try. For
example,
Visual Studio Code
https://code.visualstudio.com/
GoLand
https://www.jetbrains.com/go/
peter
On Saturday, April 22, 2023 at 6:31:11 PM UTC-4 jlfo...@berkeley.edu wrote:
> As a beginning Go programmer, I was initially attracted to the short
> variable declaration syntax.
>
> It’s great for declaring variables of a simple type. What could be wrong
> with letting the Go compiler infer a variable type by looking at what’s
> being assigned to the variable, such as:
>
> func main() {
>
> x := 10
>
> }
>
> Nothing. This is trivially the same as
>
> func main() {
>
> var x int
>
> x = 10
>
> }
>
> I didn’t have to waste my precious time by entering an explicit type
> declaration for “x” when the compiler already knew what it was.
>
> But what about something like
>
> import “os”
>
> func main() {
>
> file, _ := os.Open(os.Args[1])
>
> }
>
> Again, nothing is wrong, at least not until I have to pass “file” to
> another function. For example
>
> import “os”
>
> func main() {
>
> file, _ := os.Open(os.Args[1])
>
> myfunc(file)
>
> }
>
> func myfunc(file ???) {
>
> }
>
> What type should I use to declare “file” in the parameter list for
> myfunc()? As a new Go programmer I have to admit that I haven’t memorized
> all the types used in the Go standard library. So, I have to break off
> working on myfunc() to look up the type returned by os.Open(). This isn’t a
> huge deal, but it’s a distraction and can waste time. I suppose that as I
> gain experience with Go, I’ll have to do this less and less.
>
> But, it doesn’t matter how experienced I am with Go when I start using
> user-defined types from packages that aren’t in the Go standard library.
> For example (from Ben Hoyt’s excellent goawk program):
>
> import "github.com/benhoyt/goawk/parser"
>
> func main() {
>
> prog, err := parser.ParseProgram(fileReader.Source(), parserConfig)
>
> myfunc(prog)
>
> }
>
> func myfunc(prog ???) {
>
> }
>
> Since I’m going to have to look up the returned types of
> parse.ParseProgram anyway, what’s the advantage of using a short variable
> declaration? They just delay the inevitable.
>
> Short definitions detract from one of Go’s primary goals - readability. I
> started using Go in the first place because I wanted a strongly typed
> language with explicit type declarations.
>
> As a result of all this, I’ve started to avoid short variable
> declarations, except when I’m initializing a variable inside an "if"
> , "for"
> , or "switch
> ” statement, such as
>
> if v := math.Pow(x, n); v < lim {
>
> }
>
> for i := 0; i < 10; i++ {
>
> }
>
> switch os := runtime.GOOS; os {
>
> }
>
> In these cases I have no choice if I want to declare local temporary
> variables since long declarations aren’t syntactically allowed.
>
> I doubt if this note will change anybody’s mind but it’s something to
> think about.
>
--
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/f73aeed2-7784-47a8-9978-dc1b2178a24dn%40googlegroups.com.
