I've been lightly considering how things would work if we removed required file-level using statements. I had no problems with this model for several years (and lots of code) - but its possible I was just used to this from my Java days. I've been building out some new code lately, and found it a hindrance that I was adding both pod-level depends and per-file usings to make the compiler happy.

My main issue against it is the current system works really well for scoping the types you are using in that file. So you may actually have a dozen name collisions - but since you are only working from a subset, your code is clean and simple.

I think we want to avoid code that looks like this:

using foo::A as FA
using foo::B as FB
using bar::A as BA  

And was thinking of some options here:

using foo      // if a using is specified, his types hide collisions in depends list

using foo      // if two pods specified by using, current compiler behavior stands
using bar 

not using bar  // hide all types from pod bar

Just throwing some ideas out there to gauge feedback on this issue - I'm warming up to this idea - but curious what everyone else thinks.

I've thought this for a while. A fully module based system implies some different thinking - only the module actually exists. Hence my proposal for a proper modeule block (either in its own file, or in one of the regular source files in the pod):

pod Foo {
  using bar
  using bax
  using baz
}

with the file having no further using statements. I would be OK with retaining type level using statements for newcomers.

For conflicting imports, using as at the pod level really should be sufficient. However, perhaps there should be a global "prefix" form as well:

pod Foo {
  using jodaMoney::Money as MyMoney
  using jodaTime as JT_*
}

The latter form causes all types from jodaTime to be available, but with a short prefix:

class Foo {
  date := JT_LocalDate()
}

I don't like not using, as all negatives are an extra layer of confusion.

The main argument against "remote import statememts" I've heard before is that "each source file should be understandable on its own". I don't buy that argument anymore, perhaps in part because imports are a function of the IDE, not coding now. I also think it makes less sense when the module/pod is the key element, and types are significantly less important.

Well we'll always need using statements for scripts.

In the case of pods, it does get sort of annoying to specify using when the compiler already knows what your dependencies are. So I'm sort of leaning towards making them optional in pod code.

Make the pod resolution code standalone and easy to use then, so IDE/tooling can use it directly. Don't want to have to re-implement and have hard to fix issues with this.

Also it would be nice to avoid name duplicates or it gets annoying quickly. Example dom:event , fwt;event