Many questions

[Yigal Chripun]

Daniel Keep wrote:
> 
> Liang Du wrote:
>> Nick Sabalausky Wrote:
>>
>>> "Fractal" <d294934 at bsnow.net> wrote in message 
>>> news:gtlihm$tt0$1 at digitalmars.com...
>>>> The namespaces: i used them with C++, and the idea of separation between 
>>>> the uses of types, makes a very good layout. Because some namespaces 
>>>> requires more types, always i write each class in separate files. D simply 
>>>> breaks it, making a big amount of lines for imports.
>>>>
>>> ...
>>>
>>> This works fine and does exactly what you want.
>>>
>> The namespaces is better !!!
> 
> That's debatable.  The hateful thing about namespaces is that they give
> you absolutely ZERO clue as to where any particular thing is coming from.
> 
> If I see "tango.io.device.File", I know exactly where the source for
> that module is.
> 
>   -- Daniel

the downside to the current system is when you have one class in a file, 
the full name of it will be SomeClass.SomeClass instead of just 
SomeClass. (because of the redundancy of the module decl. in this case)

Ideally, I'd want at most one public root entity per file.
where entity can be a type (class/struct/union/etc..) _or_ a "module". 
where a module is just a struct with all methods declared static by 
default (that exactly the same thing as today). that's also the same 
thing as the object in scala (if you look at this from an OO perspective).
i.e
object {
  ...
}

also, packaging needs to be enhanced to allow easier management of 
bigger projects.
for example, what if i want to have internal APIs to be used by my 
packages which are not exposed to the end user? the design should 
restrict the package layout as little as reasonably possible.