View mode: basic / threaded / horizontal-split · Log in · Help
January 19, 2013
Re: Focus
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
January 19, 2013
Re: Focus
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.
January 19, 2013
Re: Focus
> 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.
January 19, 2013
Re: Focus
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.
January 19, 2013
Re: Focus
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
January 20, 2013
Re: Focus
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
January 21, 2013
Re: Focus
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
January 21, 2013
Re: Focus
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 !
January 21, 2013
Re: Focus
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
January 21, 2013
Re: Focus
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?
1 2 3 4 5 6 7
Top | Discussion index | About this forum | D home