> 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.

I don't think programming languages should be treated like religion. If something does not fit the purpose, it should be changed.

Walter originally thought "one module contains everything it needs". I totally agree with that.

The problem is that a module is not equal to a file. Why does it have to be ? a module is nothing more than a collection of code and data that are closely related...(also a property of classes, by the way). But why should all the code reside in one file ? there is no real reason. In fact, there are many reasons why module code should be in different files...and maintenance/source control is one of them, and a very important one, at least for software companies.

To give you a real-world example: the Linux kernel is thousands of lines of code, in hundrends of files, and many files contain nothing more than one declaration or two. Do you think this is by accident ? it is not. In fact, it is easier to maintain the kernel that way.

Imagine if the Linux kernel would be made in D: tens of files, each one with thousands of lines of code...a real source control nightmare.

I think this is a major problem for D and it needs to be addressed as soon as possible. I am sure Walter has big plans for D (i.e. to be used in big and serious projects).

"Achilleas Margaritis" <axilmar@b-online.gr> wrote in message news:c84ppl$kg5$1@digitaldaemon.com...
> > 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.
>
>
>
Why dont you just name the module the same name as the class and import the module.

> 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.
>

Why dont you use public get and set methods, and
access the private fields from these methods?

Hmnnnn I must be wrong, this is just too obvious a solution.

mike parker wrote:
> 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.

Another (very simple) solution would be to allow a module to be a directory. The module import mechanism could then be just as it is, "friends" could be handled the same way and the file layout would nevertheless be in the hands of the programmer.

A super-simple way to do this would be to modify the module importing algorithms like this:

- searching for module A
- if there is a file A.d import that
- if there is no file A.d search for a directory A.dmodule
- if there is a directory A.dmodule import all .d files in it.
- if there is no directory A.dmodule then the module is not found.


Hauke

"Achilleas Margaritis" <axilmar@b-online.gr> wrote in message news:c84rni$mtv$1@digitaldaemon.com...
> > 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.
>
> I don't think programming languages should be treated like religion. If something does not fit the purpose, it should be changed.
>
> Walter originally thought "one module contains everything it needs". I totally agree with that.
>
> The problem is that a module is not equal to a file. Why does it have to
be
> ? a module is nothing more than a collection of code and data that are closely related...(also a property of classes, by the way). But why should all the code reside in one file ? there is no real reason. In fact, there are many reasons why module code should be in different files...and maintenance/source control is one of them, and a very important one, at least for software companies.
>
> To give you a real-world example: the Linux kernel is thousands of lines
of
> code, in hundrends of files, and many files contain nothing more than one declaration or two. Do you think this is by accident ? it is not. In fact, it is easier to maintain the kernel that way.
>
> Imagine if the Linux kernel would be made in D: tens of files, each one
with
> thousands of lines of code...a real source control nightmare.
>
> I think this is a major problem for D and it needs to be addressed as soon

It is up to the developer how small he breaks down his
problem and therefore how small he makes his modules.
You dont need to have large modules anymore than
you have to have large methods.
In Java you can have one class per file or one thousand
classes(or more) per file. Same as D.

Its all up to you!

Achilleas Margaritis wrote:

> 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...

The need to access private members usually imply bad design. The need to access protected members might be well founded, especially where MI isn't possible (like D).

Lars Ivar Igesund

On Sat, 15 May 2004 20:57:59 +1000, Phill wrote:

>> 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.
>>
> 
> Why dont you use public get and set methods, and
> access the private fields from these methods?
> 
> Hmnnnn I must be wrong, this is just too obvious a solution.

This is how I would be addressing the situation too.

I mentioned in another thread that I choose not to have public data elements, instead they are made private and I have public methods to access them. In D's case this could be the get/set property system.

-- 
Derek
Melbourne, Australia

On Sat, 15 May 2004 13:34:25 +0300, Achilleas Margaritis wrote:

>> 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.
> 
> I don't think programming languages should be treated like religion. If something does not fit the purpose, it should be changed.

Agreed.

> Walter originally thought "one module contains everything it needs". I totally agree with that.

Me too.

> The problem is that a module is not equal to a file. Why does it have to be ? a module is nothing more than a collection of code and data that are closely related...(also a property of classes, by the way). But why should all the code reside in one file ? there is no real reason. In fact, there are many reasons why module code should be in different files...and maintenance/source control is one of them, and a very important one, at least for software companies.

I agree here too. The 'module' is a concept and the 'file' is a physical. To make files be a metaphor for modules is artifical. A module is a collection of related code and data. A file is just a device to contain source code. There is no essential reason that a module must be constrained to a single file. This is just a design decision b Walter. Hopefully it has merit in most cases, but I think the argument concerning source code control systems might need further investigating.

> To give you a real-world example: the Linux kernel is thousands of lines of code, in hundrends of files, and many files contain nothing more than one declaration or two. Do you think this is by accident ? it is not. In fact, it is easier to maintain the kernel that way.
> 
> Imagine if the Linux kernel would be made in D: tens of files, each one with thousands of lines of code...a real source control nightmare.
> 
> I think this is a major problem for D and it needs to be addressed as soon as possible. I am sure Walter has big plans for D (i.e. to be used in big and serious projects).

I can't see much merit in a module needing to have unrestricted access to private data elements contained in other modules. This just sounds like a bug or two waiting to happen. It is generally accepted that modules need to be as decoupled as possible to achieve quality systems.

-- 
Derek
Melbourne, Australia

Derek wrote:

>On Sat, 15 May 2004 20:57:59 +1000, Phill wrote:
>
>  
>
>>>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.
>>>
>>>      
>>>
>>Why dont you use public get and set methods, and
>>access the private fields from these methods?
>>
>>Hmnnnn I must be wrong, this is just too obvious a
>>solution.
>>    
>>
>
>This is how I would be addressing the situation too. 
>
>I mentioned in another thread that I choose not to have public data
>elements, instead they are made private and I have public methods to access
>them. In D's case this could be the get/set property system.
>
>  
>
One thing I like about D is that you don't need to write the getter/setter until you need them.  You can happily create a public property and then change it to a getter/setter latter.  This is the ideal way of doing things.  Get/Sets were nessary in C++ and java because they didn't have that ability.

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

Achilleas Margaritis wrote:

>>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.
>
>  
>

You can. Only if your sharing information between these classes is it *wrong* to expect these classes not to be visible.    Its *wrong* to treat a module as a class.  The idea is to try to reduce coupling, not create it.  Its hard to explain but once you get the concept you'll thank us later.

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