Re: [Objex-developers] Objex planning
Status: Pre-Alpha
Brought to you by:
ert
From: Mikhail Z. <mh...@al...> - 2001-11-13 22:57:54
|
Hello Andrew, On Tue, Nov 13, 2001 at 03:21:54PM +0200, Andrew Lipnitsky wrote: > > > Do you guys have any more extended master plan? > > > Yes, This plan is in my mind ;-) Well, I hope your mind is generous enough to put your vision in a document eventually :) > > It would be very > > elucidative, e.g. to learn what that object system in CVS is for, > > > Did you mean objex-M1 branch? If so, these are rough drafts of system > objects > of future operating system Objex. Recently I have put there sources > (incomplete) > of main Objex objects: "Object", "Class", "Metaclass", "Operation" and > so on. > Please, take a look. These look like base classes for something. I have no further idea, as i've yet to see any implementation. The object system looks baroque compared to the C-based class/interface systems I'm used to, namely the CORBA C binding and GTK GObject). > > and > > how do you see processes interacting with the system. > > > There is no term of "process" in Objex. The main notion is Object. All > things are > objects. User's object will interact with system one by method > invocation. OK, but in terms of CPU execution there are protected contexts. Any security and authentication is manageable only to these contexts' granularity, because objects in the same address space can forge one another. Restricting each CPU context to represent exactly one object is totally impractical due to the cost of context creation and switching, so you have to maintain a notion of "processes", "domains", or whatever. > Every class is inherited from Object class. Object class has methods > which > return references to few system objects (for bootstrapping). So every > object has such methods. Has this any advantages over discoverability of interfaces a-la COM? -- Stay tuned, MhZ JID: mo...@ja... |