Now that we are going with the "pod" approach I've been giving some thought to the notion of pods versus namespace/packages. Basically I think packages are just a confusing abstraction that should be killed. There should just be pod names and class names, end of story (no notion of a packages).

Why do we separate classes into packages? The only use seems to be to organize source code or documentation, which neither one really requires a first class language construct. There is package scoped protection, but in general I'd rather have pod scoped protection anyways.

Furthermore the notion that naming is simplified to be pod name and classname dovetails a bit better when using scripting files:

import web             // import web pod and all its types
import ../utils.fan    // import utils file from my parent directory

So basically what I am thinking is that import means to import a pod, and importing a pod imports all the types in that pod into your local compliation unit namespace. Or if a file name is specified, it means import a script file. But source code can still be organized into different dirs (the compiler will just recursively search for "*.fan"). Plus we can consider adding some type of meta-data tags for documentation - although honestly I'd rather keep the surface area of types in a pod small (less public classes, with more methods).

Getting rid of the notion of arbitrary type names get's us back to universally identifying a type as <pod><sep><type>. If we pick a separator other than the dot, that makes the parsing much less ambiguous (right now it is a killer trying to figure out what a.b.c means). Rubys uses #, which might not be so bad: web#WebRequest web@WebRequest web~WebRequest web^WebRequest. I'd prefer to stay away from dot or colon since they are used in other ways. What do you guys vote?

That's not a bad idea, since we have the notion of pods, you are right that packages just really get into your way. We may find we need to have some way to "subdivide" pods - but I can't think of any reason at the moment.

Like I said you probably do want to subdivide for source and documentation, but I can't ever think of a reason of subdividing the type namespace other than to force a shitload of extra import statements.

You know though, that poses some interesting design issues - in Java I can "design downward" where some base functionality is independant of the sub-package (or any other package) - and it gets enforced at compile time. I sort of lose that - but its less of a big deal because its isolated to my pod.

Of course, the biggest issue - having to import a million things - goes way.

The # sign is ok I guess - not crazy about it though.

I think I like that in general. I like the large-grained approach as a library user because there's less detail that I have to remember when importing.

I do think for docs we may regret not having any finer-grained organization than pod. It sounds like you're talking about adding meta data for doc to solve the "problem" that there is no structure within a pod.

Do you expect we'll create a higher level grouping of pods to define an application and all of the pods that it requires? What do you call a collection of pods?

Yeah I think we need a generic way to categorize or tag pods and types for both documentation and maybe even programming purposes.