In article <dl0ks3$2dae$1@digitaldaemon.com>, Ivan Senji says...
>
>Tomás Rossi wrote:
>> In article <dkvsqj$1ndm$1@digitaldaemon.com>, Ivan Senji says...
>> 
>>>Tomás Rossi wrote:
>>>
>>>>In article <dkvjhk$1dtg$1@digitaldaemon.com>, Ivan Senji says...
>>>>
>>>>>as opShl_r is defined in SimpleStack it has access to SimpleStack's private parts.
>>>>>
>>>>>Hope this helps in this neverending discussion :)
>>>>
>>>>
>>>>Ok, this beats specifically the << operator overloading example, but there could be another similar example that doesn't use an operator and instead use just a member function. I'll think about it and post it (if I found one).  I doubt this specific example will puff out this nice discussion :)
>>>>
>>>>Tom
>>>
>>>Other than this what would be the case where you wish to grant some other (possibly library) class access to your classes private parts? I think that one can adjust to this /limitation/ in D. I don't even think it is a limitation, in most cases i wish my classes have friendship relationship and it is easy to accomplish that (put them in the same module).
>> 
>> 
>> I still think it looks very dirty to allow other classes from the same module to touch private members of each others
>
>In a strict OO sense friendship is allways dirty.
>
>> (IMHO this could be a nice feature but not
>> to be the default behavior, maybe it should have a keyword behind it). What
>> about all the nice contract programming features? PRE/POST-conditions and
>> invariants? (just asking). I feel that this permissive behavior goes one step
>> back just after going a step forward with contract programming. If it's ugly to
>> break the invariant of a class inside it, imagine breaking it from the outside.
>> I sincerely distrust of the feature.
>> 
>> Quote: "in most cases i wish my classes have friendship relationship and it is
>> easy to accomplish that".
>> Yeah it's nice, but it'd be nicer if you could have more control of this in a
>> more detailed way (e.g. adding more attributes or modifiers if it is necessary).
>> I'm not saying this in-module-friendship is bad, just wish it to be optional to
>> avoid the "paradox" it is (IMO) with respect to contract programming philosophy
>> (not being to much of a scientist here, this is just what I perceive :) ). One
>> advantage of friend keyword approach (e.g. C++) is that with it, you can control
>> exactly WHO would you let to put their hands on the most intimate members of
>> your object.
>> 
>> 
>>>On the other topic i am starting to think that it would be nice to be able to split modules into more files. C# can now even split classes into more files but it is another discussion.
>> 
>> 
>> PS: stop with the "if you don't want any other entity to gain access to your class privates, put it on another module!", THE WORLD ISN'T JUST BLACK OR WHITE.
>> 
>
>I think the problem here is (i had it too when i started with D) that
>you are trying/wanting to write C++, but this is another language and
>there are different ways to do things. The philosophy here is: make
>simple things simple and the D way gives you full control.
>If you want to have friend classes in D you have to put them in the same
>model. The rule in C++ is different: if you want firendsip use the
>friendship keyword.
>
>The D way is a little bit more limiting in that you can't make someone elses (or library) classes your firends but that would IMO be a bad design decision anyway.
>
>D makes you stick to the OO paradigm when using other peoples classes (wich is ok), but also allows you to cheat OO in your code (also ok).
>
>So your code in one module has default friendship, and doesn't it make
>sense? It is after all a group of related classes that are placed in one
>module.
>And if you really really don't want any other entity to gain access to
>your class privates, put it on another module. :) HM, this sentence
>sounds familiar ;)

Not again! :D

>Conclusion: Give The-D-Way a chance, it might make sense to you in a while.

Ok, I'll try. It'll be hard to accept it... after all, having some keywords to do what I ask is just a proposal... in the future it could be taken in account :)

Tom

Ivan Senji wrote:
> C# can now even split classes into more files but it is another discussion.
You can do that too in D with mixins.

-- 
Bruno Medeiros - CS/E student
"Certain aspects of D are a pathway to many abilities some consider to be... unnatural."

Jari-Matti Mäkelä wrote:
> Regan Heath wrote:
>
>> So, does Java have something like "friend" in C++? Does a class ever
>> gain  access to another classes 'private' data? If so, how? If not,
>> why has it  never been required? (as it was in C++? debatable?)
>
>
> Yes, all classes in the same package (Java package = D module) share
> their private data. This is no problem (unless you run out of inodes ;))
> since all non-friendly classes can be split into separate packages.
No. Modules in Java are the top-level classes in each source file, of which there is allways exactly one in each source file.  Furthermore, "all classes in the same package" do not share private data. 'private' restricts acess to the class-scope only.


Jari-Matti Mäkelä wrote:
> Regan Heath wrote:
> 
> Java does have a similar system using packages. You can declare a top-level class as public/package (no keyword). 

> Only one public class
> per package (module) is allowed, other classes must be "hidden" so that they're not polluting the namespace when the package is imported. 
No, there can be several public classes in a Java package (obviously) and in a Java module too (the public top-level class and public inner classes for example)

> Therefore only public classes are accessible from other modules. You need to explicitely write the "package foobar" line inside the source to use packages.
> 
No, to use other modules (or packages, since you can import a whole package) you use the 'import' statement. The 'package' statement in Java defines which package the module is part of (analagous to D's 'module' statement)


-- 
Bruno Medeiros - CS/E student
"Certain aspects of D are a pathway to many abilities some consider to be... unnatural."

Bruno Medeiros wrote:
> Jari-Matti Mäkelä wrote:
>  > Regan Heath wrote:
>  >
>  >> So, does Java have something like "friend" in C++? Does a class ever
>  >> gain  access to another classes 'private' data? If so, how? If not,
>  >> why has it  never been required? (as it was in C++? debatable?)
>  >
>  >
>  > Yes, all classes in the same package (Java package = D module) share
>  > their private data. This is no problem (unless you run out of inodes ;))
>  > since all non-friendly classes can be split into separate packages.
> No. Modules in Java are the top-level classes in each source file, of which there is allways exactly one in each source file.  Furthermore, "all classes in the same package" do not share private data. 'private' restricts acess to the class-scope only.

Sorry, I meant that all classes in the same file share their private data. I know the private inner classes are an exception to this, but tried to keep things simple.

> 
> 
> Jari-Matti Mäkelä wrote:
> 
>> Regan Heath wrote:
>>
>> Java does have a similar system using packages. You can declare a top-level class as public/package (no keyword). 
> 
> 
>  > Only one public class
> 
>> per package (module) is allowed, other classes must be "hidden" so that they're not polluting the namespace when the package is imported. 
> 
> No, there can be several public classes in a Java package (obviously) and in a Java module too (the public top-level class and public inner classes for example)

Oh my, I though I was writing about files but somehow typed that darn package there again. Again, inner classes are an exception, but I wanted to stay in top-level classes since we had different opinions on that particular level. That's it, gotta stop posting in the middle of the night :/

> 
>> Therefore only public classes are accessible from other modules. You need to explicitely write the "package foobar" line inside the source to use packages.
>>
> No, to use other modules (or packages, since you can import a whole package) you use the 'import' statement. The 'package' statement in Java defines which package the module is part of (analagous to D's 'module' statement)

Yes, you're right. I'm not that sure what I actually meant but I think it had something to do with implicit compiler logic. At least Sun javac requires you to explicitely define the name of the package in the source file. Otherwise it complains "file does not contain class foo.bar". D does not require you to do this, right? The other thing is that unless you explicitely define the package, javac treats all those files in that directory as if they were in the same module. At least that's how I see it since you're able to access all private members of other top-level classes then.

What I said about public classes is completely true. If the .java-file is called a module, you really can't access the non-public classes from other modules. (Actually you can access non-static inner classes using their public superclass/interface, but that's another story.)

Derek Parnell wrote:

> In other words, currently if I change a "private" member's data type
> I should also scan the other classes in the module, and module level code, to see if my change upsets them.

That is unacceptable!

> I think that the module concept as an encapsulating entity is a neat idea too.

True. But exposing parts of a class to the "outside", should always have to be explicit!

What was it that Walter once wrote? Someting like: In D, doing the right thing should be natural, but as a pragmatic language D doesn't restrict the programmer unduely. Or something like it anyway.

---

If we had class, module, and descendant visibility in an unsurprising way, then D would be much easier to learn. And there'd be less errors.

Tomás Rossi wrote:
> It's still a little shocking to me and hard to accept the fact that D
> took away the class encapsulation capabilities and transfer them to
> the module. I know it'd be a lot more neat to make an attribute that
> limits a class to interfere with another class in the same module. I
> know that some day i'll find an example where i'll show that this
> requirement is needed :)

I definitely think we should have both.

In some projects I can see modules used as a way of grouping many related small classes. I should be able to choose which methods and attributes I want private, visible to the module, or the world.

I can see no benefit in only having either class or module visibility, without the other.

It's like saying we can have a language either with integers or with reals, but not both.

---

Hell, these requirements change even during the lifetime of a program, from early versions to later and larger versions.

In large scale software development, one does not want to put every single little class in its own file just to be sure you can enforce encapsulation.

On the other hand, friendliness between classes is a must in certain situations (especially with a Pragmatic Language), and in those situations it would be very useful to implement it with module encapsulation.

---

So, choise in granularity, please.

On Fri, 11 Nov 2005 21:16:52 +0200, Georg Wrede wrote:

> Derek Parnell wrote:
> 
>> In other words, currently if I change a "private" member's data type I should also scan the other classes in the module, and module level code, to see if my change upsets them.
> 
> That is unacceptable!

Yes it is.

>> I think that the module concept as an encapsulating entity is a neat idea too.
> 
> True. But exposing parts of a class to the "outside", should always have to be explicit!

Very true. Its similar to the default "public" import issue.

> What was it that Walter once wrote? Someting like: In D, doing the right thing should be natural, but as a pragmatic language D doesn't restrict the programmer unduely. Or something like it anyway.
> 
> ---
> 
> If we had class, module, and descendant visibility in an unsurprising way, then D would be much easier to learn. And there'd be less errors.

Amen, brother! Couldn't agree more.

-- 
Derek Parnell
Melbourne, Australia
12/11/2005 7:25:56 AM

In article <dbke8a2orfcb.msjstcpt7tb5.dlg@40tude.net>, Derek Parnell says...
>
>On Fri, 11 Nov 2005 21:16:52 +0200, Georg Wrede wrote:
>
>> Derek Parnell wrote:
>> 
>>> In other words, currently if I change a "private" member's data type I should also scan the other classes in the module, and module level code, to see if my change upsets them.
>> 
>> That is unacceptable!
>
>Yes it is.

We are three.

>>> I think that the module concept as an encapsulating entity is a neat idea too.
>> 
>> True. But exposing parts of a class to the "outside", should always have to be explicit!
>
>Very true. Its similar to the default "public" import issue.

We should establish a political party, having the same ideals :P

>> What was it that Walter once wrote? Someting like: In D, doing the right thing should be natural, but as a pragmatic language D doesn't restrict the programmer unduely. Or something like it anyway.
>> 
>> ---
>> 
>> If we had class, module, and descendant visibility in an unsurprising way, then D would be much easier to learn. And there'd be less errors.
>
>Amen, brother! Couldn't agree more.

At last! I was feeling a little lonely here defending my point. I was unfairly called a C++ programmer trying to desing in C++ and write in D (:-D maybe there is a little true in that but that's because C++ respect class independency)... but I'm sure D shouldn´t commit such a crime against class independency (at least not by default). For many time classes were total independent encapsulating objects and it were nice, we all liked it that way. Taking their nice encapsulation capabilities isn't a good idea.

Regards and dont let me fight alone again for so many time! :P

Tom

Derek Parnell wrote:
> On Fri, 11 Nov 2005 21:16:52 +0200, Georg Wrede wrote:
> 
> 
>>Derek Parnell wrote:
>>
>>
>>>In other words, currently if I change a "private" member's data type
>>>I should also scan the other classes in the module, and module level code, to see if my change upsets them.
>>
>>That is unacceptable!
> 
> 
> Yes it is.
> 
> 

I agree. However, if there should be a protection attribute that restricts access to the enclosing scope only (and I suppose we are also agreeing that there should be one), then that should be "private" and not something else, like "local".


-- 
Bruno Medeiros - CS/E student
"Certain aspects of D are a pathway to many abilities some consider to be... unnatural."

In article <dl50tq$2uss$1@digitaldaemon.com>, Bruno Medeiros says...
>
>Derek Parnell wrote:
>> On Fri, 11 Nov 2005 21:16:52 +0200, Georg Wrede wrote:
>> 
>> 
>>>Derek Parnell wrote:
>>>
>>>
>>>>In other words, currently if I change a "private" member's data type I should also scan the other classes in the module, and module level code, to see if my change upsets them.
>>>
>>>That is unacceptable!
>> 
>> 
>> Yes it is.
>> 
>> 
>
>I agree. However, if there should be a protection attribute that restricts access to the enclosing scope only (and I suppose we are also agreeing that there should be one), then that should be "private" and not something else, like "local".

Before enthusiastically proposing keywords, the majority should agree in that something has to be done to accomplish this enhancement. Besides, it is clear (as Regan posted it before) that one single keyword isn't enough. Must be three of them (I think) or a modifier for either of the three existing attributes (pitifully modifiers are ugly and introduces some complexity to the language -I believe-).

Something it's clear, this must be a serious proposal so Walter can take it into account.

Tom