"Diez B. Roggisch" <de...@nospam.web.de> > 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?
No. Not airy. Hairy, yes. I suppose the language is a kind of wish list on my part - I have spent the last twenty years or so writing stuff like this on small processors, in assembler, and I would have loved a language that supported it, as well as an operating system (and I do not mean stuff like tiny os and others of that ilk), but one that really supported fast task switching to make the micro tasks less expensive on cheap little processors with scarce resources. (8031) I have written various flavours of my own, (pre emptive, round robin, cooperative) and they all suffer from the speed troubles associated with task switching on that architecture, but in all cases the performance was good enough to get the job done. Most of the stuff really did follow a dataflow model as I have described, but its all so inextricably intertwined with the hardware and the requirements of the different jobs that it feels kind of hopeless to try to extract general principles from it, except for obvious stuff like that it works better if your queues are formal and robust, and that the messages must contain everything that is required to get the job done. If you do this, then there is really no reason to worry about how some other thing is doing it's job. In fact if you find yourself peeking at the other task's innards, then it means you have to rethink the dataflow, because you are on the wrong track - that is what I meant when I talk of "granularity" I have find that code re use, between different projects, has in my case been limited to some parts of: - Task switching code - The ticker structure to interface to hardware - Queues, buffers and memory management. - Utility functions like some simple math and string handling. Anyway this is getting a bit far away from the python way, which does not strictly enforce the 'Pure Path' (Tm) of: - have loose objects as threads/processes - send messages between them using clever queueing So we are extremely unlikely to agree on the importance of enforced data hiding. :-) - Hendrik -- http://mail.python.org/mailman/listinfo/python-list