FAQ
How is this any different from a non-relative import with conflicting
package names?

~
Doug.
On Friday, May 17, 2013 9:33:16 AM UTC+8, Dave Cheney wrote:

Here is an example where relative imports create package aliases

GOPATH=/home/user/a:/home/user/b

We have a package d in /home/user/b/src/c/d which imports "../c". We
also have a package c in /home/user/a/c ... which version of c is
bound into the final executable ?

On Fri, May 17, 2013 at 11:23 AM, Robert Johnstone
<r.w.jo...@gmail.com <javascript:>> wrote:
I agree. If you'll read back, you'll note I've already said pretty much the
same thing. However, failure to prove A is not proof of not A. i.e. No one
has yet provided a reason to remove relative paths.


On Thursday, 16 May 2013 20:34:27 UTC, kortschak wrote:

It doesn't, but it does deny that an intrinsic package heirarchy can be
used as an argument to support their inclusion/retention.

On 16/05/2013, at 10:53 PM, "Robert Johnstone" <r.w.jo...@gmail.com>
wrote:
I don't disagree, but how does that translate into an argument for or
against relative imports?
--
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 <javascript:>.
For more options, visit https://groups.google.com/groups/opt_out.
--
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+unsubscribe@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.

Search Discussions

Discussion Posts

Previous

Follow ups

Related Discussions

People

Translate

site design / logo © 2021 Grokbase