nemesis <nam### [at] gmailcom> wrote:
> >   So in your opinion the concept of "interface" is a verbal agreement about
> > what should and shouldn't be used from a module? *That* is what sounds like
> > bureaucracy to me.

> Not bureaucracy at all.  Just a list of names of functions a module 
> provides.

  I really fail to see how that is different from using a *real* interface
specification, rather than just a verbal one. Except for the fact that with
a real interface the compiler can make sanity checks, of course.

> >> For people who know it better, the lack of such measure does not mean 
> >> irrestrict access to things, it simply means less stupid typing to make 
> >> the compiler happy.  Modularity is conserved.
> > 
> >   In Utopia, maybe. In the read world, not so.

> Indeed.  In real enterprise world we got people who don't enjoy nor know 
> how to program, programming.

  Yes, and these people put everything in the public part of their classes
because they don't have any idea what they are doing. In the same way as
those self-taught hackers who detest all programming paradigms.

> >   And I don't consider having to write "private:" once to be significantly
> > more typing.

> Indeed, Delphi and C++ are yet more zippy at that, not so much for those 
> poor Java souls... you also forgot the data type declarations.

  In fact, in C++ you don't even have to necessarily write "private:" at
all because members are by default private (when not inside any access
specifier block).

> > If I had to document what you should and should not access
> > in the module, *that* would be significantly more typing.

> This coming from a guy whose favorite language needs for one to provide 
> the source and the header file.

  What source?

> >   Also, if I make a module for others to use, how can I guarantee that
> > I can change the implementation later without breaking code others have
> > written?

> Don't change the interface.  Of course, if the implementation is changed 
> in such a buggy way as to totally alter the behaviour, same interface 
> doesn't mean jack.

  Don't write such BS. I am talking about experience. For example I have
totally changed the internal implementation of this class of mine several
times, and the public interface has always remained the same regardless,
and thus the changes have never broken any existing code:

http://warp.povusers.org/FunctionParser/

  And by "totally" I mean literally write everything from scratch. And
no external code breaks. That's the nice thing about modularity. It allows
me to do that safely.

> >> It's all about scope.  If it's public, it should be used.  If it's not, 
> >> you shouldn't.
> > 
> >   And what's wrong with the compiler telling you if you try to use it
> > regardless? I really can't understand that.

> Nothing wrong except quite a few more tiresome and bureaucratic measures 
> before actually writing anything.

  Thinking that brevity in programming is a good thing is a really common
beginner mistake. Those are the beginners who, for example, in C++ always
write "using namespace std;" to dump *everything* in the standard libraries
to global namespace because it saves them from typing 5 extra characters
later. Then you get code like this:

    i = search(first1, last1, first2, last2);

  "Woohoo! I saved typing 5 characters!" And now it's completely unclear
what this "search()" is. Is it a local function somewhere? Is it an external
function defined in some header? Perhaps it's a class which is being
instantiated? Is it a standard library function?

  Compare to:

    i = std::search(first1, last1, first2, last2);

  Now it's completely unambiguous that this is a standard library function
being called.

  Brevity is *not* always the answer. Even if I had to write "private" in
front of every single function and variable declaration (as you have to do
in some languages), I would still do it. (Fortunately I don't have to.)

> >   The compiler is not limiting anything that you aren't *already* limiting
> > by your verbal agreement. The only thing the compiler is doing is checking
> > that the agreement is not broken. Why that is a bad thing is beyond my
> > comprehension.

> I was not saying that is bad.  I was just reacting to this:  "Your 
> definition of object-oriented programming may vary, but in my view
> data hiding, ie. modularity, is an integral part of OO programming."

> Modularity is still there regardless of dumb programmers ripping their 
> contracts and no middleman to prevent them doing so.

  I disagree. There's no modularity if you can't enforce access rights.
Data hiding is an integral part of modular design. Verbal agreements are
worth absolutely nothing.

-- 
                                                          - Warp

Post a reply to this message