In article <c8343j$15v2$1@digitaldaemon.com>, Hauke Duden says...
>
>Kevin Belaer wrote:
>
>> In article <c82ogd$lf6$1@digitaldaemon.com>, Hauke Duden says...
>> 
>>>I totally agree. I posted about this a while back because I also like to have one class per file. Got no comment from Walter, so I guess he was waiting to see how important this issue is. Thanks for bringing it up again ;).
>>>
>>>IMHO a JAVA-like package attribute is a good solution for this. Not as hackish as C++'s friend stuff and it integrates cleanly with the other access attributes.
>> 
>> 
>> By putting each module in one file, all the code that is able to access a given private member is compiled in the same step.  This means that those members can be rearranged and even eliminated if they are not used.  This level of analysis is probably not available yet; but its a good design.
>
>Even if the code is in different files, unused module members can still be optimized away by the linker, which is where this kind of optimization is usually done. Applies to public members as well, btw.

I think it's common to use the operating system's linker, and rare to modify the linker with specific language optimization features.  The linker looks at .o and a files.  I think the knowledge of structures and members is lost at this point, and everything is done based on pointers, offsets, and labels. But I'm not really up on this; maybe everyone is writing their own linkers now.  C++ needs at least some linker interaction in order to insure auto instantiation of template stuff.

Kevin

>> If you really want seperate files, you could use makefile rules:
>> 
>> bigmodule.d: file1.dp file2.dp file3.dp
>> cat file[123].dp > bigmodule.d
>
>Ewww. I prefer not to hack together my own preprocessor, thank you. The source files should be compilable as they are - generating intermediate files just leads to lots of problems (e.g. during debugging or if you accidentally edit the wrong file, or if people don't have your "preprocessor" or ...)

I agree that its ugly..

>Hauke

> The whole idea of one class per file in Java is not necessarily because it's a better design, but because it's the convention when using Java (it's possible to have more than one class per file in Java actually). We use package protection in Java because that's the mechanism provided. Likewise the friend keyword in C++. D provides the same functionality. If you adjust your train of thought (think in D!) you can accomplish what you need easily without frustration.

I think the main reason for one public class per file in Java is to allow for magically compilation. ie. Given a classpath and a dotted class name, the compiler can find the file where the class lives.

J Anderson wrote:

> Achilleas Margaritis wrote:
> 
>>In the GUI library I am making, I want to have one class per module, so as that the programmer declares 'import bar.foo' with 'foo' being the name of the class;
>>
>>
>>But at the same time, I want class 'Foo' to access the private fields of another class 'T'. This is impossible, because they are in different modules.
>>
>>In other words, I want the analogy of modules to classes to be 1 to 1: it is easier for the programmer (if he remembers the name of the class, then he remembers the name of the module), and it is easier for me, as I keep source files smaller.
>>
>>Maybe D could have a 'package' access attribute which works just like in Java: the declaration can be accessed by anyone on the same module.
>>
>>Another solution would be to introduce the 'friend' access attribute, although parameterized to the type of the class that is friend. I propose the following grammar:
>>
>>FriendAttribute:
>>"friend" "(" IdentifierList ")"
>>
>>Example:
>>class Foo {
>>friend(Bar, Other):
>>int m_data;
>>}
>>
>>I think this is really needed in the language; as it is right now, it would frustrate many developers who would want module names to correspond to class names (and for gui libs, there are lots of classes). Again, this is a small change and easily implementable, but it would save lots of developers from lots of frustration.
>>
>>
>>
>> 
>>
> What about putting all your shared info in a private module, ie:
> 
> module hidden;
> 
> //Hidden data sharing here
> 
> class pA {}
> 
> class pB {}
> 
> module A;
> 
> private import hidden;
> 
> class A : pA {}
> 
> module B;
> 
> private import hidden;
> 
> class B : pB {}
> 
> In other words, I suggest re-thinking your design.
> 


Something like that doesn't stop a programmer using the API from importing hidden.

I really like Ben's idea of:
public (package or module) to expose a field (or class, why not?) to another
package or module.  I would even take it a step further, and say one should
be able to specify a list of packages or modules.

D, however, is not Java, which is really what an idea like this is for/from. The way I understand it, each module should be a separate and distinct entity, and this idea of sharing privates between modules is, for lack of a better word... wrong.  This design methodology doesn't sit well with the Java guys since we like splitting things up into lots and lots of files.

I see two solutions that seems to stay better in line with D design
methodology:
1) Come up with some method of combining files into one module.  I don't
like this one however, since it breaks the idea of one module to one file.
2) Package access for modules.  Make package access keyword that applies to
modules.  This way, programmers can clearly separate their API from the
internal backend, should they choose to put it in separate files (modules.)
Let's face it D guys: sometimes it makes a lot of sense for two modules to
share an internal module.  Not every module can be completely separate-
layered programming, right? (Yeah, I just made up that term)

I wonder what the ratio of Java guys to C/C++ guys involved in D is...

DemmeGod

Sorry if I reworded a lot... I was a manager in a past life.

DemmeGod wrote:

>J Anderson wrote:
>
>  
>
>>Achilleas Margaritis wrote:
>>
>>    
>>
>>>In the GUI library I am making, I want to have one class per module, so as
>>>that the programmer declares 'import bar.foo' with 'foo' being the name of
>>>the class;
>>>
>>>
>>>But at the same time, I want class 'Foo' to access the private fields of
>>>another class 'T'. This is impossible, because they are in different
>>>modules.
>>>
>>>In other words, I want the analogy of modules to classes to be 1 to 1: it
>>>is easier for the programmer (if he remembers the name of the class, then
>>>he remembers the name of the module), and it is easier for me, as I keep
>>>source files smaller.
>>>
>>>Maybe D could have a 'package' access attribute which works just like in
>>>Java: the declaration can be accessed by anyone on the same module.
>>>
>>>Another solution would be to introduce the 'friend' access attribute,
>>>although parameterized to the type of the class that is friend. I propose
>>>the following grammar:
>>>
>>>FriendAttribute:
>>>"friend" "(" IdentifierList ")"
>>>
>>>Example:
>>>class Foo {
>>>friend(Bar, Other):
>>>int m_data;
>>>}
>>>
>>>I think this is really needed in the language; as it is right now, it
>>>would frustrate many developers who would want module names to correspond
>>>to class names (and for gui libs, there are lots of classes). Again, this
>>>is a small change and easily implementable, but it would save lots of
>>>developers from lots of frustration.
>>>
>>>
>>>
>>> 
>>>
>>>      
>>>
>>What about putting all your shared info in a private module, ie:
>>
>>module hidden;
>>
>>//Hidden data sharing here
>>
>>class pA {}
>>
>>class pB {}
>>
>>module A;
>>
>>private import hidden;
>>
>>class A : pA {}
>>
>>module B;
>>
>>private import hidden;
>>
>>class B : pB {}
>>
>>In other words, I suggest re-thinking your design.
>>
>>    
>>
>
>
>Something like that doesn't stop a programmer using the API from importing
>hidden.
>
>  
>
<snip>

There is if you make it a library.

-- 
-Anderson: http://badmama.com.au/~anderson/

J Anderson wrote:

> DemmeGod wrote:
> 
>>J Anderson wrote:
>>
>> 
>>
>>>Achilleas Margaritis wrote:
>>>
>>> 
>>>
>>>>In the GUI library I am making, I want to have one class per module, so as that the programmer declares 'import bar.foo' with 'foo' being the name of the class;
>>>>
>>>>
>>>>But at the same time, I want class 'Foo' to access the private fields of another class 'T'. This is impossible, because they are in different modules.
>>>>
>>>>In other words, I want the analogy of modules to classes to be 1 to 1: it is easier for the programmer (if he remembers the name of the class, then he remembers the name of the module), and it is easier for me, as I keep source files smaller.
>>>>
>>>>Maybe D could have a 'package' access attribute which works just like in Java: the declaration can be accessed by anyone on the same module.
>>>>
>>>>Another solution would be to introduce the 'friend' access attribute, although parameterized to the type of the class that is friend. I propose the following grammar:
>>>>
>>>>FriendAttribute:
>>>>"friend" "(" IdentifierList ")"
>>>>
>>>>Example:
>>>>class Foo {
>>>>friend(Bar, Other):
>>>>int m_data;
>>>>}
>>>>
>>>>I think this is really needed in the language; as it is right now, it would frustrate many developers who would want module names to correspond to class names (and for gui libs, there are lots of classes). Again, this is a small change and easily implementable, but it would save lots of developers from lots of frustration.
>>>>
>>>>
>>>>
>>>> 
>>>>
>>>> 
>>>>
>>>What about putting all your shared info in a private module, ie:
>>>
>>>module hidden;
>>>
>>>//Hidden data sharing here
>>>
>>>class pA {}
>>>
>>>class pB {}
>>>
>>>module A;
>>>
>>>private import hidden;
>>>
>>>class A : pA {}
>>>
>>>module B;
>>>
>>>private import hidden;
>>>
>>>class B : pB {}
>>>
>>>In other words, I suggest re-thinking your design.
>>>
>>> 
>>>
>>
>>
>>Something like that doesn't stop a programmer using the API from importing hidden.
>>
>> 
>>
> <snip>
> 
> There is if you make it a library.
> 

Good point... package access level is only important in programming libs, which is something I spend most of my time doing.  A good library isn't just the stuff you expose, it's also the stuff you don't.  If a library has a lot of it's internal stuff exposed and readily available, the whole library is made more confusing for the user (errr... programmer).

Hauke Duden wrote:

> My whole idea of using one class per file is that I can easily find the file that contains a specific class and that the files do not grow to tens of thousands of lines.
> 
> Sourcecode control systems also work better with many smaller files, since then they don't have to merge that often.
> 
> My reasons for wanting this are simple code maintenance issues. These kinds of things become important for big projects.

From this perspective I will grudgingly agree ;-) I'll admit, in a project I'm currently working on I stumbled into a situation where package level protection would have been real handy. Even so, I'm starting to grow accustomed to the D way. I like cutting down on the number of files.

It seems that right now the concept of a package in D is nothing more than a namespace for modules. The question is, would a keyword for package protection add more utility without causing a breakdown in the intended use of modules? I don't think that's possible. Give us the keyword, and soon D packages will be treated as 'modules', while the original module idea slowly fades away. Considering that the majority of us are coming from C++ and Java, the idea of one class per file is something we've grown accustomed too (for maintenance, readability, desgin paradigms, or whatever reason). If we can do it easily, we will.

> This seems to be an oxymoron to me.  D's modules design tries to help the programmer from making bad design decisions.

Yet I can't have module == class.

> Something like that doesn't stop a programmer using the API from importing hidden.
>
> I really like Ben's idea of:
> public (package or module) to expose a field (or class, why not?) to
another
> package or module.  I would even take it a step further, and say one
should
> be able to specify a list of packages or modules.

I don't care if it is 'friend(identifier-list)' or 'public(identifier-list)'
as long as it does the job.

>
> D, however, is not Java, which is really what an idea like this is
for/from.

I don't think it is important for D not to be Java or to be Java. The most important thing is for D to the best language. The way I see it, there is a chance here for the programming language ever.

> The way I understand it, each module should be a separate and distinct entity, and this idea of sharing privates between modules is, for lack of
a
> better word... wrong.  This design methodology doesn't sit well with the Java guys since we like splitting things up into lots and lots of files.

So if modules sharing privates is wrong, D should allow me to import specific classes then.

"mike parker" <mike@aldacron.com> wrote in message news:c82sm7$r9u$1@digitaldaemon.com...
> Hauke Duden wrote:
> >>
> >> I think this is really needed in the language; as it is right now, it
> >> would
> >> frustrate many developers who would want module names to correspond to
> >> class
> >> names (and for gui libs, there are lots of classes). Again, this is a
> >> small
> >> change and easily implementable, but it would save lots of developers
> >> from lots
> >> of frustration.
>
> I think it's not needed at all. When coding in Java, I don't think in
> C++. D isn't Java, and it isn't C++. When designing a D app, think in D.
>   It's not that hard of an adjustment to get used to using module-levle
> privates in place of package protection and friends.

>
> The whole idea of one class per file in Java is not necessarily because it's a better design, but because it's the convention when using Java (it's possible to have more than one class per file in Java actually). We use package protection in Java because that's the mechanism provided. Likewise the friend keyword in C++. D provides the same functionality. If you adjust your train of thought (think in D!) you can accomplish what you need easily without frustration.

I personally have no problem in adjusting to D, but the end-users of my library will have.

From the end-user perspective(that is, the programmer who uses my library) it will be much easier to have one module per class, because remembering the class name will also help remember the module that should be imported.

The problem is, a GUI library has many many classes: widgets (over 40 classes), layouts (over 10 classes), items (over 5 classes), many helper classes etc. If the user of this library has to remember all these class' names AND module names, it will be diffucult for them...whereas if it was possible to have one module per class, there would be significant advantages:

1) it would be much easier for the programmer, because remembering the class
name will also help remember the module name.
2) it would make management of the project (a huge project) much easier.

So, why to put the burden on the end-user's shoulders, while it can be put on the developer's ? a small change would result in big savings.

> My reasons for wanting this are simple code maintenance issues. These kinds of things become important for big projects.
>
> Hauke

The importance of maintenance can't be overstressed. GUI classes often are made out of thousands of lines of code. For example, Microsoft's ListBox implementation is 11,000 lines. Imagine a source code file with 5 such classes (because they need to know each other's few private members) !!! a nightmare from all perspectives...