Lars Ivar Igesund wrote:

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

The same could be said of goto.  It may be bad design, but sometimes the wrong way really is the right way.  D recognizes this in the case of goto, and maybe it should recognize it in the case of package scope.

 -- andy

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

I have been using a special convention to get around the issue.

public memberSetFoo(float foo)
{
}

I prepend 'member' to sets and gets. I don't have to do it much, but it is ugly.

Saying that, I would prefer a package concept too.

hmm. Maybe there could be another access attribute called that allows access to any module that is in the same directory.

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

It was not my intent to imply anything religious ;) A zealot I'm not. What I'm getting at is that this sort of change is not just a minor feature addition, but really would be a major paradigm shift.

Achilleas Margaritis wrote:
>>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...

Change the private memebers to public and use as many files as you want.

If you think that's a bad design, maybe the design has some other problems that are the REAL root of the issue.

-- 
Justin (a/k/a jcc7)
http://jcc_7.tripod.com/d/

J C Calvarese wrote:
> Achilleas Margaritis wrote:
> 
>>> 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...
> 
> 
> Change the private memebers to public and use as many files as you want.
> 
> If you think that's a bad design, maybe the design has some other problems that are the REAL root of the issue.
> 

What kind of response is that? "Dude, my TV isn't working properly!" "Don't use it then! If it doesn't work then you don't need it, or there's something wrong with you. Can't be the TV."

I probably shouldn't even have answered...


Hauke

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

Does it have to be one of the other?

Can we have two files with 20 lines of code each and then every other file can contain a few hundred lines?

I think this is an issue of personal preference, but I cringe when I'm looking through a set of code and every file I open seems to have about 5 lines of code. I'd prefer to have longer modules if I could have fewer of them.

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

-- 
Justin (a/k/a jcc7)
http://jcc_7.tripod.com/d/

Hauke Duden wrote:

> J C Calvarese wrote:
> 
>> Achilleas Margaritis wrote:
>>
>>>> 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...
>>
>>
>>
>> Change the private memebers to public and use as many files as you want.
>>
>> If you think that's a bad design, maybe the design has some other problems that are the REAL root of the issue.
>>
> 
> What kind of response is that? "Dude, my TV isn't working properly!" "Don't use it then! If it doesn't work then you don't need it, or there's something wrong with you. Can't be the TV."
> 
> I probably shouldn't even have answered...
> 
> 
> Hauke

I'm not saying not to use private. I think private works as it was designed to work. It says, "Don't touch this." If everybody and his brother has access to it, it's should be called "public".

I'm wondering if his designs might be better off if they used fewer private members. If all of the maze of interconnected classes need access to something, perhaps it should be public.

I can't see what the problem is. Perhaps more detailed code samples will make his point more clear. I'm afraid that he wants to program Java in D when it would be better to program D in D. D is designed to be different than C++ and Java. Let's not be afraid to do things differently. Sometimes "different is better".

Maybe we do need a protected, supermodule, friend, directory or some other new keyword, but I think we need to check to see if we have a need before we take that step.

-- 
Justin (a/k/a jcc7)
http://jcc_7.tripod.com/d/

Achilleas Margaritis wrote:

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

Not specific classes, but modules.  You should be able to have private (or package, whatever) modules, which can only be imported by modules in the same package.  This way, shared privates are clearly separated from the public stuff, or non-shared privates.  I'm not saying that it seems to be perfectly inline with D design methodology, but it's closer to it than package-level access at the class or field level.

J C Calvarese wrote:
> Hauke Duden wrote:
> 
>> J C Calvarese wrote:
>>
>>> Achilleas Margaritis wrote:
>>>
>>>>> 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...
>>>
>>>
>>>
>>>
>>> Change the private memebers to public and use as many files as you want.
>>>
>>> If you think that's a bad design, maybe the design has some other problems that are the REAL root of the issue.
>>>
>>
>> What kind of response is that? "Dude, my TV isn't working properly!" "Don't use it then! If it doesn't work then you don't need it, or there's something wrong with you. Can't be the TV."
>>
>> I probably shouldn't even have answered...
>>
>>
>> Hauke
> 
> 
> I'm not saying not to use private. I think private works as it was designed to work. It says, "Don't touch this." If everybody and his brother has access to it, it's should be called "public".
> 
> I'm wondering if his designs might be better off if they used fewer private members. If all of the maze of interconnected classes need access to something, perhaps it should be public.

I don't think you understand the issue. It is often the case that you want to provide a certain functionality and that functionality is decomposed into multiple classes. These classes may need to cooperate to achieve the goal, but you do not want the mechanisms used for the cooperation to be accessible by anyone else.

That's where "package", "friends" or whatever you call it comes into play. It means "public, but only for my own team". In D this means that all classes of the same "team" have to be in the same module. So far so good, nothing wrong with that. But since a module is always a single file it means that these classes also have to be in the same file. And THIS can be a real problem when they reach a certain size.

For example, it may very well be that you write a bunch of GUI classes which need to cooperate with some kind of window system. As said before, maybe you don't want these cooperation mechanism to be accessible by anything but the window system and the GUI classes. So with the current situation you'd have to put a good sized chunk of the library into one single file. We're talking about tens of thousands, maybe even hundreds of thousands of lines of code here. It would be impossible to have multiple programmers work on the library without regular merging nightmares.

There may always be some way to avoid putting too much code into a single file, like creating "proxy classes" with all the cooperation stuff. But this kind of thing limits the freedom of the software designer. And worst of all, the problem isn't even a language concept (every language limits the design in some way) but merely the mapping of a language concept to a physical entity (i.e. the mapping of module=file). This kind of thing is totally unnecessary.


Hauke

Hauke Duden wrote:

> J C Calvarese wrote:
>> Hauke Duden wrote:
>> 
>>> J C Calvarese wrote:
>>>
>>>> Achilleas Margaritis wrote:
>>>>
>>>>>> 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...
>>>>
>>>>
>>>>
>>>>
>>>> Change the private memebers to public and use as many files as you want.
>>>>
>>>> If you think that's a bad design, maybe the design has some other problems that are the REAL root of the issue.
>>>>
>>>
>>> What kind of response is that? "Dude, my TV isn't working properly!" "Don't use it then! If it doesn't work then you don't need it, or there's something wrong with you. Can't be the TV."
>>>
>>> I probably shouldn't even have answered...
>>>
>>>
>>> Hauke
>> 
>> 
>> I'm not saying not to use private. I think private works as it was designed to work. It says, "Don't touch this." If everybody and his brother has access to it, it's should be called "public".
>> 
>> I'm wondering if his designs might be better off if they used fewer private members. If all of the maze of interconnected classes need access to something, perhaps it should be public.
> 
> I don't think you understand the issue. It is often the case that you want to provide a certain functionality and that functionality is decomposed into multiple classes. These classes may need to cooperate to achieve the goal, but you do not want the mechanisms used for the cooperation to be accessible by anyone else.
> 
> That's where "package", "friends" or whatever you call it comes into play. It means "public, but only for my own team". In D this means that all classes of the same "team" have to be in the same module. So far so good, nothing wrong with that. But since a module is always a single file it means that these classes also have to be in the same file. And THIS can be a real problem when they reach a certain size.
> 
> For example, it may very well be that you write a bunch of GUI classes which need to cooperate with some kind of window system. As said before, maybe you don't want these cooperation mechanism to be accessible by anything but the window system and the GUI classes. So with the current situation you'd have to put a good sized chunk of the library into one single file. We're talking about tens of thousands, maybe even hundreds of thousands of lines of code here. It would be impossible to have multiple programmers work on the library without regular merging nightmares.
> 
> There may always be some way to avoid putting too much code into a single file, like creating "proxy classes" with all the cooperation stuff. But this kind of thing limits the freedom of the software designer. And worst of all, the problem isn't even a language concept (every language limits the design in some way) but merely the mapping of a language concept to a physical entity (i.e. the mapping of module=file). This kind of thing is totally unnecessary.
> 
> 
> Hauke

So I wonder if Walter is going to grace us with his take on this?