What's really annoying for me is that the private/protected-part-sharing stuff must always reside in a single file.

I normally tend to write in a class-per-file fashion because it simply
makes code better 'readable'. This method is also frequently adhered to in existing projects. That is using class-per-file plus x.all metamodules, Which I personally find ideal for heavy OO applications.

The java approach wasn't that bad actually. OK, java _forced_ to use class-per-file, that's not ideal. D perfectly fixes that.

BUT, with java a package is splet into nice separate files and besides it's possible to 'extend' an existing package from some library and have access to the protected parts of the classes. Just put some classes into existing packages, and that's it.

Actually this option is not bad to have.

As for incapsulation disputes, IMHO, incapsulation-guarding techniques for a language should not be too restrictive. In most cases It's main purpose is to protect a programmer from his own _relatively obvious_ encapsulation misconceptions.

Putting a class _accidentally_ into an existing package has a very small probability.

Question to strict OOPlers.

- Do you at least agree, it's ok to have semi-implicite friends, like protected class members in java (making protected members visible for the entire package)?

- Where I'm not 100% sure, is the question whether visibility of everything to everything (including private) inside a module is a good practice. Is there analogous behavior in other languages? Are there any negative experiences because of that? Any suggestions?

B.G. wrote:
> Question to strict OOPlers.
> 
> <snip>
> 
> - Where I'm not 100% sure, is the question whether visibility of everything to everything (including private) inside a module is a good practice. Is there analogous behavior in other languages? Are there any negative experiences because of that? Any suggestions?

Well, the way I see it right now, a module acts as a class, in terms of "private" and "public" attributes atleast.
This is ok if a module is meant to be a way of encapsulating related data or some thing like that, but that's not very clear to me, I was assuming a module is just a file like a cpp file, and that the module concept was introduced to eliminate the need for .h files.

The analogous behaviour in other languages (and in D itself) is the "class" .. ironic?

The way things are built now, a module should only contains one class, having it contain more, is like mixing several classes into one class, since every method would have access to every member variable across all the classes.

What I mean is, it seems to me that modules are meant to encapsulate a specific entity or functionality .. so really a source file is not just a grouping of source code (like cpp files), but it represents some sort of entity, which makes it more like java files.

So, there is not much difference from java, in that each class needs to be in its own file.

I would personally accept it if it was made clear that a module is an entity by itself that should be cohesive just like a class. i.e. you wouldn't make a class to draw images and recieve input at the same time (that would be a very uncohesive class), and so you shouldn't put unrelated functions or classes in one module.

I'm kind of confused now myself, what exactly is a module? what's its purpose (why was it invented)? and, are .d source files meant to encapsulate an idea/entity/concept/functionbality like .java files? or are they just meant for organization, like .cpp files?

Maybe there should be more focus on this area in the website, to clear the confusion. Because at first I was thinking of d files as "just source files", which is why I felt it's redicilous to have implicit friendship between classes in the same file, but now that I think about it in terms of "modules", it seems to me that modules are kind of a procedural alternative to the OO class concept.
I'm still confused, as to why the idea was come up with?

I still think there shouldn't be implicit friendship though, it must be explicit between classes even if they are in the same modules, becuase classes are one level down inside a module, if you know what I mean.

You have several levels of privacy/locality.
private modules variables are like global variables that are only visible inside the module. That's the highest level.
The seocnd level is private class members, they should only be visible to the class, unless otherwise is explicitly stated.

Kind of hard for me to explain.

Think of it like this: assume we can have modules within modules, and we have moule 1, inside it module 2, inside it is module 3.
things inside module 3 have access to all vriables in modules 1, 2, 3.
things inside module 2 have access to all variable in modules 1, 2, and only public variables in module 3.
things in module 1 only have access to public things in modules 2, 3 and everything in module 1.

Kind of like a blackbox within a blackbox (blackbox1, inside it there is blackbox2). everything inside a blackbox knows the innder workings of it, blackbox2 is inside blackbox1, so bb2 knows how things in bb1 work, so it can access them. but for bb1, bb2 is a blackbox, bb1 doesn't know the inner works of bb2, so it shouldn't try to mess with it.

See, in a class, all methods have access to the private variables, but, local variables inside a method are private to that method, other methods can't reference them, because they are private to the method itself, not to everything related to it. (local method variables don't really exist until the method is called, but I'm talking theoratically, so my point still stands)

I hope you understand what I mean.

It makes perfect sense to have private module variables and have them accessable only inside that module, but to me, it doesn't make sense to make things that are private to a class inside a module, to make them accessable to the whole module.

"Derek Parnell" <derek@psych.ward> wrote in message news:1ij7494v296ax$.11p7zru21utm3.dlg@40tude.net...
> On Wed, 11 May 2005 10:07:33 +1000, Tony wrote:
>
>
> > Darn.  I seem to be swimming against the current of popular opinion
here.
> >
> > I agree with Hasan for the simple reason that I feel anything which
violates
> > encapsulation should be explicit.
> >
> > I agree that in practice it is unlikely to be a problem.  However, it is nice to be certain that there is no inadvertent coupling.
> >
> > Tony
> > Melbourne, Australia
>
> I'm with Hasan too ;-) But I'm willing to compromise if we can have both coding styles enabled.
>
> BTW, I'm based in Ormond. Where are you?
>
> -- 
> Derek
> Melbourne, Australia
> 11/05/2005 10:12:28 AM

Hi Derek,

I had to look up "Ormond" in my Melway :)
You aren't that far away from me.  I'm in Vermont.

Tony
Melbourne, Australia

Hasan Aljudy wrote:
> People who don't really write OO code probably won't realize the point of this, but people who do OO all the time do realize it, I don't think this "feature" of D will appeal to many of them.
> 
> D is suposed to be *practical* and simple, but this does not mean it should provide simple ways of writing bad code .. becuase this totally contradicts the "practical" part. If it's easy to write bad code, then the language is probably not that practical.
> In my opinion, if you want an easy way to break encapsulation, just make everything public, or don't write OO code.

I come from a C++/mostly Java background, so have been coding 'OO' for a while. I'm not a purist, and it doesn't matter to me what happens within a library. I view the object oriented paradigm as a *guideline* to good design practices, and not as a set of 'rules' that must be adhered to. From this perspective, all that matters to me is that the language allows me to easily implement my object oriented design while allowing me to hide the implementation details from clients where needed.

I can easily see the perspective you are coming from, but to me it's just as easy to see it another way. Encapsulation is meant to hide implementation details - clients can use a standard interface and I can change the implementation behind the scenes without them ever knowing. Considering that the module in which a class resides is part of the implementation, then module-level access to private class members does not break encapsulation. Yes, you can counter that it's easy, particularly on large teams, to screw things up by setting a class member directly rather than manipulating it via a setter method, but to me that's an issue that belongs in the realm of coding standards rather than language features.

Personally, I like it that I don't need to explicitly declare friends. If we did allow a friend keyword, would you be allowed to declare them outside of the module? Outside of the package? That, in my mind, *does* break encapsulation where the current case doesn't. So I would prefer leaving things as is, but if we must have a special keyword for it then it should be restricted to module scope.

Hasan Aljudy wrote:
> B.G. wrote:
> 
>> Question to strict OOPlers.
>>
>> <snip>
>>
>> - Where I'm not 100% sure, is the question whether visibility of everything to everything (including private) inside a module is a good practice. Is there analogous behavior in other languages? Are there any negative experiences because of that? Any suggestions?
> 
> 
> Well, the way I see it right now, a module acts as a class, in terms of "private" and "public" attributes atleast.
> This is ok if a module is meant to be a way of encapsulating related data or some thing like that, but that's not very clear to me, I was assuming a module is just a file like a cpp file, and that the module concept was introduced to eliminate the need for .h files.

> The way things are built now, a module should only contains one class, having it contain more, is like mixing several classes into one class, since every method would have access to every member variable across all the classes.
Errr, AFAIK a module can contain any nuber of classes, that's the difference with java. Perhaps it's just the STYLE many developers have chosen to put every class into a separate module. Did I miss something???

I've read the language specs once more and here is my vision.

If someone asked me to put the access control differences between java and D in a most simple way, I'd describe it as below. (This is my vision, I would appreciate any comments, if there's something wrong with it. I'm not a native english speaker, so wording might need to be changed too.)

IMO, Compiling such a small tutorial would be VERY helpful for beginners.

-= How to understand D access control if you know java access control =-

1) D allows multiple classes per compilation unit. Just for a minute imagine it WOULD NOT allow to do so. This way D source code layout would be exactly the same as in java. At this level, a 'package' in D terminology corresponds to a 'package' in java terminology.

2) rename 'protected' atribute in java code to read 'package'.

----- After these 'changes' java logic and syntax for access control
      has been 'translated' to D.
      Further is what makes D a more flexible language in
      terms of access control.

3) add 'protected' attribute with a new meaning of allowing
_only derived_ classes to access the corresponding members.

4) Now allow multiple classes in a single compilation unit (file).
In additions to the above access control, this gives a chance to relate some classes at the lowest possible level.
That is, all members, regardless, 'private', 'package' or 'protected' even in different classes are visible for all other members inside a single compilation unit. These compilation units are called modules in D.

In java a class simply belongs to a certain package.

In D _in addition_ to that it also logically belongs to a certain module inside this package (even if that module consists of this single class only). Though, syntactically a class is declared to belong to a module and it implicitely belongs to the enclosing package.

http://java.sun.com/docs/books/tutorial/java/javaOO/accesscontrol.html

package, private, protected and public are all the same as in Java, with the important difference that everything is visible to the module, regardless of the specifier.. there's also "export" that allows access to other executables, like in DLLs (if I got the doc right :)

I'm not sure what happens in D if you don't specify anything (in Java it gives access to package, but not subclasses.


xs0


> If someone asked me to put the access control differences between java and D in a most simple way, I'd describe it as below. (This is my vision, I would appreciate any comments, if there's something wrong with it. I'm not a native english speaker, so wording might need to be changed too.)
> 
> IMO, Compiling such a small tutorial would be VERY helpful for beginners.
> 
> -= How to understand D access control if you know java access control =-
> 
> 1) D allows multiple classes per compilation unit. Just for a minute imagine it WOULD NOT allow to do so. This way D source code layout would be exactly the same as in java. At this level, a 'package' in D terminology corresponds to a 'package' in java terminology.
> 
> 2) rename 'protected' atribute in java code to read 'package'.
> 
> ----- After these 'changes' java logic and syntax for access control
>       has been 'translated' to D.
>       Further is what makes D a more flexible language in
>       terms of access control.
> 
> 3) add 'protected' attribute with a new meaning of allowing
> _only derived_ classes to access the corresponding members.

B.G. wrote:
> Hasan Aljudy wrote:
> 
>> B.G. wrote:
>>
>>> Question to strict OOPlers.
>>>
>>> <snip>
>>>
>>> - Where I'm not 100% sure, is the question whether visibility of everything to everything (including private) inside a module is a good practice. Is there analogous behavior in other languages? Are there any negative experiences because of that? Any suggestions?
>>
>>
>>
>> Well, the way I see it right now, a module acts as a class, in terms of "private" and "public" attributes atleast.
>> This is ok if a module is meant to be a way of encapsulating related data or some thing like that, but that's not very clear to me, I was assuming a module is just a file like a cpp file, and that the module concept was introduced to eliminate the need for .h files.
> 
> 
>> The way things are built now, a module should only contains one class, having it contain more, is like mixing several classes into one class, since every method would have access to every member variable across all the classes.
> 
> Errr, AFAIK a module can contain any nuber of classes, that's the difference with java. Perhaps it's just the STYLE many developers have chosen to put every class into a separate module. Did I miss something???
> 

That's not what I mean .. you can techncally put as many classes in a single file as you want, but the current concept of a module suggests that a good coding practice is to put every class in its own file, except for those cases when you have to hack things.

Like a class, good practices suggest that a class should be cohesive, so it does not make sense to make the class responsioble for two totally different tasks (like drawing images on the screen, and sending data over the network).
So in the same sense, a module has to be cohesive, it does not make sense to put two totally seperate classes in one module (like a player class and a buffer class).

Of course, you can go ahead and put everything in one huge class, just the same way as you can go ahead and put everything in one big module, but that would just be bad bad code.

> > Just because elements in the same file
> > have private-access doesn't mean you /have/ to write code that toys
> > with them?
>the private attribute is supposed to prevent other classes from coupling
>to my data, as it triggers a compiler error. There are practical reasons
>for that.
>When this attribute becomes useless, then the code will compile with no
>errors. Which means I could have what would be considered an error, but
>the compiler will not notify me about it.
>This is why I would /have/ to write classes in different files ..
>becuase I don't want to just hack some code together to make something
>"work".

Private is ment to hide implementation details. Some language hide per class, others per hierarchie, D per module.


>Again, that's not exactly the point, even if it didn't limit my
>freedome, it'd still be bad, becuase friend is not something very
>usefull that always comes up in projects, it's really just a "hack" that
>shouldn't really be used, and when it does get used, it must be used
>with extreem care.
>I just don't see any reason to make it implicit.

It is exmplicit. You explicitly put two classes into one file. This doesn't happen implicitly!

Anyway friend in C++ is meant to improve encapsulation not to violate it as you claim it would. Think about the alternatives. Eigther you can allow one class (only one) to access some private attributes, if this class realy needs to. The alternative is to use a public methods to access this variable, so all (not only one) class can access this attribute.

>Yeah, I don't know what's wrong with the current here, maybe this issue
>is irrelevant for people who don't really do OOP, but lemme put it this way:
>D is *not* a procedural-only language, it's not "C", OO is important
>people!! there are reasons for making things private, the simplest of
>them is to reduce coupling.

Why is OO more important than other paradigms? This way of programming is way to
limited.
E.g. using delegates is simpler and way more convenient than using things like
the observer pattern, command pattern, ... but it's 'not as OO'. So should we
stop using them?

>Information hiding, encapsulation, high cohesion and low coupling are all desirable, so why make it so easy to voilate them? This encourages bad coding practices.

Well there are many ways of acheaving this. e.g. component orientation.

OR look at the SML module system. No OO at all, but you can easily achive information hiding, encapsulation, and low coupling.


>See, it's not just to prevent errors, but I think we should *not* encourage bad coding practices by making them so easy. They should atleast require some explicit declaration.

So over oo-engeniring should be prevented by the language?

>C++ is already hated by many OO junkies becuase it's so easy to just break all the OO rules, why would D carry out the same faults of C++?

Leave that junkies allown. Junkies aren't good for you.

>If you look at some C++ projects, you'll see alot of bad coding styles (e.g. abuses of friends and protected) .. why is that? becuase C++ allows you to do that!

No, because C++ is a very complicated language that is hard to realy understand. Most peaople using it don't realy understand it. That's why they use it wrongly.

>When you make it so easy for people to write OO code then voilate OO rules, you can be sure that people are gonna use the features that voilate the rules of what's considered to be good coding style, and this will only give D a bad reputation, as a language that is not good for OOP.

Bad coders stay bad coders. They can use something like VB.net instead.
If the language prevents you from too many things it prevents beginners to write
bad code, but it prevents good programmers from wrting good code as well.


>People who don't really write OO code probably won't realize the point of this, but people who do OO all the time do realize it, I don't think this "feature" of D will appeal to many of them.

I do a lot of OO-programming.

>D is suposed to be *practical* and simple, but this does not mean it
>should provide simple ways of writing bad code .. becuase this totally
>contradicts the "practical" part. If it's easy to write bad code, then
>the language is probably not that practical.
>In my opinion, if you want an easy way to break encapsulation, just make
>everything public, or don't write OO code.

Well, if two classes are defined in two different modles it is impossible to break encapsulation. But impossible isn't easy, is it?

I don't want to make everything public and I do want to write OO code. But this doesn't conflict in any way with D's access concept.