For me it is the following:
Import declaration Local name of Sin
import "lib/math" math.Sin
import M "lib/math" M.Sin
import . "lib/math" Sin
I have to type the annoying dot in front of each package name in order
to refer to an imported item without qualification. From my very
limited experience, you can mostly get away with this without
ambiguity, and if you find that something is ambiguous, it would be
simple to zoom up to the top of the file and correct it if the rule
was:
import . "lib/math" math.Sin
import M "lib/math" M.Sin
import "lib/math" Sin
I also have some difficulty leaving out the semicolons and the
parentheses around ifs and so on. And if I get used to it, then I'm
going to start making stupid mistakes in D.
I'd suggest getting used to using fully qualified names. Explicit is
better than implicit.
If having to type the dot is that annoying then you are definitely
importing too many packages in to your package's namespace.
"Namespaces are one honking great idea", and it's really f**king
annoying trying to find out which package a function is from without
them.
Remember, any code you write is going to be read many more times then
it is written, any time you can save the reader is good.
The amount of time spent typing is a small fraction of the time spent
programming and conciseness in go isn't about the writing, it's more
about the reading.
> I also have some difficulty leaving out the semicolons and the
> parentheses around ifs and so on. And if I get used to it, then I'm
> going to start making stupid mistakes in D.
>
You can put the semicolons in if you want to, and gofmt will take them out.
The lack of parentheses around if conditions still trips me up too,
but it's much cleaner to read.
- jessta
--
=====================
http://jessta.id.au
-Ostsol
> You can put the semicolons in if you want to, and gofmt will take them out.
> The lack of parentheses around if conditions still trips me up too,
> but it's much cleaner to read.
>
OK, so we've discussed my irrational prejudices. The question I was
asking is what is yours - a bit of light relief after a long day.
if (...) {
} else {
}
instead of my preferred
if (...) {
}
else {
}
This convention we have, using the package names always, is deliberate. Yes, sometimes it makes for more typing but we believe in the long run it means less typing.
-rob
On Jan 23, 8:43 am, teales <steve.te...@britseyeview.com> wrote:
> I also have some difficulty leaving out the semicolons and the
> parentheses around ifs and so on. And if I get used to it, then I'm
> going to start making stupid mistakes in D.
A nice transition for programmers coming from a C-style language might
be if parens were optional around around the condition in an if
statement, but gofmt takes them out. (This assumes the habit of
running all code through gofmt catches on.)
- Brian
> Since package names are used in qualified identifiers could import
> declarations be made optional?
Technically yes, but that would make it less obvious what the dependencies are and one of the important elements of Go is clear dependency declarations.
-rob
No. Does vector refer to container/vector or my/local/vector?
Russ
fmt and math are in nearly none of my go packages. As you said, not
much of anything would be gained, but IIUC it complicates the
compiler, which currently does not have to know about any specific
packages.
Let's keep imports explicit.
huh? sure you can.
http://golang.org/doc/go_spec.html#Function_literals
--
=====================
http://jessta.id.au
fmt and math are in nearly none of my go packages
it complicates the compiler
[the compiler] currently does not have to know about any specific packages
> huh? sure you can.http://golang.org/doc/go_spec.html#Function_literals
>
> --
I think you know what I mean. At top level scope I can write
func outer() int { ... }
In a function scope I must write
inner := func() int { ... }
Why the irregularity?
I've written plenty of packages _and_ programs that have used fmt and
io only for testing/debugging purposes. I would not appreciate having
them auto-imported for me.
Shift your thinking on this issue. Explicit is better than implicit.
Namespaces are a good idea. There is no real downside to typing
"fmt.Printf" and there are many upsides.
I would not appreciate having them auto-imported for me.
Ivan
The compiler would still need to find the packages during compilation
or somehow magically recognize that those packages are exempt from
lookup rules. This becomes a problem when you work with targets that
don't support the standard library, either by accident or choice. E.g.
my current work is with a small embedded target that only has a small
custom runtime and none of the standard packages.
Aside from my inconvenience, auto-import would add an element of
unnecessary surprise.
Kai
you're right, I missed your point. Sorry.
The compiler would still need to find the packages during compilation
auto-import would add an element of unnecessary surprise
Thankfully you don't need to import anything to print something in go.
The print() and println() functions are built-ins.
--
=====================
http://jessta.id.au
-1 on your suggestion, +1 on how it is now.
Non-qualified names are such a pain when trying to figure out what a
certain piece of code means that people who use them should be made to
jump through a hoop or two.
--vk
+1 on Vesa's thoughts.
I call it non-grepable sources. C++ has them, mostly because of
function overloading by type. Unfortunately Go has them too, because
there is polymorphic method dispatch (interfaces and their
method) and you can have same names in different modules. Personally I
find it very confusing sometimes. For example we have io.Reader and
flate.Reader. I mean.. it's really bad even that way. One of the
features I like in C is unique naming in everything. If you see
some_long_function_name, you can just grep all the sources for it and
find out what it means. No kind of redirection is necessary. C++ for
example is really horrible on this, there are: function/operator
overloading, dynamic polymorphism, preprocessor, templates and other
horrible things. It's _very_ hard to grep over C++ sources.
Well, Go has few of this problems too.. unfortunately. And I really
want that no one will make it even worse. By worse I mean encouraging
full namespace import to the current namespace.
However, Go has simple syntax and it is possible to create nice tools
for jumping over Go's sources. But currently there are no such tools.
So.. I use grep. ;-)
The religion you're not aware of has this commandment:
Just because Ryanna doesn't like to type import "fmt" import "io"
doesn't mean the language has to change. Typing less than 20
characters is a respectful bow to the keyboard and not eternal
damnation.
So there, we got religious too. :-D
--
Peter H. Froehlich <http://www.cs.jhu.edu/~phf/>
Senior Lecturer | Director, Johns Hopkins Gaming Lab
Typing...is a respectful bow
However, there are potential readability issues and also other
situations where explicit import declarations would be necessary. For
example, if there are two packages 'foo' and 'stuff/foo', which does
Go import? It must match the identifier being referenced to those
that are available in the two packages -- and there is still room for
ambiguity when both packages share an identifier.
My preference: keep explicit import declarations in all cases. It
keeps code clear and it keeps this aspect of the compiler simple.
-Ostsol
On Jan 24, 10:40 am, Ryanne Dolan <ryannedo...@gmail.com> wrote:
> Peter,
>
> "Go attempts to reduce the amount of typing"
>
> http://golang.org/doc/go_lang_faq.html#principles
>
> Typing...is a respectful bow
>
> If we are trading one religion for another, I should like to know why!
>
> I'm not necessarily a firm believer in either; I'm just saying we should
> stick with one, and boilerplate like importing the standard library seems to
> violate the first commandment of Go's religion.
>
> Thanks.
> Ryanne
>
> --www.ryannedolan.info
>
> On Sun, Jan 24, 2010 at 9:33 AM, Peter Froehlich <
>
>
>
> peter.hans.froehl...@gmail.com> wrote:
> > On Sun, Jan 24, 2010 at 1:16 AM, Ryanne Dolan <ryannedo...@gmail.com>
OK, so we've discussed my irrational prejudices. The question I was
> You can put the semicolons in if you want to, and gofmt will take them out.
> The lack of parentheses around if conditions still trips me up too,
> but it's much cleaner to read.
>
asking is what is yours - a bit of light relief after a long day.
...I see two ways in which the standard library can be automatically imported: (1) into the global namespace, or (2) implicitly whenever a package is referenced...
How does one compile those packages now that they import themselves?
Seems like a giant cycle to me, and hardly worth the effort.
Suppose you pick a set of auto-imported packages:
* Now you've saved what, one or two lines per file?
* Do we start to argue about which packages should be in the standard set?
* What happens when I add import "my/fmt" to the top of a file that was
referring to the standard fmt before? Is that an error immediately, or
do all the references silently convert? What if I wasn't using fmt before?
* How do you compile fmt if it auto-imports itself? Isn't that a cycle?
Implicit dependencies are perhaps the biggest problem in C and C++
when trying to change code in very large code bases. This is one of
the problems that Go tries to clean up, and explicit imports are a large
part of that effort.
> Notice that built-in "print" and fmt.Print are different, but probably
> shouldn't be. Clearly the Go team thinks printing should come with Go
> without asking.
No. The Go team recognizes that when you're bootstrapping a new
system it's important to be able to print before you've got enough
working to implement fmt or even import. That's why the spec refers
to them as bootstrapping functions:
http://golang.org/doc/go_spec.html#Bootstrapping
As it also says, they are not guaranteed to stay in the language.
Russ
I'd go with the upper-case Vector (func (v Vector) Add (v Vector) Vector
...), so the compiler can know it is a type that, if not defined in the
current context, had to have been explicitly provided by a previously
imported package. Multiple definitions would be a compile-time error.
What if I wanted to extend vector.Vector by adding fields and methods to
it, then exposing it as myVector.Vector? Code written using "vector"
would fail, because the user imported myVector instead of vector. But
code written using Vector could run unaffected.
I can't count the times I've had to do global search-and-replace to
handle such situations. It would be great if Go provided a neat
work-around by permitting the package name to be omitted from a reference.
Oh, wait, Go already does this by the 'import . "package"' syntax.
Adding a single dot doesn't seem like much of a hassle.
Never mind.
-BobC
This is not a valid program. You can't define a method on
a type in another package, so this would have to be in package
vector, at which point it would become:
func (v Vector) Add(u Vector) Vector { ... }
which is much more reasonable.
Russ
This is my first post here so treat my 2¢ accordingly :)
Making the compiler knowledgeable about specific packages so that it automagically provides support for them is a premature optimisation.
Firstly the Go language and its standard library are still very young so its entirely plausible that both will change significantly in the coming years. However by giving certain packages a special significance to the compiler at this stage there'll be a constant pressure to retain their use regardless of viable and more idiomatic alternatives.
Secondly building unnecessary dependencies into the reference implementation of the language will mean that future implementations will also have to support them, regardless of whether or not they're appropriate.
Ellie
Eleanor McHugh
Games With Brains
http://slides.games-with-brains.net
----
raise ArgumentError unless @reality.responds_to? :reason
As Rob said earlier, import . is really for special cases,
not general use.
Suppose that you do write
import . "container/vector"
import "os"
in one of your packages, and that package defines func New().
If os decides to add a func New, no big deal, it's os.New in
your package and not a problem. If vector decides to bring
its func New back, your package breaks because of the naming
conflict. If you want your packages to work long term, it's
best to avoid import . unless you control the thing being importing
that way.
That is, overusing import . makes code fragile, overly
dependent on details of other packages.
It only makes sense when the package doing the import
and the package being imported are coordinated,
like fmt_test and fmt.
Russ
...that package defines func New()....
func (t Type) Method(p Param) {}
I'd love to have a shortcut such as:
method (t Type) (
func Method_1(p Param) {};
func Method_2(p Param) {};
)
or maybe even:
T method (
func Method_1(p Param) {};
func Method_2(p Param) {};
)
where type T would be bound to 'self' in each of the contained methods.
The current syntax certainly has drawbacks but it also has advantages:
1) It avoids the pitfalls of function declarations in C and C++.
2) Function arguments and multiple return values have the same
syntax. (Single return values are treated specially as a compromise
to brevity.)
3) As the one place in the language where types are always explicit,
the apparent verbosity can be justified as clarity.
4) The func keyword makes the meaning always clear.
Regarding the syntax of methods:
5) It's a regular extension of function syntax.
6) The receiver syntax is exactly a (one-argument) parameter list.
7) The receiver name is, like all other names, chosen by the
programmer. Because of that, it can be short yet clear, often one
letter, unlike automatically chosen ones (self, this) that must be
longer because they must not conflict with user-chosen names. If the
method doesn't use the receiver, it doesn't even need to name it.
Finally, and most important, it parses unambiguously. (There's a now-
unnecessary requirement to parenthesize a single return value of
function type, but that will be removed.)
You may think the disadvantages outweigh the advantages but we are
comfortable with the tradeoffs we made. Compromises, by definition,
do not satisfy everyone.
-rob
Too true, and good language design is always a compromise.
The one thing I'd say in defence of my 'method' syntax suggestions (which strictly speaking are an analogue to import and const rather than a replacement for func) is that to people coming from class-based OO languages they might feel more natural. Of course that could just be a bias I've picked up from years of Ruby coding :)
func (
F1() {}
F2() int {}
)
or
func (t *T) (
M1() {}
M2() int {}
)
Though this would be ambiguous. Oh well.
For me, i'm coming from the last few years of Python, this feels so much like
it that I love using `:` for something do things like `for k,v := range vmap:`
and write the short declaration incorrect, i.e. `i = 0` instead of `i := 0`
--
"IBM uses what I like to call the 'hole-in-the-ground technique'
to destroy the competition..... IBM digs a big HOLE in the
ground and covers it with leaves. It then puts a big POT
OF GOLD nearby. Then it gives the call, 'Hey, look at all
this gold, get over here fast.' As soon as the competitor
approaches the pot, he falls into the pit"
- John C. Dvorak
My 2 cents, this thread is about what you don't like in Go syntax, not "What I
want Go to be."
Following this list since the new year and it seems to me that a majority of
threads are this style. While I won't disagree to, these threeads are a good
thing for the developers to know what we want, It's the follow up posts, not
from the developers, but from those who disagree with the developers or
consensus reasoning and fight for what they want. That makes me wonder if Go
should already be forked into something else for those people.
This also leads me to this question, why can't people let Go be what the
developers believe is the 'correct' way for the language? From their answers,
the FAQ, Docs, and before I started with Go, just the reputation of yhr people
behind Go, you knew they put a lot of thought into this.
Personally, I think Go will be a major language in the future, but I don't
believe it will be the be all-end all in languages. I don't know if one
language will cover all needs, without becoming C/C++ or similar, with a lot
of convulution in the compiler (or interpretter) and tricky syntatic rules.
If I offended anyone, sorry, I'm just venting my own little frustrations.
Mike
--
Let's just be friends and make no special effort to ever see each other again.