Darren New schrieb:
> clipka wrote:
>> Docman? Javadoc?
> 
> Were that helpful, it might fit the bill. :-)  As it stands now, it 
> seems more often an excuse to not write documentation than a tool for 
> writing it.

That's not a problem of the tool, but the person using it. Those people 
taking it as an excuse wouldn't do any docuentation at all otherwise, 
unless forced at gunpoint.

As far as making life easier for people who do have the honest desire to 
document properly, I think integrating the documentation with the source 
code is a good way to go, and docman and javadoc make good tools for hem.

Then again, maybe it's the approach taken from the wrong side, and the 
true proper way would be embedding the source code in the documentation, 
not vice versa - if only for the psychological effect.


>>  > To avoid security problems?
>> I guess this would require a proper definition of "security problems".
> 
> Code doing things the author didn't want it to do because malicious 
> people intentionally caused it to happen.

There's no general way around it, because malicious people of this type 
are highly intelligent and inventive. Whatever you'd integrate into the 
language itself would just give you a /false sense of/ security.

The only truly safe computer system would be an isolated computer locked 
in a stainless steel safe, with the key thrown into the Atlantic, and 
the safe sunk in the Pacific. Which would somewhat limit its usefulness 
I guess :-P

The only thing you can do about it is /defensive/ programming - but 
that's a paradigm you probably cannot support with language features I 
guess. Well, maybe stuff designed for contract-oriented programming 
would help with this.


> Stuff like the ability for me to know that my change hurt your code. 
> Something like unit testing, only built into the language, say.

That seems to go into a similar direction as contract-oriented design.


>> But it appears to me that as far as libraries are concerned, OOP has 
>> been a tremendous success regarding code re-use.
> 
> Ehn, to some extent. How many of the libraries you use would work just 
> as well without OO, or with faked OO (like C's stdio fakes OO)?

It's not a question of how well they would work - it's a question of how 
easy they were to implement, and how easy they are to use.

Try implementing and using generic container classes in a non-OO language.

Then try to refactor your application to use a deque container instead 
of a stack for a certain job. Or a tree-backed map instead of a 
hash-table-backed one someplace else.

You won't have much success without implementing verbosely what OO 
languages do for you behind the scenes.

Post a reply to this message