On Wed, Dec 05, 2007 at 11:34:45AM -0500, Reed Hedges wrote: > > We should also include at this point a reminder of why there's a code > generator. > > If I understand things correctly, the goal is to use the code generator to > (a) generate code for different programming languages > (b) make it easier for users to generate MetaObject (now called > Component) wrapper classes corresponding to different type interfaces > (and in different programming languages). > > The fact that Peter happened to use the code generator to generate VOS > itself is, again if I understand it correctly, partly for (a), and > partly to make sure it works well. > > Correct me if I'm wrong Pete.
You're on the right track, but there's more to it than that. It provides a set of formal semantics for VOS which are defined externally of a particular programming language. With the spec in hand, you only have to write a code generator (or other metaprogramming layer) and run it against the spec to map VOS onto a new target language. It gives a self-contained type system, so when two programming languages talk about a VOS Class, they are unambigously referring to the same thing. It also encourages developing an OS- and language-independent vobject-based standard library of APIs and components instead of dropping down to the language-specific standard library for common tasks. For example, I've already added InputStream and OutputStream classes as part of VOS in order to read and write files. This means you will be able to read from or write to streams which come from other language runtimes, processes, or hosts. In the case of the C++ binding, the code generator will automate marshalling, unmarshalling, and pipling, which would be tedious and error prone to write by hand (and changes often during development). C++ template metaprogramming doesn't really help here, since templates don't provide the reflection features to be able to say "for each method in this class..." Finally, the code generator also keeps some other miscellaneous boilerplate code in sync, such as registering classes and implementations, and embedded the correct copy of the interface spec in the executable so that reflection is available at runtime. Rather than simply being a convenient tool, the VOS object model is almost a new language that happens to be hosted on C++. I actually hope to see VOS implemented in other languages (and not just through foreign function interfaces) and think it will be a better fit for higher-level languages that already provide garbage collection, reflection, marshaling, promises, continuations, etc. -- [ Peter Amstutz ][ [EMAIL PROTECTED] ][ [EMAIL PROTECTED] ] [Lead Programmer][Interreality Project][Virtual Reality for the Internet] [ VOS: Next Generation Internet Communication][ http://interreality.org ] [ http://interreality.org/~tetron ][ pgpkey: pgpkeys.mit.edu 18C21DF7 ]
signature.asc
Description: Digital signature
_______________________________________________ vos-d mailing list vos-d@interreality.org http://www.interreality.org/cgi-bin/mailman/listinfo/vos-d
