C++Talk.NET C++ language newsgroups   Archives   FAQ   Search   Memberlist   Usergroups   Register   Profile   Log in to check your private messages   Log in  Universal Object Models - Grrr!          C++Talk.NET Forum Index -> C++ Language (Moderated) View previous topic :: View next topic   Author Message Le Chaud Lapin Guest Posted: Tue Jul 13, 2004 9:53 pm    Post subject: Universal Object Models - Grrr! There are "mature" and emerging frameworks that push the concept of universal objects and univeral repositories to contain them, .NET being the most prevalent. I would like to argue that this concept is fundamentally flawed and can only be "successful" if it causes erosion of distinct type systems in languages like C++. I am not concerned that C++ will subsumed by C++/.NET or CORBA - I believe that in time, programmers will learn empircally the sillyness and futility of this approach. Neverthesless, there is much time spent trying to concoct these systems, and perhaps we can discuss its viability now (again). My argument is that it is not possible to have a universal object without modifying the type system of any language that must interact with the object. In other words, invoking the concept of an IDL and throwing in a separate compiler is not enough. There will always be a point where the programmer will have to make a choice between the native types of the language and the "universal" types. Furthermore, comitting to a universal type system causes an immediate incompatibility between native type systems. For example, let's say that I have a moderately complex data structure in a "pure C++" client that is to interact with a "universal object" server: Associative_Monarchy<List Quote: ; Associative_Monarchy<> is what some might have called Tree<>. This structure is one that I might actually use in C++. It could be used to represent the structure of an XML file. I certainly have structures like it and some much more complex in my current project. I would like to state first that I *very* *much* deliberately chose the structure of this object. By this I mean that it has a certain structure which is precisely what I want - I am not willing to surrender its form for something flatter simply because the "universal object" permits no parallel reprenstation. How would I manage to allow this structure to interact with a universal object? Would I be forced to substitute this class with another "universal class" in my C++ program? If so, how do I deal with the incompatibiity? -Chaud Lapin- [ See http://www.gotw.ca/resources/clcm.htm for info about ] [ comp.lang.c++.moderated. First time posters: Do this! ] Back to top Hyman Rosen Guest Posted: Wed Jul 14, 2004 9:35 am    Post subject: Re: Universal Object Models - Grrr! Le Chaud Lapin wrote: Quote: My argument is that it is not possible to have a universal object without modifying the type system of any language that must interact with the object. You are wrong. The only thing needed for a universal object format is a way of describing any object, the way Java has in its reflection system. The RTTI part of C++ is also a (very) partial implementation of this concept. Your native object format does not have to change at all, because there is no conceptual need to embed the object description within the object, the way C++ embeds vptrs. Instead, when you have a concrete object of a given type, its associated description is implicit. Pointers and references can be made "fat", such that when one is created it consists of a pair of pointers, one to the object and one to the descriptor. The advantage of a universal format is that adaptable frameworks can be written that can handle any object, for such things as serialization. [ See http://www.gotw.ca/resources/clcm.htm for info about ] [ comp.lang.c++.moderated. First time posters: Do this! ] Back to top David Eng Guest Posted: Wed Jul 14, 2004 9:14 pm    Post subject: Re: Universal Object Models - Grrr! [email]unoriginal_username (AT) yahoo (DOT) com[/email] (Le Chaud Lapin) wrote in message news:<fc2e0ade.0407131156.4f4898c1 (AT) posting (DOT) google.com>... Quote: There are "mature" and emerging frameworks that push the concept of universal objects and univeral repositories to contain them, .NET being the most prevalent. I would like to argue that this concept is fundamentally flawed and can only be "successful" if it causes erosion of distinct type systems in languages like C++. I am not concerned that C++ will subsumed by C++/.NET or CORBA - I believe that in time, programmers will learn empircally the sillyness and futility of this approach. Neverthesless, there is much time spent trying to concoct these systems, and perhaps we can discuss its viability now (again). In term of CORBA (I cannot speak to .NET since I don't want to study it), your argument is totally wrong. CORBA never defines universal objects. It just defines a standard communication protocol, in this case, it is called interface. In traditional programming languages such as C++, there is no way you can call or communicate an object which does not reside in the calling process's address space. One way to solve this problem is to use TCP/IP interface socket. But this practice results lot of pluming code and portability issue. CORBA solves this problem by providing a standard way through IDL to communication between objects in different address space. By the standard interface, different objects, i.e. C++ type, Java type, etc. can communicate with each other. The implementation of the interface is native language type. There are no so call universal objects. CORBA only defines a standard protocol and run-time environment to facilitate the communication. If the standard interface cannot satisfy you native type, you always can write your own communication protocol. [ See http://www.gotw.ca/resources/clcm.htm for info about ] [ comp.lang.c++.moderated. First time posters: Do this! ] Back to top paul Guest Posted: Wed Jul 14, 2004 9:37 pm    Post subject: Re: Universal Object Models - Grrr! Hyman Rosen wrote: Quote: Your native object format does not have to change at all, because there is no conceptual need to embed the object description within the object, the way C++ embeds vptrs. Instead, when you have a concrete object of a given type, its associated description is implicit. Pointers and references can be made "fat", such that when one is created it consists of a pair of pointers, one to the object and one to the descriptor. Regarding fat pointers: I assume you have included in this VM model the ability to correctly emulate C manipulations with pointers and bitshifting. There may be no conceptual _need_ for thin pointers, but languages at the level of C/C++ where one can _apparently_ manipulate memory directly avoid the confusion of maintaining a VM with user-manipulatable memory by merely doing direct memory manipulation. Regarding type systems: Some languages directly depend on "thin" types. Essentially what a universal object model does is create an emulator. Yay. Seems rather pointless to me unless it's application is non-os specific, like Java. -paul -- /b Quote: f(x) = F(b) - F(a) /a [ See http://www.gotw.ca/resources/clcm.htm for info about ] [ comp.lang.c++.moderated. First time posters: Do this! ] Back to top Le Chaud Lapin Guest Posted: Wed Jul 14, 2004 10:18 pm    Post subject: Re: Universal Object Models - Grrr! Hyman Rosen <hyrosen (AT) mail (DOT) com> wrote Quote: Your native object format does not have to change at all, because there is no conceptual need to embed the object description within the object, the way C++ embeds vptrs. Instead, when you have a concrete object of a given type, its associated description is implicit. Pointers and references can be made "fat", such that when one is created it consists of a pair of pointers, one to the object and one to the descriptor. I do not understand this. It seems like you are implying that, within my C++ program, I have some stuff permits definitions of universal objects. If so, this validates my assertion. Let me give a more concrete example: There are two nodes, A and B. [A] <-----------> [B] Node B is located at a Fortune 500 company that has been raving about their universal objects. Node A is located in the office of a university professor who is a C++ "purist", meaning that he has no intention of deviating from C++, but he wants to use the services of B by invoking methods on objects of B. How then, can the professor meaningfully make use of universal objects located on the server at [B]? My whole point is that the notion of seamless interaction with universal objects with bona fide C++ objects is a facade. By its very nature, if it is universal, then the interfaces cannot be seamless. -Chaud Lapin- [ See http://www.gotw.ca/resources/clcm.htm for info about ] [ comp.lang.c++.moderated. First time posters: Do this! ] Back to top Hyman Rosen Guest Posted: Thu Jul 15, 2004 10:23 am    Post subject: Re: Universal Object Models - Grrr! paul wrote: Quote: Regarding fat pointers: I assume you have included in this VM model the ability to correctly emulate C manipulations with pointers and bitshifting. It's not a VM model. You can do whatever operations you like, and the compiler will follow along maintaining the descriptor part. If you want to convert from an integer to a pointer, you would have to provide the true type of the pointer, and then the descriptor could be craeted fresh from the cast. Quote: There may be no conceptual _need_ for thin pointers, but languages at the level of C/C++ where one can _apparently_ manipulate memory directly avoid the confusion of maintaining a VM with user-manipulatable memory by merely doing direct memory manipulation. This has nothing to do with VMs. Fat pointers manipulate memory directly just as thin pointers do. They just carry around extra type information so you know what is being pointed to. Quote: Some languages directly depend on "thin" types. Essentially what a universal object model does is create an emulator. No, there is no emulation involved, just information. [ See http://www.gotw.ca/resources/clcm.htm for info about ] [ comp.lang.c++.moderated. First time posters: Do this! ] Back to top Le Chaud Lapin Guest Posted: Thu Jul 15, 2004 11:48 pm    Post subject: Re: Universal Object Models - Grrr! [email]davideng2004 (AT) yahoo (DOT) com[/email] (David Eng) wrote in message news:<6b74193f.0407140608.10c73d93 (AT) posting (DOT) google.com>... Quote: unoriginal_username (AT) yahoo (DOT) com (Le Chaud Lapin) wrote in message news:<fc2e0ade.0407131156.4f4898c1 (AT) posting (DOT) google.com>... In term of CORBA (I cannot speak to .NET since I don't want to study it), your argument is totally wrong. CORBA never defines universal objects. It just defines a standard communication protocol, in this case, it is called interface. In traditional programming languages such as C++, there is no way you can call or communicate an object which does not reside in the calling process's address space. One way to solve this problem is to use TCP/IP interface socket. But this practice results lot of pluming code and portability issue. CORBA solves this problem by providing a standard way through IDL to communication between objects in different address space. By the standard interface, different objects, i.e. C++ type, Java type, etc. can communicate with each other. The implementation of the interface is native language type. There are no so call universal objects. CORBA only defines a standard protocol and run-time environment to facilitate the communication. If the standard interface cannot satisfy you native type, you always can write your own communication protocol. I understand what you mean, but the fact remains that a C++ programmer operating on a local machine is unabled to remain entirely within the confines of C++ to access a CORBA object on a remote machine. The C++ code must be made non-portable using IDL elements. Also, if the interface is to an oject is universal, then the object itself can be regarded as universal, as no programmer would ever know the difference. This can be illustrated by defining a C++ class in a .hpp file and providing its implementation in a .lib file, written in Pascal, or Cobol, or Lisp, or Forth, or Fortran, or assembly. So it should be apparent that, for all practical purposes, the interface defines the object. That said, and given that CORBA attempts to serve a wide audience, the interface will necessarily have to be described in "generic" terms - a new type system that is not equivalent to any type system of any of the supported languages (otherwise, no IDL would have been necessary). I do not like this approach. As stated in my OP, it is restrictive at best. It would be better to find a solution that puts C++ on both sides of the pipe, using absolutely no extra compilers or language extensions. If somebody screams bloody murder that the server-side-object is biased toward C++, some sort of conversion can be provided on the server end to accommodate the other languages, but *at least* your C++ code remains pure. -Chaud Lapin- [ See http://www.gotw.ca/resources/clcm.htm for info about ] [ comp.lang.c++.moderated. First time posters: Do this! ] Back to top Michiel Salters Guest Posted: Thu Jul 15, 2004 11:57 pm    Post subject: Re: Universal Object Models - Grrr! [email]unoriginal_username (AT) yahoo (DOT) com[/email] (Le Chaud Lapin) wrote in message news:<fc2e0ade.0407141049.57242c58 (AT) posting (DOT) google.com>... .... Quote: Let me give a more concrete example: There are two nodes, A and B. [A] <-----------> [B] Node B is located at a Fortune 500 company that has been raving about their universal objects. Node A is located in the office of a university professor who is a C++ "purist", meaning that he has no intention of deviating from C++, but he wants to use the services of B by invoking methods on objects of B. How then, can the professor meaningfully make use of universal objects located on the server at [B]? 1) The purist will have to accept that he has to use some non-standard C++ to deal with the remote objects; standard C++ works on local objects. 2) The purist has to deal with any interface offered by the objects; whether this interface is defined by whims of B or the need to remote an interface doesn't really matter. Regards, Michiel Salters [ See http://www.gotw.ca/resources/clcm.htm for info about ] [ comp.lang.c++.moderated. First time posters: Do this! ] Back to top Hyman Rosen Guest Posted: Fri Jul 16, 2004 12:11 am    Post subject: Re: Universal Object Models - Grrr! Le Chaud Lapin wrote: Quote: How then, can the professor meaningfully make use of universal objects located on the server at [B]? To even know about the objects at [B], [A] must invoke some kind of lookup function which returns handles to those objects. Those handles will incorporate the descriptors for the [B] objects, and [A]'s code will use those descriptors to manipulate the objects. [ See http://www.gotw.ca/resources/clcm.htm for info about ] [ comp.lang.c++.moderated. First time posters: Do this! ] Back to top Le Chaud Lapin Guest Posted: Sun Jul 18, 2004 11:04 am    Post subject: Re: Universal Object Models - Grrr! [email]Michiel.Salters (AT) logicacmg (DOT) com[/email] (Michiel Salters) wrote in message news:<fcaee77e.0407150448.459030d (AT) posting (DOT) google.com>... Quote: unoriginal_username (AT) yahoo (DOT) com (Le Chaud Lapin) wrote in message news:<fc2e0ade.0407141049.57242c58 (AT) posting (DOT) google.com>... ... Let me give a more concrete example: There are two nodes, A and B. [A] <-----------> [B] Node B is located at a Fortune 500 company that has been raving about their universal objects. Node A is located in the office of a university professor who is a C++ "purist", meaning that he has no intention of deviating from C++, but he wants to use the services of B by invoking methods on objects of B. How then, can the professor meaningfully make use of universal objects located on the server at [B]? 1) The purist will have to accept that he has to use some non-standard C++ to deal with the remote objects; standard C++ works on local objects. Well then, why not put C++ on A, and C++ on B, so that C++ is used on the whole pipe. If someone wants to use a different language connect to the object on B, a translation would be done from that language to C++ on B. This way C++ is used everywhere except where the seam exists: on B. Quote: 2) The purist has to deal with any interface offered by the objects; whether this interface is defined by whims of B or the need to remote an interface doesn't really matter. Any interface that could be offered would be severely restrictive. I inferred that the developers of CORBA were arware of the restrictive nature of the model and probably endeavored to "help the programmer out" by providing more complicated data structures than scalars, so I went to the CORBA site to see, and sure enough, there are something called sequences, which I am guessing is some form of list<>. A list<> is probably the best they can offer without causing too much frustration. Anything beyond that painfully illustrates the limitation of the model - it does complex data structures to interact with the objects. This is why I think its better to stay with C++ (or whatever language) end to end, and do the conversion only where necessary. It keeps the standard(s) from being perturbed. It allows the programmer to remain with the language s/he is familiar with. And it allows unrestricted elegance and complexity when passing data element back and forth. If conversion can be doing in a distributed manner, certainly it can be done locally. -Chaud Lapin- [ See http://www.gotw.ca/resources/clcm.htm for info about ] [ comp.lang.c++.moderated. First time posters: Do this! ] Back to top Hyman Rosen Guest Posted: Mon Jul 19, 2004 10:26 am    Post subject: Re: Universal Object Models - Grrr! Le Chaud Lapin wrote: Quote: I went to the CORBA site to see, and sure enough, there are something called sequences, which I am guessing is some form of list<>. No. It's closest to a vector<>. [ See http://www.gotw.ca/resources/clcm.htm for info about ] [ comp.lang.c++.moderated. First time posters: Do this! ] Back to top Display posts from previous: All Posts1 Day7 Days2 Weeks1 Month3 Months6 Months1 Year Oldest FirstNewest First         C++Talk.NET Forum Index -> C++ Language (Moderated) All times are GMT Page 1 of 1   Jump to: Select a forum C/C++----------------C LanguageC Language (Moderated)C++ Language (Moderated)C++ language (comp.lang.c++)C++ language, library and standards Non-English C/C++ Newsgroups----------------C++ (German)C++ (French)  You cannot post new topics in this forum You cannot reply to topics in this forum You cannot edit your posts in this forum You cannot delete your posts in this forum You cannot vote in polls in this forum Powered by phpBB © 2001, 2006 phpBB Group SEO toolkit © 2004-2006 webmedic.