Xref: utzoo comp.object:1554 comp.lang.c++:8843 Path: utzoo!attcan!uunet!wuarchive!swbatl!jmd From: jmd@swbatl.sbc.com (Jim Doherty 5-0804 11-Y-03) Newsgroups: comp.object,comp.lang.c++ Subject: Re: Choice of language for manufacturing Applications Summary: Objective C and c++ distributed applications Message-ID: <1990Aug7.165255.5174@swbatl.sbc.com> Date: 7 Aug 90 16:52:55 GMT References: <26686@pasteur.Berkeley.EDU> <37938@ucbvax.BERKELEY.EDU> <5427@stpstn.UUCP> Organization: Southwestern Bell Tele. Co. - Advanced Technology Lab - St. Louis Lines: 122 In article <5427@stpstn.UUCP> you write: >In article <37938@ucbvax.BERKELEY.EDU> jbuck@galileo.berkeley.edu (Joe Buck) writes: >>In article <26686@pasteur.Berkeley.EDU>, lozinski@argon.uucp (Chris >>|> C++ is the computer scientists language where the focus is on >>|> technical aspects of the language. >> >>I don't see how Objective-C is any less a "computer scientist's language". > >Although I appreciate the attempt on both sides to clarify this cloudy >issue, I cringe whenever Objective-C and C++ are compared as *languages*. >My reason for building Objective-C was actually quite the opposite, in that >I've always viewed the Objective-C front end as more philosophically >aligned with yacc and lex (C attachments, rather than something that >competes directly with C). Since I have experience with both languages at a fairly detailed level (we have used both to drive switches) the real importance from our perspective is involved with how can we extend these languages to the next level of OOP. Today both languages do a good job of allowing you to send messages between objects in the same process space. However nether allows a messaging across process boundaries, yes I know this some may argue should not be part of the language, however since our goal is to create a commercial environment which allows both reusability and the capability to respond to market needs in a timely fashion we need to push the OOP paradigm across the entire environment. My work for the last three years has looked at this issues and we have come to some of the following conclusions. 1. OS changes are slow. 2. There is an extreme lack of software fault tolerance in the industry. 3. In order for large systems (ie switching) to be developed in a timely manner we need to build larger distributed systems. 4. The OOP paradigm provides the methodology to do this. We have recognized that the emergance of an OO Operating System will be some time in coming, (meaning commercial acceptance), in light of this we wanted to look at what capabilities are available today to do major distributed systems. (ie the telephone network is distributed) We then began looking at languages, ie (OOP) mainly for all the same reasons that many of you have are using languages. We came down to two languages Objective-C and c++. After doing some major implementations in both we have found they both hav there place and each does certain things extremely well. (we us both) I must tell you that our implementations of c++ tend to follow the smalltalk model rather closely. All objects in our systems inherit from an object called Adam (for biblical reasons). So when I discuss things later on keep this in mind. c++ because it could take liberty with the language itself, on aspect of c++ we have found extremely useful in certain aspects is that of operator overloading, a colleague of mine Stan Rishel has developed an OO interface to a relational data base that overloads the -> operator, this works quite naturally for the developer because the -> is what does the db call. Stan has also developed a scheme to store objects in the relational model which works quite naturally for us. (its real fast) Objective-C because it follows the smalltalk model of messaging is easily extendable across process spaces, for instance: when in OBJC you code [xxx xxx xx] this gets translated to a call to a routine called _msg(xxx xxx xx) this routine then looks in some hash tables to find the object and method you want to execute gets the addr of the function, then he removes the address of _msg from the stack and then begins execution of the desired code. Then when you return from the requested method you will return to the line just below the [xxx xxx xx]. Since Objective-C follow this model and provides you the source to the message kernel we made some modifications to the message kernel to add interprocess communications of objects. This we did without the knowledge of the developer. The basic methodology was as follows: 1. We let the message kernel determine if the method was internal to this process.(the normal mode) 2. if this failed (a normal runtime error) we intercepted the error and did a call to our external Object name server which all objects register with at initialization time. 3. we then returned the foreign address+site+incarnation as a handle to the requesting method, which now allowed the code in the original process to have a handle to t/w the other object. This is the handle method, which works quite well in medium to low traffic situations, and seems to be the only method to use when there is the possibility for updates. In read only type operations the copy method(ie you send a copy of the object) in a message to the requesting process space. The requesting proces space then can handle high volumes of traffic. 4. if this fails we then return the normal Objective-C runtime error with some additional information of ours. One item I have not mentioned yet is that in order to to accomplish the programs must be multi threaded, ie able to give up control in light of an external event (a message). to accomplish this we used a unique trick in the _msg code we also put in an accept_events() function call which in reality makes the program(object) multi threaded with out the programmer having knowledge of this. We also linked in a LWP lib (light weight process) in the linkage section. Now I hope this gives you some food for thought, because of the way Brad implemented Objective-C (i don't know if you thought of this at the time brad) adding interprocess communication can be done in a quite seamless manner. In c++ since messages do not flow through a common place implementation of this leads one to develop surrogate and possible a pre-processor to generate them. In conclusion both languages have certain things they allow the developer to do quite nicely, our specific focus is quasi real time distributed applications. I would be interested in hearing from any of you on c++ porting issues, (another task we have to undertake soon). This article is not religious, and i hope it is not taken that way, however if it is I would be glad to share my faith in Jesus Christ with you. -- James M Doherty - SWBT - Advanced Technology Planning One Bell Center Room 11-Y-03 St. Louis, Mo. 63101 UUCP: { pyramid, ihnp4, bellcore }...!swbatl!jmd PHON: 314-235-0804 FAX: 314-235-0727