> The reason is that I see a level of abstraction that makes it kind of > irrelevant whether something is run as a process, a thread, a time > multiplexed mainloop, on one or more processors, wherever or > whatever - almost like a fractal structure spread across the total > addressable space - and I would like to use the same rules > everywhere. And if there are reasons for forced encapsulation > *somewhere*, then it is more elegant (to my taste) to allow it > *everywhere*. - and conversely, of course. Hence the rather > *an der Haare herbeigezogen* (see ** below) argument > based on the forced restrictions in processors.
Your argument would be valid if *any* of the *languages* implementing encapsulation would offer that real isolation. None does. So where from comes the feeling that this must be something a *language* should offer? Sure one could envision a system where each object is running in it's micro-process. So far, this hasn't been implemented (to the best of my knowledge) - so making assertions about the feasibility & robustness for running as well as for developing are somewhat "airy", don't you think? > Given this approach, there is no reason whatever for anything > to mess with any other thing's innards - in fact the less you know > about it, the more robust and predictable the system becomes. For a certain, very limited definition of robustness & predictability. As much as I like my OS not to go down, it's nothing that helps me to accomplish my actual goal using it if the software running on top of it crashes. From this POV, a chain is always only as strong as it's weakest member. And that might well be one of your encapsulated components. > And in embedded processes, there exist things that are time > critical, that are designed to be used in one way, and no other, > and that can have serious consequences if messed with- when > I have started moving the 100 tonne mass, then I *cannot* tolerate > other code changing my timeouts or speeds or feeds in an arbitrary > fashion - EXPENSIVE noises will result. Embedded programming most often even offers the memory protection one needs to make the "real" encapsulation, due to hardware restrictions. And even if it did, it won't help you with memory corruption that occurs in process. Which is of course a re-iteration of my argument. Again: the expensive noises haven't been avoided because of encapsulation. They might be the product of expensive testruns, either by trial-and-error, or by review. Not by encapsulation. >> I've seen a lot of programs segfault that are written in C++ with data >> encapsulation. And also a lot of them that overcame the restrictions the >> compiler or even runtime in java imposed on them, either by >> pointer-magic, or through some available backdoors that have been put in >> place for good reasons. > > I think that segfaulting is basically caused by programming error - > By the inability of the programmer actually to understand the > limitations of the compiler to "do what I mean". > > Encapsulation or data hiding will never "cure" that, because > at best it could move some of the errors from runtime to > compile time. > > I doubt the "good reasons for backdoors" part - I think that comes > from a design that has either not been done, or used, at the correct > level of granularity. > >> So far I haven't seen any argument for forced data encapsulation that >> went beyond a matter of personal taste. That's fine, but also just that. > > This could be true, and if it is, we are just beating our heads one > against the other, trying to win non existent prizes for pig-headedness. > > I could also turn that argument around, as well as stating it stronger: > > So far I have not seen any argument in favour of free access to > the internals of another piece of code that is based on ANY necessity, > (beside a handwaving "good reasons" ) or that goes beyond a matter > of personal taste based on a hacker's glee in meddling in somebody > else's code. The argument as apparent in Python: ducktyping is used everyday, to all our benefit. And every piece of code that only works precisely because it was possible to access the innards of some other piece of code is an example and a reason to allow it. You might say that these things are showing a lack of proper design - but the point is that design is a question of perspective, and a otherwise useful piece of code is rendered useless because of encapsulation if that prevents the usage from a new perspective the original author didn't think of. That's my stance on this, and as a coder, I want to (re)use code, not work around it. Diez -- http://mail.python.org/mailman/listinfo/python-list
