On 2013-01-19 03:50, Andrey wrote:

> I haven't seen such situations yet. According to OOP concept they must
> be very rare, so I tend to consider them more of architecture and logic
> mistake (and C++ is one big architecture and logic frankenstein).

In theory and according to the OOP concept they might not be needed but when it comes to actually implement a OO concept it can turn out to be handy to have. That is, accessing a private member in the same module.

-- 
/Jacob Carlborg

Am 19.01.2013 16:26, schrieb Jacob Carlborg:
> On 2013-01-19 03:50, Andrey wrote:
>
>> I haven't seen such situations yet. According to OOP concept they must
>> be very rare, so I tend to consider them more of architecture and logic
>> mistake (and C++ is one big architecture and logic frankenstein).
>
> In theory and according to the OOP concept they might not be needed but
> when it comes to actually implement a OO concept it can turn out to be
> handy to have. That is, accessing a private member in the same module.
>

I do use it a lot when doing unit tests that check for side effects in the private data (JVM/.NET) of objects.

> In theory and according to the OOP concept they might not be needed but when it comes to actually implement a OO concept it can turn out to be handy to have. That is, accessing a private member in the same module.

Allright. But I don't see a reason why this coudln't be done with nested classes. If some class wants frequently to access parent's members, then it preferably demands constant reference to it and therefore need to be presented as inner class. Then we can better and more intelligently track the existence and cooperation of both classes.

And, as it was said, there is no actual encapsulation unless you have organized runtime access checks to the memory chunk occupied by an object. Maybe the creators of D can implement this using contract programming or other things, I do not know. But this can be really a huge step towards safety. The real effect may be seen if the whole OS is written in object oriented manner, and its processes and services have the built-in hierarchical access policy. Such architecture makes possible natural cooperation between various core modules, processes and the user space. Maybe even existence in one address space without the need of slow artificial system calls.

If someone wants to continue discussing OOP, then I suggest to move to another thread to stop polluting this topic. Although I think that there are enough debates around OOP in the Internet already and yet another one will not make difference.

On 1/19/2013 5:57 AM, Andrei Alexandrescu wrote:
> On 1/19/13 8:21 AM, Maxim Fomin wrote:
>> How much chances does this program have?
>> ----------mylib.di--------
>> class A
>> {
>> public int i;
>> }
>>
>> void foo(A a);
>> ---------mylib.d---------
>> class A
>> {
>> public int i;
>> private int ii;
>> }
>
> Looks like an ODR violation, but oddly there's nothing stopping us from making
> this work. It's a good idea to pursue.

It can only work if the user is very well aware of how classes are laid out, avoids things that depend on the instance size, etc.

On Saturday, 19 January 2013 at 11:52:52 UTC, Russel Winder wrote:
> On Fri, 2013-01-18 at 21:21 +0100, bearophile wrote:
> […]
> (*) Groovy managed to use a 6 year rather than 10 cycle to real
> usability, but it was only when SpringSource bought G2One and started
> putting resource into Groovy that it really took off. With Canoo backing
> it and one or two USA consultancies, it rapidly became the dynamic
> language of choice and actual use on the JVM.  The similarities between
> D evolution and Groovy evolution are quite interesting (**). Groovy has
> made the jump to organizational respectability. D needs to do the same.
>

This opinionated piece of opinion agrees:

"What about D as a replacement for C?

It's not there for the same reasons as Go. It's possible that someday it will be suitable, but I'm less optimistic about it strictly from a momentum perspective, it doesn't have a big backer like Google and doesn't seem to be growing very rapidly. But perhaps it will get there someday."

http://damienkatz.net/2013/01/follow_up_to_the_unreasonable.html

On 1/19/13 1:36 PM, Walter Bright wrote:
> On 1/19/2013 5:57 AM, Andrei Alexandrescu wrote:
>> On 1/19/13 8:21 AM, Maxim Fomin wrote:
>>> How much chances does this program have?
>>> ----------mylib.di--------
>>> class A
>>> {
>>> public int i;
>>> }
>>>
>>> void foo(A a);
>>> ---------mylib.d---------
>>> class A
>>> {
>>> public int i;
>>> private int ii;
>>> }
>>
>> Looks like an ODR violation, but oddly there's nothing stopping us
>> from making
>> this work. It's a good idea to pursue.
>
> It can only work if the user is very well aware of how classes are laid
> out, avoids things that depend on the instance size, etc.

Well I'm thinking of scenarios in which the implementation file imports and verifies the incomplete declaration file.

Andrei

On Saturday, 19 January 2013 at 18:43:45 UTC, SomeDude wrote:
> On Saturday, 19 January 2013 at 11:52:52 UTC, Russel Winder wrote:
>> On Fri, 2013-01-18 at 21:21 +0100, bearophile wrote:
>> […]
>> (*) Groovy managed to use a 6 year rather than 10 cycle to real
>> usability, but it was only when SpringSource bought G2One and started
>> putting resource into Groovy that it really took off. With Canoo backing
>> it and one or two USA consultancies, it rapidly became the dynamic
>> language of choice and actual use on the JVM.  The similarities between
>> D evolution and Groovy evolution are quite interesting (**). Groovy has
>> made the jump to organizational respectability. D needs to do the same.
>>

Yes. I remember looking at Groovy around 2000 timeframe and not giving
too much consideration.

Back then Jacl had much more support, and IBM was pushing Beanshell and
Jacl.

Funny how it turned out to be.

>
> This opinionated piece of opinion agrees:
>
> "What about D as a replacement for C?
>
> It's not there for the same reasons as Go. It's possible that someday it will be suitable, but I'm less optimistic about it strictly from a momentum perspective, it doesn't have a big backer like Google and doesn't seem to be growing very rapidly. But perhaps it will get there someday."
>
> http://damienkatz.net/2013/01/follow_up_to_the_unreasonable.html

Go might eventually succeed in replacing C, Google just needs to make Go a first class language for Android development.

--
Paulo

On Monday, 21 January 2013 at 08:34:49 UTC, Paulo Pinto wrote:
> Go might eventually succeed in replacing C, Google just needs to make Go a first class language for Android development.
>

Go has no chance to replace C as too many low level features are missing. But yes, it can become pretty big !

On Mon, 2013-01-21 at 09:34 +0100, Paulo Pinto wrote:
[…]
> Yes. I remember looking at Groovy around 2000 timeframe and not
> giving
> too much consideration.
[…]

Just to ensure the history as determined by Google search is at least fairly reasonable, Groovy started in mid to late 2003 had a hiccup mid 2004, and really got moving in late 2004.

-- 
Russel. ============================================================================= Dr Russel Winder      t: +44 20 7585 2200   voip: sip:russel.winder@ekiga.net 41 Buckmaster Road    m: +44 7770 465 077   xmpp: russel@winder.org.uk London SW11 1EN, UK   w: www.russel.org.uk  skype: russel_winder

On Friday, 18 January 2013 at 22:29:45 UTC, Walter Bright wrote:
> On 1/18/2013 2:16 PM, Andrey wrote:
>
> This is by design, not a bug. All code in a module has access to all private members in that same module. This obviates the need for the C++ "friend" declarations.

Yes, but that is a bad choice. The simplest argument against it it is that it is a departure of C++. Yes, you've made "private" like Java (package), but that's not the first intended audience.

If you cannot go back with private acting like C++ private, then at least introduce an "internal" specifier for things that truly belongs to the class only (ie: the C++ private).

You could have:

internal
private
package
protected
public
export

or

private
semiprivate // well? better ideas?
package
protected
public
export

Why make access protection dependent of how the source code is spread into files?