www.digitalmars.com         C & C++   DMDScript  

digitalmars.D - implicit "friend" is wrong (opinion)

reply Hasan Aljudy <hasan.aljudy gmail.com> writes:
I was kind of surprised to see that all classes in the same file have 
access to each others private parts (pun intended).

The rationale was: "In D, friend access is implicit in being a member of 
the same module. It makes sense that tightly related classes should be 
in the same module, so implicitly granting friend access to other module 
members solves the problem neatly".

Well, it does "makes sense that tightly related classes should be in the 
same module", but it does not make sense the other way aorund.
It does not make sense that classes in the same file should be tightly 
coupled .. this is a matter of style. I personally don't like creating a 
file for everyting single class even if it's only 5 lines long, so I put 
them all in one file; this doesn't mean that I want them to be friends 
and have access to each other's private fields.

I wouldn't mind if these friends only had access to "protected" fields 
.. but private? that's upsetting.

This "friend" thing is considered bad anyway, why should it be implicit? 
I think it should always be explicit. It's not something that people 
want to do all the time, quite the opposite, it's something that people 
shouldn't be doing.

I don't see how making "friend" implicit solves any problem .. on the 
contrary, I think it creates one: now it's more like java, every class 
should have its own file. kind of limits my freedom, I don't like that.
May 10 2005
next sibling parent reply Chris Sauls <ibisbasenji gmail.com> writes:
Hasan Aljudy wrote:

 I don't see how making "friend" implicit solves any problem .. on the 
 contrary, I think it creates one: now it's more like java, every class 
 should have its own file. kind of limits my freedom, I don't like that.


How does it limit your freedom?  Just because elements in the same file 
have private-access (actually its better to say they have total access, 
the protection attributes just don't matter within the module, only 
outside) doesn't mean you /have/ to write code that toys with them?  Its 
your module, meaning its your code, meaning you are free to do whatever 
the heck you want.  Isn't that the definition of freedom?  I fail to see 
how this creates any problems at all.  But perhaps its just different 
milage.

-- Chris Sauls
May 10 2005
next sibling parent "Andrew Fedoniouk" <news terrainformatica.com> writes:
"Chris Sauls" <ibisbasenji gmail.com> wrote in message 
news:d5r183$1n5p$1 digitaldaemon.com...

 Hasan Aljudy wrote:

 I don't see how making "friend" implicit solves any problem .. on the 
 contrary, I think it creates one: now it's more like java, every class 
 should have its own file. kind of limits my freedom, I don't like that.


 How does it limit your freedom?  Just because elements in the same file 
 have private-access (actually its better to say they have total access, 
 the protection attributes just don't matter within the module, only 
 outside) doesn't mean you /have/ to write code that toys with them?  Its 
 your module, meaning its your code, meaning you are free to do whatever 
 the heck you want.  Isn't that the definition of freedom?  I fail to see 
 how this creates any problems at all.  But perhaps its just different 
 milage.



Agreed on 100% percent.

Andrew.
May 10 2005
prev sibling parent reply Hasan Aljudy <hasan.aljudy gmail.com> writes:
Chris Sauls wrote:

 Hasan Aljudy wrote:
 

 I don't see how making "friend" implicit solves any problem .. on the 
 contrary, I think it creates one: now it's more like java, every class 
 should have its own file. kind of limits my freedom, I don't like that.


 
 
 How does it limit your freedom?  Just because elements in the same file 
 have private-access (actually its better to say they have total access, 
 the protection attributes just don't matter within the module, only 
 outside) doesn't mean you /have/ to write code that toys with them?  Its 
 your module, meaning its your code, meaning you are free to do whatever 
 the heck you want.  Isn't that the definition of freedom?  I fail to see 
 how this creates any problems at all.  But perhaps its just different 
 milage.
 
 -- Chris Sauls


Well, first of all, that's not exactly the point.
Secondly, it limits my freedom because I want to write OO code, if 
"private" becomes useless inside a file, then the only way to write good 
OO is to make new files for new classes. I want to write multiple 
classes inside one file, without having to worry about coupling (aka 
voilation of encapsulation).


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

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.
May 10 2005
next sibling parent "Ben Hinkle" <bhinkle mathworks.com> writes:
"Hasan Aljudy" <hasan.aljudy gmail.com> wrote in message 
news:d5r54s$1ra2$1 digitaldaemon.com...

 Chris Sauls wrote:

 Hasan Aljudy wrote:


 I don't see how making "friend" implicit solves any problem .. on the 
 contrary, I think it creates one: now it's more like java, every class 
 should have its own file. kind of limits my freedom, I don't like that.



 How does it limit your freedom?  Just because elements in the same file 
 have private-access (actually its better to say they have total access, 
 the protection attributes just don't matter within the module, only 
 outside) doesn't mean you /have/ to write code that toys with them?  Its 
 your module, meaning its your code, meaning you are free to do whatever 
 the heck you want.  Isn't that the definition of freedom?  I fail to see 
 how this creates any problems at all.  But perhaps its just different 
 milage.

 -- Chris Sauls


 Well, first of all, that's not exactly the point.
 Secondly, it limits my freedom because I want to write OO code, if 
 "private" becomes useless inside a file, then the only way to write good 
 OO is to make new files for new classes. I want to write multiple classes 
 inside one file, without having to worry about coupling (aka voilation of 
 encapsulation).


D is designed to be practical and simple. So the question is "what is a 
practical and simple way to break encapsulation"? C++ does it with "friend". 
Java doesn't allow it at all. D does it with modules. Obviously breaking 
encapsulation shouldn't be allowed for arbitrary customer code that uses a 
class. Code in the same module is not customer code and is not even code 
that is likely to abuse the other code in the module. Hence the module 
becomes a practical solution to the problem of how/when to break 
encapsulation.  I don't think it violates OO.


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


how large are your modules? They are probably pretty big if private 
variables get lost/abused in them.


 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.


That's a perfectly fine opinion to have, but have you in practice ever 
caught an error where you were abusing a private property in the same 
module? The only time I can think of where I would have noticed is when a 
subclass of std.stream.Stream was using a private variable that should have 
been protected instead. I changed it to protected just in case someone 
outside the module needed it.
May 10 2005
prev sibling parent Matthias Becker <Matthias_member pathlink.com> writes:
 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.
May 11 2005
prev sibling next sibling parent Derek Parnell <derek psych.ward> writes:
On Tue, 10 May 2005 12:24:03 -0600, Hasan Aljudy wrote:


 I was kind of surprised to see that all classes in the same file have 
 access to each others private parts (pun intended).
 
 The rationale was: "In D, friend access is implicit in being a member of 
 the same module. It makes sense that tightly related classes should be 
 in the same module, so implicitly granting friend access to other module 
 members solves the problem neatly".
 
 Well, it does "makes sense that tightly related classes should be in the 
 same module", but it does not make sense the other way aorund.
 It does not make sense that classes in the same file should be tightly 
 coupled .. this is a matter of style. I personally don't like creating a 
 file for everyting single class even if it's only 5 lines long, so I put 
 them all in one file; this doesn't mean that I want them to be friends 
 and have access to each other's private fields.
 
 I wouldn't mind if these friends only had access to "protected" fields 
 .. but private? that's upsetting.
 
 This "friend" thing is considered bad anyway, why should it be implicit? 
 I think it should always be explicit. It's not something that people 
 want to do all the time, quite the opposite, it's something that people 
 shouldn't be doing.
 
 I don't see how making "friend" implicit solves any problem .. on the 
 contrary, I think it creates one: now it's more like java, every class 
 should have its own file. kind of limits my freedom, I don't like that.


I can't see anything wrong with your reasoning here. I have to agree with
you. There is no necessary reason that the physical location of a class
(i.e. in a specific file) should cause it to automatically have access to
private members of another class, regardless of where that other class is
located. 

However, as an arbitrary device, implemented to avoid an extra keyword for
a commonly (misused?) coding style, it is a neat solution. But a side
effect of this design decision is that it forces a particular coding style
on all D coders - namely that if you want/need to have truly private
members in a class, you are forced to have them in different files. 

The solution, which is to allow both coding styles to exist, seems simple
enough. I would suggest that a keyword be used as an attribute of the
'module' statement to indicate to the compiler that classes in this module
cannot see private members of other classes in the same module. Maybe
something like ...

  private module myclasses;

-- 
Derek Parnell
Melbourne, Australia
BUILD v2.07 is now available. 07/May/2005
http://www.users.bigpond.com/ddparnell/build/download.html
11/05/2005 6:55:19 AM
May 10 2005
prev sibling next sibling parent Andy Friesen <andy ikagames.com> writes:
Hasan Aljudy wrote:

 I was kind of surprised to see that all classes in the same file have 
 access to each others private parts (pun intended).
 
 The rationale was: "In D, friend access is implicit in being a member of 
 the same module. It makes sense that tightly related classes should be 
 in the same module, so implicitly granting friend access to other module 
 members solves the problem neatly".
 
 Well, it does "makes sense that tightly related classes should be in the 
 same module", but it does not make sense the other way aorund.
 It does not make sense that classes in the same file should be tightly 
 coupled .. this is a matter of style. I personally don't like creating a 
 file for everyting single class even if it's only 5 lines long, so I put 
 them all in one file; this doesn't mean that I want them to be friends 
 and have access to each other's private fields.
 
 I wouldn't mind if these friends only had access to "protected" fields 
 .. but private? that's upsetting.
 
 This "friend" thing is considered bad anyway, why should it be implicit? 
 I think it should always be explicit. It's not something that people 
 want to do all the time, quite the opposite, it's something that people 
 shouldn't be doing.
 
 I don't see how making "friend" implicit solves any problem .. on the 
 contrary, I think it creates one: now it's more like java, every class 
 should have its own file. kind of limits my freedom, I don't like that.


I don't think it's such a big problem because, frankly, I don't care all 
that much about access specifiers within my own code.

I use access modifiers to control how *other* code uses my API.  This is 
important because my unit tests can't do anything to protect me if that 
other code starts mucking around implementation details.

  -- andy
May 10 2005
prev sibling next sibling parent reply "Tony" <talktotony email.com> writes:
"Hasan Aljudy" <hasan.aljudy gmail.com> wrote in message
news:d5qu7o$1kq9$1 digitaldaemon.com...

 I was kind of surprised to see that all classes in the same file have
 access to each others private parts (pun intended).

 The rationale was: "In D, friend access is implicit in being a member of
 the same module. It makes sense that tightly related classes should be
 in the same module, so implicitly granting friend access to other module
 members solves the problem neatly".

 Well, it does "makes sense that tightly related classes should be in the
 same module", but it does not make sense the other way aorund.
 It does not make sense that classes in the same file should be tightly
 coupled .. this is a matter of style. I personally don't like creating a
 file for everyting single class even if it's only 5 lines long, so I put
 them all in one file; this doesn't mean that I want them to be friends
 and have access to each other's private fields.

 I wouldn't mind if these friends only had access to "protected" fields
 .. but private? that's upsetting.

 This "friend" thing is considered bad anyway, why should it be implicit?
 I think it should always be explicit. It's not something that people
 want to do all the time, quite the opposite, it's something that people
 shouldn't be doing.

 I don't see how making "friend" implicit solves any problem .. on the
 contrary, I think it creates one: now it's more like java, every class
 should have its own file. kind of limits my freedom, I don't like that.


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
May 10 2005
next sibling parent reply Derek Parnell <derek psych.ward> writes:
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
May 10 2005
parent "Tony" <talktotony email.com> writes:
"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
May 11 2005
prev sibling next sibling parent reply Hasan Aljudy <hasan.aljudy gmail.com> writes:
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


Hehe, Thanks.
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.
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.

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.

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++?
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!
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.

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.
May 10 2005
next sibling parent reply Mike Parker <aldacron71 yahoo.com> writes:
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.
May 11 2005
parent Hasan Aljudy <hasan.aljudy gmail.com> writes:
Mike Parker wrote:

 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.


Actually, hiding implementation details from people who use my code is 
the least of my concerns .. I personally like to share knowledge, and I 
think information about the implementation details should be provided 
for those who want to know.

Really, the purpose of making things private and public is to increase 
cohesion and reduce coupling, which in turn makes the code more 
maintainable.
It's not important whether those who use the code know the 
implementation details or not, the important thing is to minimize 
coupling.. so instead of coupling directly to the data, you couple to 
the interface.

Yes, it's a coding standard, but language features (imo) should 
encourage good coding standards.
Which is why there is a "private" keyword in the first place .. there is 
nothing preventing you from making everything public, and nothing in the 
language features prevents the compiler from compiling a code that 
accesses private class members. I mean, it's not like a code that 
accesses private fields is code that cannot be compiled, it's just that 
the compiler will not compiler it for you.

It's just a coding standad, enforced by the language features.
May 11 2005
prev sibling parent reply Matthias Becker <Matthias_member pathlink.com> writes:
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.
May 11 2005
parent reply Hasan Aljudy <hasan.aljudy gmail.com> writes:
Matthias Becker wrote:

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?
 


I didn't say it's more important than something else, I'm just saying it 
is important.
OO is not simple, it's complex, but once you setup the code correctly, 
the complexity of the code won't increase that much when the complexity 
of the problem increases.
With other alternatives, the complexity of the code incrreases 
(explonentially, might I say) as the complexity of the problem increaes.


 

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.
 


Cohesion and Coupling were actually conceptualized for procedural 
programming ..
Again, I didn't say that these concepts are only possible through OOP, 
but they are a big part of OOP.

You don't have to write OO code if you don't want to, but this doesn't 
mean that the language can provide poor support for OO. (I'm  not saying 
that D's suport for OO is poor, I'm just talking hypothatically)



 

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?
 


I didn't say anything about "preventing", all I'm saying is that things 
that would be considered bad coding poractices shouldn't be encouraged 
by making them implicit.
I'm not saying don't allow them, just let them require some explicit 
statement.


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.
 


D is supposed to be a re-engineering of C and C++, so things that are 
considered bad shouldn't be carried out the same way.


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.


How is it that not understanding the language pushes the programmer to 
make many classes friends of each other?


 

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.
 


Don't prevent it, just make it require an explicit statement.


 

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'm talking about implicit friendship among classes that are in the same 
module. what you talking about? dude ...
May 11 2005
parent reply Matthias Becker <Matthias_member pathlink.com> writes:
I'm talking about implicit friendship among classes that are in the same 
module. what you talking about? dude ...


Some languages use keywords, this language uses modules for "friendship". Both
is explicit. The language can't implicitly move two classes into one module. You
allways have to manually place the classes into modules.
May 12 2005
parent Hasan Aljudy <hasan.aljudy gmail.com> writes:
Matthias Becker wrote:

I'm talking about implicit friendship among classes that are in the same 
module. what you talking about? dude ...


 
 
 Some languages use keywords, this language uses modules for "friendship". Both
 is explicit. The language can't implicitly move two classes into one module.
You
 allways have to manually place the classes into modules.
 
 
 


ok ... um, there is no need to go philosophical, hehe, this is rediclious.
Friendship /_*IS*_/ implicit.

quote: http://www.digitalmars.com/d/cpptod.html#friends
The D Way
In D, friend access is implicit in being a member of the same module.
/quote

Of course the programmer has to do something to trigger this 
"implication", but it's still implicit.

in C++, you can do something like:
code:
long x = ...
short e = ....

..

e = x;
/code
here, there is an implicit conversion form long to short.
one can argue that it's not implicit because the coder explicitly said 
that he wants to assign a long value to a short variable, but that is 
just BS, the conversion here happens implicitly, becuase the coder 
didn't explicitly state that he wants to convert a long to a short.

Java doesn't allow you to do that, you have to explicitly cast x to short.

I hate philosophy.

This kind of argument can never end, so please stop it.
May 12 2005
prev sibling parent reply "B.G." <gbatyan gmx.net> writes:
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?
May 10 2005
parent reply Hasan Aljudy <hasan.aljudy gmail.com> writes:
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.
May 10 2005
parent reply "B.G." <gbatyan gmx.net> writes:
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.
May 11 2005
next sibling parent xs0 <xs0 xs0.com> writes:
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.
May 11 2005
prev sibling parent reply Hasan Aljudy <hasan.aljudy gmail.com> writes:
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.
May 11 2005
parent reply Mike Parker <aldacron71 yahoo.com> writes:
Hasan Aljudy wrote:


 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.


It doesn't suggest that to me.


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


How is that a problem? Several related classes in the same module, 
several related modules in the same package. If you don't want two 
classes being friendly (i.e. having access to each others private parts) 
as a design decision, then they likely don't belong in the same module.

D is not C++. One does not implement a design in Java the same way one 
would in C++, simply because the language features are so different. 
It's the same with D. Just because you would implement a design one way 
in C++ does not mean that's the way you should implement it in D. Look 
at the features you have available and use them to implement your design 
accordingly. When using D, think in D.
May 11 2005
parent reply Hasan Aljudy <hasan.aljudy gmail.com> writes:
Mike Parker wrote:

 Hasan Aljudy wrote:
 

 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.


 
 
 It doesn't suggest that to me.
 


<snip>

 How is that a problem? Several related classes in the same module, 
 several related modules in the same package. If you don't want two 
 classes being friendly (i.e. having access to each others private parts) 
 as a design decision, then they likely don't belong in the same module.
 


Classes should generally never be friends, if you need some classes to 
be friends, there's probably a flaw in the design.
it's not related classes that should be in the same module .. it's 
classes that are "tightly _coupled_", the keyword here is "coupling".
Design should attempt to reduce coupling, not introduce it.
Of course, it's the programmers decision to make, but good design should 
need to put each class in its own module.
May 11 2005
parent reply Mike Parker <aldacron71 yahoo.com> writes:
Hasan Aljudy wrote:


 Classes should generally never be friends, if you need some classes to 
 be friends, there's probably a flaw in the design.
 it's not related classes that should be in the same module .. it's 
 classes that are "tightly _coupled_", the keyword here is "coupling".
 Design should attempt to reduce coupling, not introduce it.
 Of course, it's the programmers decision to make, but good design should 
 need to put each class in its own module.


Whatever term you use, it shouldn't make a difference within the same 
module. Tightly coupled designs are inflexible and a bear to rework, but 
unless you have a monolithic module (your whole app is in one module - 
yuck) then having classes within a module that are tightly coupled hurts 
nothing in the big picture. External modules still have access to 
whatever interface you choose to expose and don't know or care how 
loosely or tightly coupled classes are underneath.

I understand what you are saying, but I think that the module concept 
adds a finer level of detail where you can violate your 'rules'. The 
module is not a client of itself, so it classes within it need not treat 
each other like strangers. If you wish to drill down and apply the OO 
paradigm at that level, fine. I just down see the usefulness of it, and 
would very much prefer things to stay the way they are.
May 11 2005
parent reply Derek Parnell <derek psych.ward> writes:
On Thu, 12 May 2005 14:04:56 +0900, Mike Parker wrote:


[snip]

 I just down see the usefulness of it, and 
 would very much prefer things to stay the way they are.


I too think that the current semantics should remain. But in addition to
that, is there any valid argument to allow the other paradigm to be
utilized by a coder? In other words, what's so wrong with allowing a coder
to create a strictly 'private' module in which the contained classes cannot
see it's neighbors private areas?

Is it a bad idea to enable D to allow coders the choice of paradigms? 

-- 
Derek
Melbourne, Australia
12/05/2005 3:10:58 PM
May 11 2005
parent Mike Parker <aldacron71 yahoo.com> writes:
 I too think that the current semantics should remain. But in addition to
 that, is there any valid argument to allow the other paradigm to be
 utilized by a coder? In other words, what's so wrong with allowing a coder
 to create a strictly 'private' module in which the contained classes cannot
 see it's neighbors private areas?
 
 Is it a bad idea to enable D to allow coders the choice of paradigms? 
 


I have no objection to supporting both ideas. Distinguishing between 
'private' and 'module' protection is fine. I just wouldn't want to see 
the current behavior removed altogether.
May 12 2005
prev sibling next sibling parent "B.G." <gbatyan gmx.net> writes:
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.
May 10 2005
prev sibling next sibling parent reply Burton Radons <burton-radons smocky.com> writes:
Implicit friend was introduced before the "package" attribute was put 
in.  With that in there there's no longer any reason to have it work the 
way it does; "package" encapsulates all its functionality and doesn't 
interfere with most refactoring.

Eliding all the debate here, that's all it boils down to.  The utility 
for implicit friend - a weird left-field hack - is gone.  It should be 
removed.
May 11 2005
parent "Ben Hinkle" <ben.hinkle gmail.com> writes:
"Burton Radons" <burton-radons smocky.com> wrote in message 
news:d5td14$19ai$1 digitaldaemon.com...

 Implicit friend was introduced before the "package" attribute was put in. 
 With that in there there's no longer any reason to have it work the way it 
 does; "package" encapsulates all its functionality and doesn't interfere 
 with most refactoring.

 Eliding all the debate here, that's all it boils down to.  The utility for 
 implicit friend - a weird left-field hack - is gone.  It should be 
 removed.


Back when the "package" keyword was being debated I argued for a flexible 
syntax like extern but applied to private. So a "private(package)" 
declaration would be visible in the package (today called package), 
"private(module)" would be visible in the module, "private(subclass)" would 
be visible in subclasses (today called protected). By default private would 
keep the "private(module)" meaning. I didn't suggest it at the time but 
something like "private(class)" or "private(scope)" or something could give 
class or scope protection. There's no problem with introducing new 
protection levels since the identifier is not a keyword. Of course that 
suggestion wasn't implemented and a new keyword was added for "package".
That said it would be annoying to have nothing between "private(class)" and 
"private(package)", as you suggest. There must be some way to say 
"private(module)".
May 11 2005
prev sibling parent reply Derek Parnell <derek psych.ward> writes:
This is *not* rhetorical:

Is there any valid reason why anyone would need, or want, to place multiple
classes in the same file and ensure that those classes cannot see each
other's private information?

-- 
Derek Parnell
Melbourne, Australia
12/05/2005 6:33:05 AM
May 11 2005
next sibling parent reply Burton Radons <burton-radons smocky.com> writes:
Derek Parnell wrote:


 This is *not* rhetorical:
 
 Is there any valid reason why anyone would need, or want, to place multiple
 classes in the same file and ensure that those classes cannot see each
 other's private information?


- No other language with protection that I know of works in this manner, 
it's a great big and weird idiosyncracy.  A mature language shouldn't be 
different just because it can be.

- It interferes with object motility, trapping classes in a module. 
Protection does in general but particularly here.  Anything that makes 
refactoring difficult has got a lot to answer to, and a feature which 
has been superceded by an explicit method that works better doesn't even 
begin to have enough utility to warrant that.

- The language has some dodgy features that make enforced protection a 
good idea.  For example:

     class Foo
     {
         private int value;
     }

     void bar ()
     {
         float value;

         with (new Foo)
             value = 4;
     }

Depending upon where bar is located it might have different effects, but 
it will never give any indication that it does.
May 11 2005
parent Burton Radons <burton-radons smocky.com> writes:
Burton Radons wrote:


 Depending upon where bar is located it might have different effects, but 
 it will never give any indication that it does.


Ah, that's not true - it complains that it can't access the field if 
it's moved outside of the module, so depending upon the private 
implementation of an object, your with statement could suddenly stop 
working.  Eh, "with" sucks.  It should be:

    with ([type] <identifier>; <expression>) <statement>

It's just too dangerous a feature as it is.
May 11 2005
prev sibling next sibling parent Dejan Lekic <leka entropy.tmok.com> writes:
I totally agree on this - in same file naturally all classes should have
access to private parts of each other.

-- 
...........
Dejan Lekic
  http://dejan.lekic.org
May 12 2005
prev sibling parent reply James McComb <ned jamesmccomb.id.au> writes:
Derek Parnell wrote:

 This is *not* rhetorical:
 
 Is there any valid reason why anyone would need, or want, to place multiple
 classes in the same file and ensure that those classes cannot see each
 other's private information?


Here are my reasons:

[1]. By default, a class should not be able to see the data in another 
class (strict OOP says a class should encapsulate its data).

[2]. A programmer should not have the inconvenience of being allowed 
only one class in each file just so that they can enforce rule [1].

For example, I put several related classes into one file for 
convenience, and then suffer strict-OOP guilt, because my classes are 
not encapsulated from each other.

So I'm in favour of an explicit 'package' or 'module' access specifier. 
But I imagine Walter would be against it, because it makes it harder to 
throw together 'quick and dirty' apps.

James McComb
May 12 2005
parent reply Burton Radons <burton-radons smocky.com> writes:
James McComb wrote:


 So I'm in favour of an explicit 'package' or 'module' access specifier. 
 But I imagine Walter would be against it, because it makes it harder to 
 throw together 'quick and dirty' apps.


Why would they use access protection if they're quick and dirty?
May 12 2005
parent James McComb <ned jamesmccomb.id.au> writes:
Burton Radons wrote:

 James McComb wrote:
 

 So I'm in favour of an explicit 'package' or 'module' access 
 specifier. But I imagine Walter would be against it, because it makes 
 it harder to throw together 'quick and dirty' apps.


 
 
 Why would they use access protection if they're quick and dirty?


Quite right, I must have been confused. They'd just leave the access 
specifiers off altogether.

James McComb
May 12 2005