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.

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

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?

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. 
 
 

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.

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)

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.

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.
 

 
 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.


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