home *** CD-ROM | disk | FTP | other *** search
- Newsgroups: comp.sys.next.misc
- Path: sparky!uunet!microsoft!hexnut!edwardj
- From: edwardj@microsoft.com (Edward Jung)
- Subject: Re: Why, Why, WHYYYY?? USE OBJECTIVE-C for IB??
- Message-ID: <1992Dec13.100829.27279@microsoft.com>
- Date: 13 Dec 92 10:08:29 GMT
- Organization: Strategy Division, Microsoft Corp.
- References: <dillon.0s9m@overload.Berkeley.CA.US> <1992Dec7.122138.389@uunet!cbmvax!xmws!kripalu> <dillon.0sh6@overload.Berkeley.CA.US>
- Lines: 45
-
- Matthew Dillon writes:
-
- > I should mention that a strong run-time system cannot be optimized
- > easily (or at all) whereas a strong compile-time and load-time system
- > can both be optimized AND handle interface portability concerns without
- > any run-time system getting in the way, but that generally entails
- > building part of the compiler into every machine to handle
- > 'installation' (integration) of an application. C++ has yet to reach
- > this capability and may never do so as it insists, as most languages
- > do, on sticking to a strict compile time paradigm.
-
- In fact I would argue that the interface run-time should be
- completely language-independent as well as very fast. As Matthew
- points out, a compile and load oriented system such as fast
- RPC interfaces is advantageous. What this means is that in
- local bindings between code and an externally-supplied module
- (or "software IC"), the performance hit can be as small as
- a single register or memory indirection -- less if you are
- willing to do relocation on load (just depends where you want
- to spend your CPU cycles and when). When you go cross-machine,
- you convert to a messaging system using standard RPC techniques.
-
- Objective-C and the NeXT run-time always use messaging, and
- perform language-specific optimizations for in-process
- invocation. The messaging system also brings synchronization
- issues in multi-threaded environments since the message
- encapsulates synchronization semantics whereas compiler
- invocations do not. The developer that therefore writes
- a software component must use messaging, think about
- thread safety in the client run-time, and therefore
- worry about distribution transparency (i.e. where the
- component code runs).
-
- Issues such as how to write a reusable and distributable
- component should really not be addressed in a language.
- They should be addressed as an infrastructure for an object
- system that is language independent. Then you can worry
- about language bindings and new languages that are semantically
- identical to the object system's model. It is hard to imagine,
- esp. given the religion on languages, that any one language
- will meet all needs.
-
- --
- Edward Jung, Software Architect edwardj@microsoft.com
- Advanced Systems, Microsoft Corp.
-