|
![](/i/fill.gif) |
Darren New <dne### [at] san rr com> wrote:
> > That's the whole idea in modular thinking: You don't know what's inside
> > the module, and you *don't care*. You don't need to care.
> It also prevents code from *inside* the module from doing certain things in
> an easy way.
Everything in the class is public to the class itself. I don't understand
your point.
> >> If it's half-enforced, as in the compiler complains and won't compile the
> >> code, but there's ways to get around it anyway (on purpose or by mistake),
> >> then it's IMO the worst of all possible worlds. You'll spend hours or days
> >> trying to debug code that's already right because the client is convinced
> >> the other code they've written is bugfree and it's easier to blame you than
> >> to find the wild pointer in their own code. The whole idea of class
> >> invariants goes out the window.
> >
> > No you'll explain to me how a naming convention of public variables helps
> > this problem.
> The naming convention doesn't help that. The safety of the language helps
> that. In other words, what helps it is not the naming convention, but the
> fact that code that accesses private variables *must* use the naming
> convention to do so.
So your solution to the problem of being able to modify private members
by accident because of the language being unsafe is to make the language
safe... and to make everything public (with a naming convention of
variables).
I don't see how the latter follows.
> I'm just less worried about intentionally violating modularity than
> accidentally doing so.
Problems with programming errors in unsafe languages has nothing to
do with the subject of modularity.
Accessing something out of boundaries by accident is always a bug
regardless of what effects that has. This has nothing to do with whether
modularity is a good thing or not.
> (I've had server code written in unsafe languages where it would dump core
> on a segfault, and the providers wanted to blame it on the fact that the Xen
> kernel was on the machine. We weren't booting Xen, but they wouldn't even
> look at their code until we uninstalled that kernel. Just as an example of
> how people can avoid admitting their own bugs might be part of the problem.
And this has what to do with the original subject?
You always succeed in returning to your favorite subject: Bashing
"unsafe" languages. And in your world there's only one such language: C++.
--
- Warp
Post a reply to this message
|
![](/i/fill.gif) |