It appears that protection attributes on static class methods don't get recognised. This compiles without errors:

    module stuff;

    class Visible {
        private static void hidden() {}
    }

    -----8<-----
    module program;

    import stuff;

    void main() {
        Visible.hidden();
    }

An error is issued if hidden() is at module level. I sometimes feel that classes are second-class citizens in D.

John C wrote:
> It appears that protection attributes on static class methods don't get recognised. This compiles without errors:
> 
>     module stuff;
> 
>     class Visible {
>         private static void hidden() {}
>     }
> 
>     -----8<-----
>     module program;
> 
>     import stuff;
> 
>     void main() {
>         Visible.hidden();
>     }
> 
> An error is issued if hidden() is at module level. I sometimes feel that classes are second-class citizens in D. 
> 
> 

This protection stuff is rediculous, any modern OO language needs to handle these things well.

Kyle Furlong wrote:
> John C wrote:
> 
>> It appears that protection attributes on static class methods don't get recognised. This compiles without errors:
>>
>>     module stuff;
>>
>>     class Visible {
>>         private static void hidden() {}
>>     }
>>
>>     -----8<-----
>>     module program;
>>
>>     import stuff;
>>
>>     void main() {
>>         Visible.hidden();
>>     }
>>
>> An error is issued if hidden() is at module level. I sometimes feel that classes are second-class citizens in D.
>>
> 
> This protection stuff is rediculous, any modern OO language needs to handle these things well.

Yeah, and the implicit module friendship is rediculous too!!! The whole C++ friend concept is rediclous.

"Hasan Aljudy" <hasan.aljudy@gmail.com> wrote in message news:du4ulf$1hpp$1@digitaldaemon.com...
>> This protection stuff is rediculous, any modern OO language needs to handle these things well.
>
> Yeah, and the implicit module friendship is rediculous too!!! The whole C++ friend concept is rediclous.

Actually, nothing is "rediculous," only "r_i_diculous" ;)

Implicit module friendship works well.  Do you have a better suggestion?

And the problem that the OP posted is most likely related to the "protection attributes mean nothing if you use a fully qualified name" bug.

"Jarrett Billingsley" <kb3ctd2@yahoo.com> wrote in message news:du4vft$1isn$1@digitaldaemon.com...
> "Hasan Aljudy" <hasan.aljudy@gmail.com> wrote in message news:du4ulf$1hpp$1@digitaldaemon.com...
>>> This protection stuff is rediculous, any modern OO language needs to handle these things well.
>>
>> Yeah, and the implicit module friendship is rediculous too!!! The whole C++ friend concept is rediclous.
>
> Actually, nothing is "rediculous," only "r_i_diculous" ;)
>
> Implicit module friendship works well.  Do you have a better suggestion?

I just realized you may have been being sarcastic.

Jarrett Billingsley wrote:
> "Jarrett Billingsley" <kb3ctd2@yahoo.com> wrote in message news:du4vft$1isn$1@digitaldaemon.com...
> 
>>"Hasan Aljudy" <hasan.aljudy@gmail.com> wrote in message news:du4ulf$1hpp$1@digitaldaemon.com...
>>
>>>>This protection stuff is rediculous, any modern OO language needs to handle these things well.
>>>
>>>Yeah, and the implicit module friendship is rediculous too!!! The whole C++ friend concept is rediclous.
>>
>>Actually, nothing is "rediculous," only "r_i_diculous" ;)
>>
>>Implicit module friendship works well.  Do you have a better suggestion?
> 
> 
> I just realized you may have been being sarcastic. 
> 
> 
No ..
friendship works, my point was that it shouldn't be there in the first place, it's not part of the OO paradigm, it's a hack introduced by C++

"Hasan Aljudy" <hasan.aljudy@gmail.com> wrote in message news:du56te$1rn5$1@digitaldaemon.com...
> friendship works, my point was that it shouldn't be there in the first place, it's not part of the OO paradigm, it's a hack introduced by C++

Just because it's not part of some archaic OO paradigm doesn't mean it can't exist.  It might be a hack, but I think it's kind of borne out of necessity. Sometimes the rules in OO need to be .. bent a little, and friend classes do just that.  I mean, which would you rather have?  Two classes that need to work together friended so they can access each others' internals, and so no one else can access those internals?  Or be required to make those internals public just so those classes can work together?  If two classes really need to work together but still need to be separate classes, I really don't see any other solution..

Jarrett Billingsley wrote:
> "Hasan Aljudy" <hasan.aljudy@gmail.com> wrote in message news:du56te$1rn5$1@digitaldaemon.com...
>> friendship works, my point was that it shouldn't be there in the first place, it's not part of the OO paradigm, it's a hack introduced by C++
> 
> Just because it's not part of some archaic OO paradigm doesn't mean it can't exist.  It might be a hack, but I think it's kind of borne out of necessity. Sometimes the rules in OO need to be .. bent a little, and friend classes do just that.  I mean, which would you rather have?  Two classes that need to work together friended so they can access each others' internals, and so no one else can access those internals?  Or be required to make those internals public just so those classes can work together?  If two classes really need to work together but still need to be separate classes, I really don't see any other solution.. 
> 
> 

Well, do people use your *ORGANS* when you work with them?

On Wed, 01 Mar 2006 16:43:07 -0800, Kyle Furlong <kylefurlong@gmail.com> wrote:
> Jarrett Billingsley wrote:
>> "Hasan Aljudy" <hasan.aljudy@gmail.com> wrote in message news:du56te$1rn5$1@digitaldaemon.com...
>>> friendship works, my point was that it shouldn't be there in the first place, it's not part of the OO paradigm, it's a hack introduced by C++
>>  Just because it's not part of some archaic OO paradigm doesn't mean it can't exist.  It might be a hack, but I think it's kind of borne out of necessity. Sometimes the rules in OO need to be .. bent a little, and friend classes do just that.  I mean, which would you rather have?  Two classes that need to work together friended so they can access each others' internals, and so no one else can access those internals?  Or be required to make those internals public just so those classes can work together?  If two classes really need to work together but still need to be separate classes, I really don't see any other solution..
>
> Well, do people use your *ORGANS* when you work with them?

No. However a better analogy is "I will let my neighbour come over and use my basketball hoop, but not the general public."

class Me {
  private BasketBallHoop hoop;
}

class Neighbour {
  void playSomeBall(BasketBallHoop hoop) {}
}

void main()
{
  Neighbour bob = new Neighbour();
  Me regan = new Me();
  bob.playSomeBall(regan.hoop);
}

Regan

Regan Heath wrote:
> On Wed, 01 Mar 2006 16:43:07 -0800, Kyle Furlong <kylefurlong@gmail.com>  wrote:
> 
>> Jarrett Billingsley wrote:
>>
>>> "Hasan Aljudy" <hasan.aljudy@gmail.com> wrote in message  news:du56te$1rn5$1@digitaldaemon.com...
>>>
>>>> friendship works, my point was that it shouldn't be there in the first  place, it's not part of the OO paradigm, it's a hack introduced by C++
>>>
>>>  Just because it's not part of some archaic OO paradigm doesn't mean it  can't exist.  It might be a hack, but I think it's kind of borne out of  necessity. Sometimes the rules in OO need to be .. bent a little, and  friend classes do just that.  I mean, which would you rather have?  Two  classes that need to work together friended so they can access each  others' internals, and so no one else can access those internals?  Or  be required to make those internals public just so those classes can  work together?  If two classes really need to work together but still  need to be separate classes, I really don't see any other solution..
>>
>>
>> Well, do people use your *ORGANS* when you work with them?
> 
> 
> No. However a better analogy is "I will let my neighbour come over and use  my basketball hoop, but not the general public."
> 
> class Me {
>   private BasketBallHoop hoop;
> }
> 
> class Neighbour {
>   void playSomeBall(BasketBallHoop hoop) {}
> }
> 
> void main()
> {
>   Neighbour bob = new Neighbour();
>   Me regan = new Me();
>   bob.playSomeBall(regan.hoop);
> }
> 
> Regan

Why would you *not* allow the general public to play with your hoop?
obviously, if you neighbour can play with it without negatively altering your state (as an object), then everyone else should be allowed to play, since they too won't be able to negatively alter your state.

From the way I understand OOP, the main reason for encapsulation is to increase the cohesion of code that maintains the state of the object.

You don't want other objects to directly access your fields (data members) because most of the time there are maintainance tasks that need to be taken when reading/writing values to/from local fields. You want these tasks to be performed in one place, that is the get/set methods inside the class itself.

That's why OOP says you should always use accessor methods for object varaibles and to never make them public!!

If you have an "age" variable for a "Person" class, you probably want to always make sure that this age is reasonable, i.e. it's between 0 and 200. So, you need to write code to make sure this condition is always met; you don't want to suddenly have a person with a negative age.
The only reason why would disallow direct access to the "age" field is so that you can be sure that no invalid age can be set for any person object. If you don't privitize age, then you have to splatter the age validation code everywhere you access/modify "age" fields of "Person" objects ... you don't want that to happen!!

That's the idea behind enapsulation.

It's got nothing to do with "forbidding" users from knowing how your code works. There's no purpose in hiding a method just for sake of hiding it. If you can make it public for some objects, it should be allowed to be public for all objects.

That's OOP, which bythe way, is a purist paradigm. I know D is not for language purists, but OOP must be supported properly.

Can you give me a real life example where one class needs to expose certain parts of itself to only one or two other classes? and why would providing a public accessor for this feild be a bad thing?