In article <du5hau$2b94$1@digitaldaemon.com>, Hasan Aljudy says...
>
..
>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?

Yes.  We have classes at work that interact.  We decided to make them friends. We have clients that use these classes.  If the classes weren't friends, and we provided the accessors, then *at that moment*, what you say is true, nothing would break.  We can provide all the guarantees of validity, etc.

But if we change the implementation of this class by removing or renaming a field or method, which we often do, then all the clients of the code outside our team, (we are writing library code, among other things) will need to change their usage of it if they happen to use that method or field.

We're not "hiding" data from clients.  If clients ask for access to the information, we virtually always give it to them.  But we need to know what people are using and what they aren't.  Otherwise, we remove a method, and break code in a dozen other projects.

If they are using something, we try to avoid changing it, or communicate first at least, and phase-in changes slowly.   The second kind (the private API that only friends see) we are free to change without warning as long as *our* code works with the change.

So I guess it's a people thing, not a code thing.

Kevin

On Wed, 01 Mar 2006 18:22:06 -0700, Hasan Aljudy <hasan.aljudy@gmail.com> wrote:
>>> 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?

Because, I can only trust myself and my neighbour not to break it. :)

Regan

On Wed, 01 Mar 2006 18:22:06 -0700, Hasan Aljudy wrote:

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


> 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.

Its a 'trust' thing. I trust my neighbour more than I trust unknown people.


> 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?

The 'friend' concept can be used as a compromise to gain runtime performance.

-- 
Derek
(skype: derek.j.parnell)
Melbourne, Australia
"Down with mediocracy!"
2/03/2006 1:34:54 PM

"Hasan Aljudy" <hasan.aljudy@gmail.com> wrote in message news:du4ulf$1hpp$1@digitaldaemon.com...
> 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.

This is an issue that has been raised at least once before:

http://www.digitalmars.com/d/archives/digitalmars/D/23420.html

I believe that anything which violates encapsulation should be explicit.

For this reason, if a friendship level/type of access is required then an explicit friend qualifier should be introduced.

This should also serve to make the C++ crowd happier.

Tony
Melbourne, Australia
tonysZ-mailboxZ@hotmailZ.com  (remove the Zs)

"Jarrett Billingsley" <kb3ctd2@yahoo.com> wrote in message news:du4vft$1isn$1@digitaldaemon.com...
>
> 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.

You might be right about it being a bug - 'protected' and 'package' are ignored on static class methods too.

Tony wrote:
> "Hasan Aljudy" <hasan.aljudy@gmail.com> wrote in message news:du4ulf$1hpp$1@digitaldaemon.com...
> 
>>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.
> 
> 
> This is an issue that has been raised at least once before:
> 
> http://www.digitalmars.com/d/archives/digitalmars/D/23420.html
> 
> I believe that anything which violates encapsulation should be explicit.
> 
> For this reason, if a friendship level/type of access is required then an explicit friend qualifier should be introduced.
> 
> This should also serve to make the C++ crowd happier.
> 
> Tony
> Melbourne, Australia
> tonysZ-mailboxZ@hotmailZ.com  (remove the Zs)
> 
> 
> 

Yeah, that was me!
As you can see, I'm still whining about it :)

Tony wrote:

> "Hasan Aljudy" <hasan.aljudy@gmail.com> wrote in message news:du4ulf$1hpp$1@digitaldaemon.com...
> 
>>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.
> 
> 
> This is an issue that has been raised at least once before:
> 
> http://www.digitalmars.com/d/archives/digitalmars/D/23420.html
> 
> I believe that anything which violates encapsulation should be explicit.
> 
> For this reason, if a friendship level/type of access is required then an explicit friend qualifier should be introduced.
> 
> This should also serve to make the C++ crowd happier.
> 
> Tony
> Melbourne, Australia
> tonysZ-mailboxZ@hotmailZ.com  (remove the Zs)
> 
> 
> 
Disclaimer: the OP code seems to be a bug, I am not contradicting that.

Each time I hear things like this I always ask for specific pragmatic examples of strict protection benefits outside of simple namespace-clash issues(which also mean IDE code completion).

I've yet to see a good example in which strict protection attributes prevented any defects.  Thus far this is a sky-is-falling issue, with very little real practical evidence.

Its frankly ridiculous to assume that a programmer working on a source file(a module) would be tripped up in his own classes because one was private and another was not.  If you cant handle a few classes in one source file, I question your programming expertise.

This seems like OOP-purism versus pragmatism.
I hope Walter keeps "all module classes can see each other".

-DavidM

"Wherever there is modularity there is the potential for misunderstanding. Hiding information implies a need to check communication." - Alan Perlis

David Medlock wrote:
> Tony wrote:
> 
> Disclaimer: the OP code seems to be a bug, I am not contradicting that.
> 
> Each time I hear things like this I always ask for specific pragmatic examples of strict protection benefits outside of simple namespace-clash issues(which also mean IDE code completion).
> 
> I've yet to see a good example in which strict protection attributes prevented any defects.  Thus far this is a sky-is-falling issue, with very little real practical evidence.

It's not obvious in small programs, but it becomes crucial in large projects, and even more crucial in projects with millions of lines of code.

I think the dmd compiler is a good example.
Don't you see how Walter spends more time fixing bugs than adding new features?!
If you look at the source code you can understand why.
I must say that I'm amazed how he can maintain the source code of the compiler!!
However, I think that if he'd used proper object oriented model for the compiler, less bugs will need to be fixed, and maybe v1.0 would've been ready along time ago!

(( Sorry Walter, that is just my opinion .. I know it is offensive, but .. oh well <g> ))

> 
> Its frankly ridiculous to assume that a programmer working on a source file(a module) would be tripped up in his own classes because one was private and another was not.  If you cant handle a few classes in one source file, I question your programming expertise.

"few classes" is an understatement.
The complexity of the problems tend to increase overtime.
Maybe now you see no point in writing get/set methods for this variable, or you maybe see no point in making a class for this concept or that one.
However, after a while the complexity is likely to increase. You will find that you need to privitze that variable and write accessor methods for it, and you will need to group those functions/variables in a class.
It _always_ happens with me, and I've never written a large-scale project.



> 
> This seems like OOP-purism versus pragmatism.

OOP is a purist paradigm, but frankly, this purism came from experience, and it's a pragmatic purism, not purism just for the sake of purism.
D claims to support OOP. Well .. it should support it properely.

> I hope Walter keeps "all module classes can see each other".

I wish at least that he'd make it require an explicit statement.

> 
> -DavidM
> 
> "Wherever there is modularity there is the potential for misunderstanding. Hiding information implies a need to check communication." - Alan Perlis

I'm all against information hiding.
I'm all for cohesion.

Hasan Aljudy wrote:

> David Medlock wrote:
> 
>> Tony wrote:
>>
>> Disclaimer: the OP code seems to be a bug, I am not contradicting that.
>>
>> Each time I hear things like this I always ask for specific pragmatic examples of strict protection benefits outside of simple namespace-clash issues(which also mean IDE code completion).
>>
>> I've yet to see a good example in which strict protection attributes prevented any defects.  Thus far this is a sky-is-falling issue, with very little real practical evidence.
> 
> 
> It's not obvious in small programs, but it becomes crucial in large projects, and even more crucial in projects with millions of lines of code.
> 

Most of my projects are in the 10-50k LOC range, with a few dipping 100-200k.   With projects of large size, the interfaces between the components needs to be a component itself.

A.C(B)

should be (where C is an object)

C( A, B )

No amount of protection in A or B will help there.

> I think the dmd compiler is a good example.
> Don't you see how Walter spends more time fixing bugs than adding new features?!
> If you look at the source code you can understand why.
> I must say that I'm amazed how he can maintain the source code of the compiler!!
> However, I think that if he'd used proper object oriented model for the compiler, less bugs will need to be fixed, and maybe v1.0 would've been ready along time ago!
> 

Sorry, but this is conjecture.
I haven't traversed his source code much but the OOP-equals-better-code isn't borne out in the software industry( where is the overflowing abundance of reusable libraries?)
Even if I accepted the premise, I seriously doubt protection attributes have caused him a lot of bugs.  Ironically handling all the corner cases(like C++'s friend attribute) probably have.

>>
>> Its frankly ridiculous to assume that a programmer working on a source file(a module) would be tripped up in his own classes because one was private and another was not.  If you cant handle a few classes in one source file, I question your programming expertise.
> 
> 
> "few classes" is an understatement.
> The complexity of the problems tend to increase overtime.
> Maybe now you see no point in writing get/set methods for this variable, or you maybe see no point in making a class for this concept or that one.
> However, after a while the complexity is likely to increase. You will find that you need to privitze that variable and write accessor methods for it, and you will need to group those functions/variables in a class.
> It _always_ happens with me, and I've never written a large-scale project.
> 

We are talking about a single module aren't we? The most I would expect to see is maybe 4 or 5 classes.  Any more and you probably need to refactor.

> 
> 
>>
>> This seems like OOP-purism versus pragmatism.
> 
> 
> OOP is a purist paradigm, but frankly, this purism came from experience, and it's a pragmatic purism, not purism just for the sake of purism.
> D claims to support OOP. Well .. it should support it properely.
> 

That goal implies that OOP is a single set in stone paradigm, it is not.

see:
http://www.paulgraham.com/reesoo.html

>> I hope Walter keeps "all module classes can see each other".
> 
> 
> I wish at least that he'd make it require an explicit statement.
> 
But, we already have an explicit _way_ to do that, separate modules.

Cheers.
-DavidM

Jarrett Billingsley wrote:
> 
> 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. 
> 
> 
No, I think it is more likely related to the bug of protection attributes only working for instance members, and no other entities. For example, protection attributes also don't work for classes or structs. As in:

  private class Foo {  // 'private' is effectless
    ...
  }

-- 
Bruno Medeiros - CS/E student
"Certain aspects of D are a pathway to many abilities some consider to be... unnatural."