View mode: basic / threaded / horizontal-split · Log in · Help
February 14, 2011
Re: Inheritance problem
On Fri, 11 Feb 2011 17:26:29 -0500, Andrej Mitrovic  
<andrej.mitrovich@gmail.com> wrote:

> On 2/11/11, bearophile <bearophileHUGS@lycos.com> wrote:
>> Steven Schveighoffer:
>>
>>> Any code can access any members defined in the current module,  
>>> regardless
>>>
>>> of access attributes
>>
>> I am not sure if Walter understands how much this rule makes it hard for
>> people not already used to protected/private attributes to understand  
>> and
>> learn to use those attributes correctly. The C# compiler doesn't have  
>> that
>> rule, and it's much more strict. I think this makes learning the usage  
>> of
>> those attributes faster.
>>
>> Bye,
>> bearophile
>>
>
> I think one benefit of the current approach is that we'll be able to
> use free functions which could be called as if they belong to a class
> (if they have that class as the first parameter), since we could use
> the uniform function call (UFC) syntax. But UFC doesn't work with
> classes yet, otherwise we might be able to do this:
>
> module foo;
> import std.stdio;
>
> class Foo {
>     private int _x, _y;
>     this(int x, int y) {
>         _x = x;
>         _y = y;
>     }
> }
>
> int sumXY(Foo foo) {
>     return foo._x + foo._y;
> }
>
> module main;
> import foo;
> import std.stdio;
>
> void main() {
>     auto obj = new Foo(10, 10);
>     writeln(obj.sumXY());  // using UFC, but doesn't work yet
>     //~ writeln(obj._x + obj._y);  // not allowed
> }
>

What's wrong with:

class Foo {
    private int _x, _y;
    this(int x, int y) {
        _x = x;
        _y = y;
    }
    int sumXY() {
        return _x + _y;
    }
}

> We could have a bunch of templated functions in the foo module which
> could work with any class inside that module. So it might help out
> against the common God class problem. What do you think?

I'm unaware of this problem, but I'm not sure it's a huge problem.  The  
UFC syntax is a marginal benefit, making a function look like it's part of  
the class.  The "horrible" alternative is to simply call the function with  
Foo as a parameter instead of the source.  i.e. f(x) vs. x.f()

Couldn't the same be achieved via mixins?  And in fact, the mixin I think  
can be defined in a separate module, more flexible.

-Steve
February 14, 2011
Re: Inheritance problem
On 2/14/11, Steven Schveighoffer <schveiguy@yahoo.com> wrote:
> What's wrong with:
>
> class Foo {
>      private int _x, _y;
>      this(int x, int y) {
>          _x = x;
>          _y = y;
>      }
>      int sumXY() {
>          return _x + _y;
>      }
> }

Nothing! But the OP asked why it's possible to access the private
state of a class if the code that accesses it is in the same module as
the class. So I just threw in an example (which admittedly doesn't
make much sense, and personally I don't like to access private state
outside the class).
February 14, 2011
Re: Inheritance problem
On Mon, 14 Feb 2011 10:52:41 -0500, Andrej Mitrovic  
<andrej.mitrovich@gmail.com> wrote:

> On 2/14/11, Steven Schveighoffer <schveiguy@yahoo.com> wrote:
>> What's wrong with:
>>
>> class Foo {
>>      private int _x, _y;
>>      this(int x, int y) {
>>          _x = x;
>>          _y = y;
>>      }
>>      int sumXY() {
>>          return _x + _y;
>>      }
>> }
>
> Nothing! But the OP asked why it's possible to access the private
> state of a class if the code that accesses it is in the same module as
> the class. So I just threw in an example (which admittedly doesn't
> make much sense, and personally I don't like to access private state
> outside the class).

I meant as an alternative to UFC syntax.  I still am not enamored by it's  
capabilities.

FWIW, classes/functions/structs in the same module are able to access all  
private and protected data to alleviate the need for the 'friend'  
attribute in C++.  In C++ a friend function is able to access all private  
data.  The most common use of friend functions is for output stream  
processors (since the operator is on the stream and not the object being  
outputted).

The theory for the private access in a module goes that likely the same  
author wrote all the code in that module, so he should understand what the  
code is supposed to do and have free access to anything.  It seems to work  
pretty well in practice (at least for me anyway).

-Steve
February 14, 2011
Re: Inheritance problem
On 2/14/11, Steven Schveighoffer <schveiguy@yahoo.com> wrote:
> In C++ a friend function is able to access all private
> data.  The most common use of friend functions is for output stream
> processors (since the operator is on the stream and not the object being
> outputted).

Oh right, these << << <<?

Ugly things. :p
February 14, 2011
Re: Inheritance problem
On 02/14/2011 05:13 PM, Steven Schveighoffer wrote:
> The theory for the private access in a module goes that likely the same author
> wrote all the code in that module, so he should understand what the code is
> supposed to do and have free access to anything.  It seems to work pretty well
> in practice (at least for me anyway).

The same logic applies in languages of the module/oberon line (which have a 
good reputation afaik for their module system). Encapsulation plays at the 
module level.
Eg in Oberon all is visible inside a module; the difference is exported/public 
thingies are marked (with '*'), instead of the opposite in D (which is in my 
view more like a dynamic language on this point).

denis
-- 
_________________
vita es estrany
spir.wikidot.com
Next ›   Last »
1 2
Top | Discussion index | About this forum | D home