Import with wildcard

[Peter Froehlich]

Hi all,

On Sat, Nov 14, 2009 at 11:14 PM, RobThaBlob <robth...@hotmail.com> wrote:
> 1. Extremely strong encapsulation - through making dependencies
> explicit at the module level. One of Gilad's fine essays on Room 101
> (http://gbracha.blogspot.com/) actually deals explicitly with the
> evils of "import module.*" in Java, and the same seems to apply to Go.

Thank you for reminding me, I wanted to "flame" regarding that
mechanism before but forgot. :-D

The idea of letting modules break open the namespaces of other modules
is dubious to begin with: why have modules if nobody has to stick to
their boundaries? It's downright silly if you want to call your
language "modular": After module A imports * from module B, you have
to essentially freeze both of them to avoid name clashes further down
the road. (This is especially deadly in a component framework, but who
builds those anymore...) Adding new stuff to an existing module
shouldn't break anyone else's modules. Period.

Now plenty of language designers simply don't care about this. And of
course programmers can avoid it by simply not using the construct. But
it still makes me shiver all over to see it in the language. :-/

Once again a call for taking something out of the language, not all of
us want more, some want less. :-D

Cheers,
Peter
--
Peter H. Froehlich <http://www.cs.jhu.edu/~phf/>
Senior Lecturer | Director, Johns Hopkins Gaming Lab

[Ian Lance Taylor]

Peter Froehlich <peter.hans...@gmail.com> writes:

> On Sat, Nov 14, 2009 at 11:14 PM, RobThaBlob <robth...@hotmail.com> wrote:
>> 1. Extremely strong encapsulation - through making dependencies
>> explicit at the module level. One of Gilad's fine essays on Room 101
>> (http://gbracha.blogspot.com/) actually deals explicitly with the
>> evils of "import module.*" in Java, and the same seems to apply to Go.
>
> Thank you for reminding me, I wanted to "flame" regarding that
> mechanism before but forgot. :-D
>
> The idea of letting modules break open the namespaces of other modules
> is dubious to begin with: why have modules if nobody has to stick to
> their boundaries? It's downright silly if you want to call your
> language "modular": After module A imports * from module B, you have
> to essentially freeze both of them to avoid name clashes further down
> the road. (This is especially deadly in a component framework, but who
> builds those anymore...) Adding new stuff to an existing module
> shouldn't break anyone else's modules. Period.
>
> Now plenty of language designers simply don't care about this. And of
> course programmers can avoid it by simply not using the construct. But
> it still makes me shiver all over to see it in the language. :-/

In Go
import . "package"
is mainly intended for testing. It makes it easier to move testing
code in and out of the package as desired. No doubt some people will
misuse it, but we hope not many.

Ian

[Peter Froehlich]

Hi all,

On Mon, Nov 16, 2009 at 12:01 AM, Ian Lance Taylor <ia...@google.com> wrote:
> In Go
>  import . "package"
> is mainly intended for testing.  It makes it easier to move testing
> code in and out of the package as desired.  No doubt some people will
> misuse it, but we hope not many.

So you have a module foo. You initially write test code in foo, but
later decide you want to move it to foo-test instead. So foo-test now
imports foo with the dot and therefore you don't have to change the
testing code in the course of moving it. Correct?

What about doing it the other way around: Instead of *breaking* the
encapsulation of foo so that foo-test doesn't have to change, make foo
*allow* foo-test to "embed" itself into foo. Inside of foo you'd have
something like this (borrowing a keyword from C++):

import "bla";
import "lalala";
friend "foo-test"; // allow foo-test to embed without qualifying

Inside of foo-test you'd have this:

import . "foo"; // embed into foo

The meaning of "dotted" import is changed to "Only if the exporting
module allows dotted import to the importing module." Note that I
couldn't care less for "friend," replace that with whatever you want,
maybe another special import clause:

import > "foo-test";

The point is that the existing mechanism breaks modularity in
arbitrary ways. This one would only break it in very limited ways to
allow exactly your example. And it's controlled by the exporting
module, not the importing one.

Disclaimer: This idea may be severely broken in arbitrary ways. :-/