Warp escreveu:
> nemesis <nam### [at] gmailcom> wrote:
>> It's not because it's accessible that it is going to be used.
> 
>   Yeah, sure. If you are the *only* person making the entire program, then
> perhaps that might be the case.

Like I said, if the dumbass wants to use things not in the interface, 
it's his risk.

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

>> 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.  Or, should I say?, fill up a few forms and 
allow an IDE to generate the code.  It will spill shit all over, true.

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

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

 > And the kind of
 > text which most people will not read anyways.

It's usually the first thing one sees when opening a module.  (export 
foo bar boz frob etc)

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

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

>   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.  But I'm thinking 
here on a typical Scheme module of old, before true modules, and where 
all you had was a list of functions and lexical scoping, not a C plain 
text file with lots of variables and variable-dependent functions lying 
all around.

Post a reply to this message