XPost: alt.os.development   
   From: mailbox@dmitry-kazakov.de   
      
   On Wed, 15 Feb 2006 03:59:11 +0300, Maxim S. Shatskih wrote:   
      
   >> pattern-matching based search for a file isn't fuzzy to me. BTW, a modern   
   >> OS should have no files, but objects and containers of objects.   
   >   
   > This looks utopic for me :-). Just imagine the backup tools for such an OS   
   :-).   
      
   That is exactly the point. Backup is a too high-level concept to work on   
   file basis. Complex things, such as user-profiles and application settings,   
   cannot be properly mapped onto files. Files don't know each other, they   
   don't know how to copy themselves. Objects do. With an OO (ADT) approach   
   you put interesting objects in a container and make a deep copy of that   
   container. This is no different from backing up a volume, which is just a   
   file container. But much better is to use all the benefits of OO view. Make   
   settings an object and copy it.   
      
   > The OS must still have the "blockwise volume" paradigm,   
      
   Yes, perhaps with one layer more. [Some new OS development projects add a   
   versioning DB layer.] But this is an implementation detail, same as it   
   always was. You always had low-level device block I/O, and a higher level   
   file system I/O.   
      
   > over which the "file"   
   > paradigm is built, over which the "object" and "container" paradigms are   
   built.   
   > The apps can operate at the level they want.   
   >   
   > Hiding the files at all will cause major headaches   
      
   Not hiding, getting rid of! (:-)) Note that objects will be memory-mapped,   
   so there will be no any place to keep files. All blocks of all devices will   
   be addressable in 64- or 128-bit virtual address space. That's IMO the way.   
      
   >. Even now the question of   
   > "how to move my Outlook Express data to another computer?" is rather complex   
   -   
   > and OE is a good sample of the app using the OO structures inside the files.   
      
   Right, because it is *file* based. Outlook Express settings should be an   
   object with the interface method "Copy". End of story.   
      
   > Pure OO paradigm is great on paper and is hardly compatible with the real   
   life.   
   > "The paper is smooth, but the real site has canyons".   
      
   So far nobody really tried, AFAIK.   
      
   1. There are technical and theoretical problems with OO languages. Many   
   things (multiple dispatch, multiple inheritance, ad-hoc supertypes,   
   extensible active objects (tasks), extensible protected objects) are quite   
   difficult. Basically nobody knows how to do them right. And this is just on   
   the language level.   
      
   2. Even if there were a good OO language supporting advanced ADTs, OS would   
   require something more. Present types systems are co-operative. You can   
   call a private method even if you no right to do it. For an OO OS one would   
   need a memory access based protection of dispatching tables and private   
   members. That is another problem to solve.   
      
   3. Yet another problem is fragility of dispatching mechanism. Small changes   
   in interfaces require full recompilation, which in terms of OS would mean a   
   monolithic Windows-like system to reboot on any change.   
      
   4. Further, it is clear that the OS have to be distributed and   
   heterogenous. Here again there are lot of problems. [Clearly Java or C#   
   isn't the answer.]   
      
   --   
   Regards,   
   Dmitry A. Kazakov   
   http://www.dmitry-kazakov.de   
      
   --- SoupGate-Win32 v1.05   
    * Origin: you cannot sedate... all the things you hate (1:229/2)