www.digitalmars.com         C & C++   DMDScript  

digitalmars.D - static and protection

reply "John C" <johnch_atms hotmail.com> writes:
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.
Mar 01 2006
parent reply Kyle Furlong <kylefurlong gmail.com> writes:
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.
Mar 01 2006
parent reply Hasan Aljudy <hasan.aljudy gmail.com> writes:
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.
Mar 01 2006
next sibling parent reply "Jarrett Billingsley" <kb3ctd2 yahoo.com> writes:
"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.
Mar 01 2006
next sibling parent reply "Jarrett Billingsley" <kb3ctd2 yahoo.com> writes:
"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.
Mar 01 2006
parent reply Hasan Aljudy <hasan.aljudy gmail.com> writes:
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++
Mar 01 2006
parent reply "Jarrett Billingsley" <kb3ctd2 yahoo.com> writes:
"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..
Mar 01 2006
parent reply Kyle Furlong <kylefurlong gmail.com> writes:
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?
Mar 01 2006
parent reply "Regan Heath" <regan netwin.co.nz> writes:
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
Mar 01 2006
parent reply Hasan Aljudy <hasan.aljudy gmail.com> writes:
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?
Mar 01 2006
next sibling parent Kevin Bealer <Kevin_member pathlink.com> writes:
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



 Mar 01 2006



prev sibling next sibling parent  "Regan Heath" <regan netwin.co.nz>  writes:


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



 Mar 01 2006



prev sibling  parent  Derek Parnell <derek psych.ward>  writes:


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



 Mar 01 2006



prev sibling next sibling parent  "John C" <johnch_atms hotmail.com>  writes:


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



 Mar 02 2006



prev sibling  parent reply Bruno Medeiros <daiphoenixNO SPAMlycos.com>  writes:


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



 Mar 02 2006



 next sibling parent  "Jarrett Billingsley" <kb3ctd2 yahoo.com>  writes:


"Bruno Medeiros" <daiphoenixNO SPAMlycos.com> wrote in message 
news:du7jtr$27bm$1 digitaldaemon.com...

 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.


Oh that's right, forgot about that one.  Protection attributes really suck, 
don't they? 



 Mar 02 2006



prev sibling  parent  Bruno Medeiros <daiphoenixNO SPAMlycos.com>  writes:


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.



Bruno Medeiros wrote:

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


Anyway, I've commented and reported about this issue before, but didn't 
get Walter's opinion on it, so I don't know if he considers this a bug 
or not. Anyone knows about this? (well, Walter at least does for sure)
I can already see by the spec ( 
http://www.digitalmars.com/d/attribute.html ) that protection is 
currently only member-centric, but should we or not change (improve, 
IMO) this behavior?

I also would like to know about the issue of using fully qualified names 
ignores protection attributes:

   moduleFoo.privateFunc() // Compiles ok, shouldn't

Is it also a bug or not? (should well damn be!)

(Hum, starting to think we could improve our way of tracking bugs and 
design issues)

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



 Mar 03 2006



prev sibling  parent reply "Tony" <ignorethis nowhere.com>  writes:


"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)



 Mar 02 2006



 next sibling parent  Hasan Aljudy <hasan.aljudy gmail.com>  writes:


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 :)



 Mar 02 2006



prev sibling  parent reply David Medlock <noone nowhere.com>  writes:


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



 Mar 02 2006



  parent reply Hasan Aljudy <hasan.aljudy gmail.com>  writes:


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.



 Mar 02 2006



 next sibling parent reply David Medlock <noone nowhere.com>  writes:


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



 Mar 02 2006



 next sibling parent reply Bruno Medeiros <daiphoenixNO SPAMlycos.com>  writes:


David Medlock wrote:

 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.
 


Why not? You can still protect C, even though it's an object/class and 
not a method, isn't it so?

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



 Mar 02 2006



  parent  David Medlock <noone nowhere.com>  writes:


Bruno Medeiros wrote:

 David Medlock wrote:
 

 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.


 
 Why not? You can still protect C, even though it's an object/class and 
 not a method, isn't it so?
 



What I mean is something like this(sortof strategy pattern):

// begin simplified example

class A { int a; void foo(B b) {...}; }
class B { int b; }

Multiply the number of A descendents and it gets messy, especially with 
a large tree.

Since the implementation of A is generally constant, I usually end up 
refactoring to:

class foo {
   void call( A a, B b );
}

This class must use the members of A and B.  In C++ it would be a 
friend, but since its functionality is local, it doesn't make any 
difference at all what the modifiers are for the data members of A and B.

Any problems you have will be in foo, no matter whether you use accessor 
methods or just public variables.

In all of this I am speaking of sub-classing, not sub-typing.  There is 
a very real reason to hide private methods, but the typical usage of 
inheritance which gets into trouble is using it as a mixin or shared 
functionality mechanism.  This usage of inheritance is *exactly* what 
protected access is for, base functionality exposed at the class level 
for re-use.

-DavidM



 Mar 02 2006



prev sibling  parent  Hasan Aljudy <hasan.aljudy gmail.com>  writes:


David Medlock wrote:

 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.


you mean A is an object and C is a method?
Sorry, I don't quite get what's your point there.


 


<snip>

 
 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.


I have also looked at the source code of the half-life and half-life2, 
if you look at it from the point of view of an OO purist, you won't be 
wondering anymore why steam/HL2 are so buggy and why Valve needs to 
release bug fixes every 2 weeks (I guess you can't relate to what I'm 
saying unless you have played HL2 and used steam).


 

 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.


Yup, but if your classes are tightly coupled, refactoring won't be that 
easy!! specially when they get big.
That was my point.


 

 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 learned OOP from an OO purist.
No, I don't mean inheritance and polymorphism, I've known this stuff 
before I got into university. What I'm talking about is what OOP really 
means, the abstract conptual theoretical stuff. Alot of people think 
they're doing object oriented programming, when they are actually not. 
Just because you write classes here and there, it doesn't make your code 
object oriented.

There is no formal definition for oop.
The main thing in OOP is cohesion .. really, if you have 20 uncohesive 
classes, then your code is not object oriented.
Unfortunately not many people realize that, and almost no one in the net 
talks about cohesion in an object oriented context.


 

 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.


That's the opposite of explicit!
explicit means "don't do it unless I say it". If I don't tell you to 
enable module friendship, I don't want to see it!!



 
 Cheers.
 -DavidM
 
 


-Hasan



 Mar 02 2006



prev sibling  parent reply Don Clugston <dac nospam.com.au>  writes:


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.
 
 I think the dmd compiler is a good example.
 Don't you see how Walter spends more time fixing bugs than adding new 
 features?!


You're kidding, right? Generally, the features don't get descriptions as 
long as the bugs do. Some of those features are *huge*. Also, what tends 
to happen is that we get a staged implementation of features -- most of 
the bugs are extending the feature to apply in more situations.


 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!


?? Name another language that has progressed anywhere near as fast.

I think that pure OO has largely been a failure. It's failed to live up 
to its initial hype. (Specifically, the claim of code reuse has _not a 
scrap_ of truth to it. History has shown that the only time you get code 
reuse is when you intentionally design a library. C has a better history 
of code reuse than object-oriented C++!). What _is_ true is that 
cohesion leads to more reliable code.

On a tangentially related topic:
Something I'm finding very interesting about D is inner functions.
I'm finding that lots of things I would have used private class members 
for, I'm now using nested functions instead, with the result that simple 
classes sometimes disappear completely.

With nested functions, you get extremely strong cohesion -- better than 
is possible in OOP. eg, generally, private class functions aren't 
completely private in OO languages. They appear in vtables, for example.

I don't think this programming paradigm has been very well explored yet.



 Mar 03 2006



 next sibling parent  David Medlock <noone nowhere.com>  writes:


Don Clugston wrote:
<snip>


 On a tangentially related topic:
 Something I'm finding very interesting about D is inner functions.
 I'm finding that lots of things I would have used private class members 
 for, I'm now using nested functions instead, with the result that simple 
 classes sometimes disappear completely.
 
 With nested functions, you get extremely strong cohesion -- better than 
 is possible in OOP. eg, generally, private class functions aren't 
 completely private in OO languages. They appear in vtables, for example.
 
 I don't think this programming paradigm has been very well explored yet.
 


I absolutely agree.  Inner functions are definitely in the top 3 reasons 
I love D.

The code I posted in "Template regexes, version 2" that allows 
backtracking over all possibilities in a regex is a great example of 
their power.

Try doing what my code does without using inner functions.  It will be 
much less readable.

-DavidM



 Mar 03 2006



prev sibling  parent  Hasan Aljudy <hasan.aljudy gmail.com>  writes:


Don Clugston wrote:
<snip>

 I think that pure OO has largely been a failure. It's failed to live up 
 to its initial hype. (Specifically, the claim of code reuse has _not a 
 scrap_ of truth to it. History has shown that the only time you get code 
 reuse is when you intentionally design a library. C has a better history 
 of code reuse than object-oriented C++!). What _is_ true is that 
 cohesion leads to more reliable code.


I don't recognize "information hiding" and "code reuse" as 
benefits/goals of object oriented programming!!
Similarily, I don't recognize "platform independence" as a pwoerful 
advantage for Java!!

The reason I like and use Java is not the "compile-once-run-anywhere" 
motto. I like Java because it's simple yet powerful, and has a rich 
library/framework. (The downside is the VM)

Sometimes people promote the right thing for the wrong reason! you know ..

I'm a (self proclaimed) proponent of OOP because of concepts like 
cohesion and modularity, which highly reduce complexity, and allow 
easier maintainance of code.

"code reuse" is only true within the project itself! That is, if I want 
to implement two modules that have similar "functionalities", I put the 
"shared" functionality in a super class and then extend it.
Others will probably not find my superclass very usefull at all!



 
 On a tangentially related topic:
 Something I'm finding very interesting about D is inner functions.
 I'm finding that lots of things I would have used private class members 
 for, I'm now using nested functions instead, with the result that simple 
 classes sometimes disappear completely.
 
 With nested functions, you get extremely strong cohesion -- better than 
 is possible in OOP. eg, generally, private class functions aren't 
 completely private in OO languages. They appear in vtables, for example.
 
 I don't think this programming paradigm has been very well explored yet.


Yeah, I like nested functions too. Although I didn't need to use them 
much so far, maybe because I like to keep my functions very small.



 Mar 03 2006