Daniel Keep wrote:
> 
> Liang Du wrote:
>> Nick Sabalausky Wrote:
>>
>>> "Fractal" <d294934@bsnow.net> wrote in message news:gtlihm$tt0$1@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.

Yigal Chripun:
> 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)

Generally if classes or functions are small, you put more than one of them (related ones) in the same module.


> Ideally, I'd want at most one public root entity per file.

That's the Java ideal world.

Bye,
bearophile

> 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

Yes it is true. But the thing is not "where is it". The thing that i want to remark is "what long".

If you use a namespace, you can write many big classes in separate files without problem, and also, with the same namespace. (and also allowing separate a multiplatform class in different files, for each one).

With modules you are limited in a single file. And it will grow potentially with multiplatform code, and makes hard to find a error or line...
Added to it, the amout of version statements.

Also Namespaces can use upper case characters... documentation indicates that package and module names should be written all in lower case.

A good point for modules is the permisson to access private or protected members of types declared in the same module or package, without the "friend" keyword anywhere.
In namespaces, it can be done by sharing access to all namespace types.

Really module, packages, and namespaces are the same thing. The unique thing that i want, is the possibility of use many files as one (for modules)

Fractal:
> Really module, packages, and namespaces are the same thing.

Not really :-) There are semantic differences.

Bye,
bearophile

Fractal wrote:
>> 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
> 
> Yes it is true. But the thing is not "where is it". The thing that i want to remark is "what long".
> 
> If you use a namespace, you can write many big classes in separate files without problem, and also, with the same namespace. (and also allowing separate a multiplatform class in different files, for each one).

public import and mixin.

> With modules you are limited in a single file. And it will grow potentially with multiplatform code, and makes hard to find a error or line...
> Added to it, the amout of version statements.

public import and mixin.

> Also Namespaces can use upper case characters... documentation indicates that package and module names should be written all in lower case.

Oh what rubbish.  You can use whatever case you please.

> A good point for modules is the permisson to access private or protected members of types declared in the same module or package, without the "friend" keyword anywhere.
> In namespaces, it can be done by sharing access to all namespace types.
> 
> Really module, packages, and namespaces are the same thing. The unique thing that i want, is the possibility of use many files as one (for modules)

But you see, this would break bud, rebuild, etc.  I'm pretty sure that if you somehow convinced Walter to do this, you would have a lot of VERY angry people coming after you for completely breaking their build tools.

I know I would be.  I'm not going back to Make!  You can't make me! Viva la laziness!

  -- Daniel

Daniel Keep wrote:
>> Also Namespaces can use upper case characters... documentation indicates that package and module names should be written all in lower case.
> 
> Oh what rubbish.  You can use whatever case you please.

On Windows (actually NTFS, I think), you can't two packages/modules that differ only in case. But if you have namespaces "XML", "Xml" and "xml", you probably have some bigger design issues.

Fractal wrote:
>> 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
> 
> Yes it is true. But the thing is not "where is it". The thing that i want to remark is "what long".
> 
> If you use a namespace, you can write many big classes in separate files without problem, and also, with the same namespace. (and also allowing separate a multiplatform class in different files, for each one).
> 
> With modules you are limited in a single file. And it will grow potentially with multiplatform code, and makes hard to find a error or line...
> Added to it, the amout of version statements.
> 
> Also Namespaces can use upper case characters... documentation indicates that package and module names should be written all in lower case.
> 
> A good point for modules is the permisson to access private or protected members of types declared in the same module or package, without the "friend" keyword anywhere.
> In namespaces, it can be done by sharing access to all namespace types.
> 
> Really module, packages, and namespaces are the same thing. The unique thing that i want, is the possibility of use many files as one (for modules)

Modules are compilation units. This makes them different from namespaces.

Packages are for the compiler to find source code. Namespaces are for humans to find source code. These have sufficient overlap that they have been unified.

For modules to do what you want, a module cannot be the unit of compilation. What then will be the unit of compilation? And why is this feature important enough to merit the change?

bearophile wrote:
> Yigal Chripun:
>> 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)
> 
> Generally if classes or functions are small, you put more than one of them (related ones) in the same module.

sure. nothing I said contradicts this. you can have however many constructs in one file. Either make only one of them as public, or put all of them inside a "module" declaration like you do now.

> 
> 
>> Ideally, I'd want at most one public root entity per file.
> 
> That's the Java ideal world.

well, the trade-off to consider is:
on the one hand - if you go for namespaces like solution you get most flexible design. i.e one file with a bunch of small public classes (for example exceptions) will be exactly the same as many small files with one class in each if in both cases you define all those classes to belong to one namespace.
on the other hand - this removes the ability to know in which file a class is defined.

I think that in such a case it's a reasonable trade off to have:
module exceptions {
  class A {}
  class B {}
  ...
}
where exceptions is the "root" element of the file.

so, exceptions.SomeException can be both a file called exceptions that contains a SomeException class and a exception directory with a file called SomeException that contains that specific class. (also, you can mix both ways, and have only some of the exceptions in separate files).

currently, if I have a file with a bunch of classes, and over time the file became too big and I decided to split it to several smaller files, such a split will affect the code because package.module.classA will become package.module.classA.classA after such a split.

> Bye,
> bearophile

another idea, is that if you have:
package
 |\
 | exceptions
 |    \
 |     classA.d
 |     classB.d
 |
exceptions.d

classA and classB files contain single classes by the same respective names, and exceptions.d contains a bunch of smaller classes in one file.
in this case the compiler could "fuse" together the paths so logically in the code you'll have package.exceptions.[class_name] where class_name is one of classA, classB or any of the classes defined in exceptions.d

does that sound reasonable? this is as close as possible I can think of to full namespaces without loosing the ability to find where some code is located in the file system.

in this case go to 'package' dir, inside you need to check the exceptions.d file. if desired class isn't in this file you know to go check the 'exceptions' dir, and so forth.

Christopher Wright wrote:
> Fractal wrote:
>>> 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
>>
>> Yes it is true. But the thing is not "where is it". The thing that i want to remark is "what long".
>>
>> If you use a namespace, you can write many big classes in separate files without problem, and also, with the same namespace. (and also allowing separate a multiplatform class in different files, for each one).
>>
>> With modules you are limited in a single file. And it will grow potentially with multiplatform code, and makes hard to find a error or line...
>> Added to it, the amout of version statements.
>>
>> Also Namespaces can use upper case characters... documentation indicates that package and module names should be written all in lower case.
>>
>> A good point for modules is the permisson to access private or protected members of types declared in the same module or package, without the "friend" keyword anywhere.
>> In namespaces, it can be done by sharing access to all namespace types.
>>
>> Really module, packages, and namespaces are the same thing. The unique thing that i want, is the possibility of use many files as one (for modules)
> 
> Modules are compilation units. This makes them different from namespaces.
> 
> Packages are for the compiler to find source code. Namespaces are for humans to find source code. These have sufficient overlap that they have been unified.
> 
> For modules to do what you want, a module cannot be the unit of compilation. What then will be the unit of compilation? And why is this feature important enough to merit the change?

in my opinion a more flexible design is:
namespaces can map both to packages/dirs (as it is now) _and_ files for added flexibility, and compilation units will be files.

I don't think splitting one class/struct/etc to several files is good design, there are better ways to acomplish this, like defining platform specific behaviors as mixins:
template foo_win32 {}
template foo_linux {}
and in the class mix-in the appropriate mixin.
*but*, I do think that splitting one file that got too big over time or uniting a bunch of small files into one should be possible.

On Tue, 05 May 2009 09:50:24 +0400, Yigal Chripun <yigal100@gmail.com> wrote:

> bearophile wrote:
>> Yigal Chripun:
>>> 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)
>>  Generally if classes or functions are small, you put more than one of them (related ones) in the same module.
>
> sure. nothing I said contradicts this. you can have however many constructs in one file. Either make only one of them as public, or put all of them inside a "module" declaration like you do now.
>
>>
>>> Ideally, I'd want at most one public root entity per file.
>>  That's the Java ideal world.
>
> well, the trade-off to consider is:
> on the one hand - if you go for namespaces like solution you get most flexible design. i.e one file with a bunch of small public classes (for example exceptions) will be exactly the same as many small files with one class in each if in both cases you define all those classes to belong to one namespace.
> on the other hand - this removes the ability to know in which file a class is defined.
>
> I think that in such a case it's a reasonable trade off to have:
> module exceptions {
>    class A {}
>    class B {}
>    ...
> }
> where exceptions is the "root" element of the file.
>
> so, exceptions.SomeException can be both a file called exceptions that contains a SomeException class and a exception directory with a file called SomeException that contains that specific class. (also, you can mix both ways, and have only some of the exceptions in separate files).
>
> currently, if I have a file with a bunch of classes, and over time the file became too big and I decided to split it to several smaller files, such a split will affect the code because package.module.classA will become package.module.classA.classA after such a split.
>
>> Bye,
>> bearophile
>
> another idea, is that if you have:
> package
>   |\
>   | exceptions
>   |    \
>   |     classA.d
>   |     classB.d
>   |
> exceptions.d
>
> classA and classB files contain single classes by the same respective names, and exceptions.d contains a bunch of smaller classes in one file.
> in this case the compiler could "fuse" together the paths so logically in the code you'll have package.exceptions.[class_name] where class_name is one of classA, classB or any of the classes defined in exceptions.d
>
> does that sound reasonable? this is as close as possible I can think of to full namespaces without loosing the ability to find where some code is located in the file system.
>
> in this case go to 'package' dir, inside you need to check the exceptions.d file. if desired class isn't in this file you know to go check the 'exceptions' dir, and so forth.

I believe this is reasonable, but I don't think we will convince Walter for a change.
Either way, this idea needs to be out into bugzilla, or it will be lost.