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

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

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

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

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.

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

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

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.