Hendrik: > > I wonder why the designers of processors do such silly things as having > > user and supervisor modes in the hardware - according to your > > arguments a code review would solve the problem, and then they > > could use the silicon saved to do other usefull stuff. - then any process > > could use any instruction, and it would be all right. - easy to manage > > out of the project - you just have to scan the object code for op codes > > that you have decided are dangerous (for whatever stupid reason). > Diez: > This is comparing apples to oranges. Forced data encapsulation or not take > place *inside one process*. So this whole argument is a straw-man.
I do not agree with this, but then I won't will I? 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. I see almost any piece of code that "does something" as a black box that has inputs and outputs - and I like to string them together in a style that resembles a systolic array - closer to unix piping , based on true queueing and message passing, where it becomes at all practical. 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. 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. > 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. :-) - Hendrik ** -*an der Haare herbeigezogen* German, literally "drawn closer by the hair" expression denoting either a specious argument or a forced analogy. Sorry, but I could think of no English equivalent. -- http://mail.python.org/mailman/listinfo/python-list
