On Thu, 12 May 2005 14:04:56 +0900, Mike Parker wrote:


[snip]
> I just down see the usefulness of it, and would very much prefer things to stay the way they are.

I too think that the current semantics should remain. But in addition to that, is there any valid argument to allow the other paradigm to be utilized by a coder? In other words, what's so wrong with allowing a coder to create a strictly 'private' module in which the contained classes cannot see it's neighbors private areas?

Is it a bad idea to enable D to allow coders the choice of paradigms?

-- 
Derek
Melbourne, Australia
12/05/2005 3:10:58 PM

>I'm talking about implicit friendship among classes that are in the same module. what you talking about? dude ...

Some languages use keywords, this language uses modules for "friendship". Both is explicit. The language can't implicitly move two classes into one module. You allways have to manually place the classes into modules.

Matthias Becker wrote:
>>I'm talking about implicit friendship among classes that are in the same module. what you talking about? dude ...
> 
> 
> Some languages use keywords, this language uses modules for "friendship". Both
> is explicit. The language can't implicitly move two classes into one module. You
> allways have to manually place the classes into modules.
> 
> 
> 

ok ... um, there is no need to go philosophical, hehe, this is rediclious.
Friendship /_*IS*_/ implicit.

quote: http://www.digitalmars.com/d/cpptod.html#friends
The D Way
In D, friend access is implicit in being a member of the same module.
/quote

Of course the programmer has to do something to trigger this "implication", but it's still implicit.

in C++, you can do something like:
code:
long x = ...
short e = ....

..

e = x;
/code
here, there is an implicit conversion form long to short.
one can argue that it's not implicit because the coder explicitly said that he wants to assign a long value to a short variable, but that is just BS, the conversion here happens implicitly, becuase the coder didn't explicitly state that he wants to convert a long to a short.

Java doesn't allow you to do that, you have to explicitly cast x to short.

I hate philosophy.

This kind of argument can never end, so please stop it.

I totally agree on this - in same file naturally all classes should have access to private parts of each other.

-- 
...........
Dejan Lekic
  http://dejan.lekic.org

> I too think that the current semantics should remain. But in addition to
> that, is there any valid argument to allow the other paradigm to be
> utilized by a coder? In other words, what's so wrong with allowing a coder
> to create a strictly 'private' module in which the contained classes cannot
> see it's neighbors private areas?
> 
> Is it a bad idea to enable D to allow coders the choice of paradigms? 
> 
I have no objection to supporting both ideas. Distinguishing between 'private' and 'module' protection is fine. I just wouldn't want to see the current behavior removed altogether.

Derek Parnell wrote:
> This is *not* rhetorical:
> 
> Is there any valid reason why anyone would need, or want, to place multiple
> classes in the same file and ensure that those classes cannot see each
> other's private information?

Here are my reasons:

[1]. By default, a class should not be able to see the data in another class (strict OOP says a class should encapsulate its data).

[2]. A programmer should not have the inconvenience of being allowed only one class in each file just so that they can enforce rule [1].

For example, I put several related classes into one file for convenience, and then suffer strict-OOP guilt, because my classes are not encapsulated from each other.

So I'm in favour of an explicit 'package' or 'module' access specifier. But I imagine Walter would be against it, because it makes it harder to throw together 'quick and dirty' apps.

James McComb

James McComb wrote:

> So I'm in favour of an explicit 'package' or 'module' access specifier. But I imagine Walter would be against it, because it makes it harder to throw together 'quick and dirty' apps.

Why would they use access protection if they're quick and dirty?

Burton Radons wrote:
> James McComb wrote:
> 
>> So I'm in favour of an explicit 'package' or 'module' access specifier. But I imagine Walter would be against it, because it makes it harder to throw together 'quick and dirty' apps.
> 
> 
> Why would they use access protection if they're quick and dirty?

Quite right, I must have been confused. They'd just leave the access specifiers off altogether.

James McComb