4 ms·

A Metaobject Protocol for C++ (1995) [pdf]

67 points by signa11 3y ago

juliangamble 3y ago
17 Oct 1995 - OOPSLA ‘95 Austin, TX, USA This paper proposes a new MOP for C++, called OpenC++ Version 2. Like previous MOPS, it allows programmers to implement customized language extensions such as persistent or distributed objects, or customized compiler optimizations such as inlining of matrix arithmetic. These can be implemented as libraries ’ and then used repeatedly. Unlike previous MOPS, our proposal incurs zero runtime speed or space overhead compared to ordinary C++. To make this possible, our MOP works by providing control over the compilation of programs rather than over the runtime environment in which they execute.
pjmlp 3y ago
During the 1990's there were lots of cool frameworks and graphical IDE tooling for C++, somehow most of them faded away during this century, with Qt/KDE, and BeOS being a few of the survivors left.
- cmrdporcupine 3y ago
  One of the ones I remember being particularly interesting is InterViews, which someone has archived here: https://github.com/steinarb/interviews https://github.com/steinarb/interviews original paper describing it here: http://i.stanford.edu/pub/cstr/reports/csl/tr/88/358/CSL-TR-88-358.pdf http://i.stanford.edu/pub/cstr/reports/csl/tr/88/358/CSL-TR-... Which in turn begat "Fresco" which then there was an attempt at a successor called "Berlin" by Graydon Hoare (of Rust fame), but it was, I believe never finished. I remember following it eagerly.
  - pjmlp 3y ago
    Ah! I remember seeing something about it on the usual suspects, DDJ and The C/C++ Users Journal.
    - cmrdporcupine 3y ago
      It was a dark era for Unix UI development -- before GTK & Qt, and when Motif was supposed to be "standard" but was locked behind restrictive licensing, and Sun's (actually open source) XView got no uptake (and Sun had abandoned OpenView for Motif anyways). Everything was a hodgepodge. Bad memories.
      - pjmlp 3y ago
        We had access to RogueWave frameworks, so not that bad. However things eventually moved on, when I started using GNU/Linux in production, it was either Tcl/Tk or Swing.
- rjsw 3y ago
  One interesting one is ET++ [1]. From memory, it shared some ideas with MacApp. [1] https://www.softwarepreservation.org/projects/c_plus_plus/library/et_plus_plus https://www.softwarepreservation.org/projects/c_plus_plus/li...
- OnlyMortal 3y ago
  RogueWave Tools.h++ was one I used on Windows and, with some work, the Mac (Cooperative threads). It was a bit like the early Boost libraries. I particularly used the serialisation to send objects over the wire via TCP. Here’s a copy of the manual: https://bs2manuals.ts.fujitsu.com/download/manual/177 https://bs2manuals.ts.fujitsu.com/download/manual/177
  - pjmlp 3y ago
    Back in the day we were using it on HP-UX. Thanks for sharing the manual.
ape4 3y ago
CORBA came out at around the same time https://en.wikipedia.org/wiki/Common_Object_Request_Broker_Architecture https://en.wikipedia.org/wiki/Common_Object_Request_Broker_A...
jamesblonde 3y ago
This was the paper that was the inspiration for my supervisor for my PhD topic at the end of the 1990s. That whole research direction - reflective programming languages - pretty much died on the evolutionary vine. Like AI at the time, the area was looking for use-cases. One of the use cases for metaobject protocols was to make distributed objects look like normal objects by declaring them as such. You could write C++ classes and then annotate them (in the metadata layer) as distributed, and suddenly you had distribution transparency. Except, distribution transparency turned out not to be a good thing as it is a leaky abstraction. See the 10 fallacies of distributed systems for why this is so. EJB also killed the use case, as it was actually a solution for it. It did build on some principles from this research - enable pre- and post-method invocations to be pushed to application deployment time. EJB enabled methods to be "transactional" or "filtered" and so on. Aspect-oriented programming was a rebranding of metaobject protocols that also didn't have huge impact. As for me, i finished my PhD in the field and moved on to other research.
- kstrauser 3y ago
  What’s “distributed” mean here?
  - bluGill 3y ago
    There are two meanings we meant: other computers, and other programs. In 1995 most computers had a single CPU core, running at around 100mhz. Today each core is 10-30x higher frequency (though as always you cannot compare frequency directly it is still a sign of relative speed), and almost all computers have at least 4 cores. In 1995 you were doing good to get 8 MB of RAM, now we are looking at around 8GB. One way around the inherent slowness of computers is another one on the network to run some programs. In 1995 there were cool demonstrations where a program could plugin others for some functions. So your word processor wouldn't have a spellcheck, it would just use a third party spell check of your choice. (we sort of do that with shared libraries, but the interface is different) Some of what was done then was better than anything we have today (but see the other replies, making distributed work transparently is not easy and so if we had made it work people would probably hate how often it failed)
armchairhacker 3y ago
If I understand this correctly, this gives users the power to add even more features to C++. Don't get me wrong, this isn't a terrible idea in that it does have some use cases. But also, I wonder if the authors would be better off adding the MOP to a language like C which is simpler and would benefit more from having extra features.
- Jtsummers 3y ago
  What would it mean to have a MOP for a language which doesn't have objects in the OO sense? Especially C.
  - wudangmonk 3y ago
    isn't CLOS OO based on generic functions and not objects? as far as I know Lisp doesn't have objects in the OO sense either.
    - lispm 3y ago
      Objects are instances of classes in CLOS. Classes, Methods, Generic Functions, ... are also instances of classes. Classes support multiple inheritance. Instances have an identity, slots and a class. CLOS does not use methods attached to classes, which can be invoked by message sending or similar. Instead CLOS uses Generic Functions which consist of one or more Methods. Methods are dispatched over classes, using possibly multiple arguments. Generic Functions are themselves objects and they are defined outside of classes. When a Generic Function gets called, all the applicable Methods are combined to an Effective Method that then will be executed.
  - toolslive 3y ago
    Well, in C you have function calls, so you can still do reification on that, turn it in to a value (ie a record that holds the parameters and the pointer of the function) and fiddle with it. Some examples: - you can send it to another machine turning it into RPC, and you can encrypt (some of) the parameters because of this - you can add save the program state before you execute it for checkpointing purposes - you can log the parameters for tracing - ...
w10-1 3y ago
Off topic, but on the question of provenance... Chiba worked with folks at PARC, and this is a year after Gregor Kiczales wrote the book, The Art of the Metaobject Protocol. Kiczales designed AspectJ, still in use in Spring today. The three design dimensions for metaprogramming are static vs dynamic, whole-program vs incremental, and raw vs typed. AspectJ committed to incremental (and removed whole-program features like callee-side call join points) because Eclipse's incremental compilation made enterprise programming bearable (and of course Java chose it for loading classes). Staticly, AspectJ did reduce the pointcut shadow at compile-time (unlike (remote) method interception which), but semantically still supported type-safe dynamic checks (mainly instance-of and limited control-flow via a thread-local). But types were the best part: unlike reflection-based proxies in Java (that formed the basis for most of the EJB/Web containers), AspectJ advice could be written to expose only the required context, and only in a type-safe manner. Inter-type declarations were guaranteed valid at compile-time (and supported default methods 20 years before Java did). And most importantly, the code with aspects was binary- and source-compatible with any code using the unmodified code. (Of course, it also helped that Java supported debugging from extrinsic source files for JSP's, so you could step into aspects as you like.) AspectJ static and incremental made it usable, but typed made it safe and correct and understandable. (And btw, Kiczales dropped out of MIT.)
- pjmlp 3y ago
  And now C# 12 is introducing something similar via interceptors, however its quite clunky versus somethig like PostSharp.
vinkelhake 3y ago
Sean Baxter's Circle [1] is arguably the spiritual successor to MOP. [1] https://www.circle-lang.org/ https://www.circle-lang.org/

67 points by signa11 3y ago

17 Oct 1995 - OOPSLA ‘95 Austin, TX, USA This paper proposes a new MOP for C++, called OpenC++ Version 2. Like previous MOPS, it allows programmers to implement customized language extensions such as persistent or distributed objects, or customized compiler optimizations such as inlining of matrix arithmetic. These can be implemented as libraries ’ and then used repeatedly. Unlike previous MOPS, our proposal incurs zero runtime speed or space overhead compared to ordinary C++. To make this possible, our MOP works by providing control over the compilation of programs rather than over the runtime environment in which they execute.

pjmlp 3y ago

During the 1990's there were lots of cool frameworks and graphical IDE tooling for C++, somehow most of them faded away during this century, with Qt/KDE, and BeOS being a few of the survivors left.

cmrdporcupine 3y ago
One of the ones I remember being particularly interesting is InterViews, which someone has archived here: https://github.com/steinarb/interviews https://github.com/steinarb/interviews original paper describing it here: http://i.stanford.edu/pub/cstr/reports/csl/tr/88/358/CSL-TR-88-358.pdf http://i.stanford.edu/pub/cstr/reports/csl/tr/88/358/CSL-TR-... Which in turn begat "Fresco" which then there was an attempt at a successor called "Berlin" by Graydon Hoare (of Rust fame), but it was, I believe never finished. I remember following it eagerly.
- pjmlp 3y ago
  Ah! I remember seeing something about it on the usual suspects, DDJ and The C/C++ Users Journal.
  - cmrdporcupine 3y ago
    It was a dark era for Unix UI development -- before GTK & Qt, and when Motif was supposed to be "standard" but was locked behind restrictive licensing, and Sun's (actually open source) XView got no uptake (and Sun had abandoned OpenView for Motif anyways). Everything was a hodgepodge. Bad memories.
    - pjmlp 3y ago
      We had access to RogueWave frameworks, so not that bad. However things eventually moved on, when I started using GNU/Linux in production, it was either Tcl/Tk or Swing.
rjsw 3y ago
One interesting one is ET++ [1]. From memory, it shared some ideas with MacApp. [1] https://www.softwarepreservation.org/projects/c_plus_plus/library/et_plus_plus https://www.softwarepreservation.org/projects/c_plus_plus/li...
OnlyMortal 3y ago
RogueWave Tools.h++ was one I used on Windows and, with some work, the Mac (Cooperative threads). It was a bit like the early Boost libraries. I particularly used the serialisation to send objects over the wire via TCP. Here’s a copy of the manual: https://bs2manuals.ts.fujitsu.com/download/manual/177 https://bs2manuals.ts.fujitsu.com/download/manual/177
- pjmlp 3y ago
  Back in the day we were using it on HP-UX. Thanks for sharing the manual.

ape4 3y ago

CORBA came out at around the same time https://en.wikipedia.org/wiki/Common_Object_Request_Broker_Architecture https://en.wikipedia.org/wiki/Common_Object_Request_Broker_A...

jamesblonde 3y ago

This was the paper that was the inspiration for my supervisor for my PhD topic at the end of the 1990s. That whole research direction - reflective programming languages - pretty much died on the evolutionary vine. Like AI at the time, the area was looking for use-cases. One of the use cases for metaobject protocols was to make distributed objects look like normal objects by declaring them as such. You could write C++ classes and then annotate them (in the metadata layer) as distributed, and suddenly you had distribution transparency. Except, distribution transparency turned out not to be a good thing as it is a leaky abstraction. See the 10 fallacies of distributed systems for why this is so. EJB also killed the use case, as it was actually a solution for it. It did build on some principles from this research - enable pre- and post-method invocations to be pushed to application deployment time. EJB enabled methods to be "transactional" or "filtered" and so on. Aspect-oriented programming was a rebranding of metaobject protocols that also didn't have huge impact. As for me, i finished my PhD in the field and moved on to other research.

kstrauser 3y ago
What’s “distributed” mean here?
- bluGill 3y ago
  There are two meanings we meant: other computers, and other programs. In 1995 most computers had a single CPU core, running at around 100mhz. Today each core is 10-30x higher frequency (though as always you cannot compare frequency directly it is still a sign of relative speed), and almost all computers have at least 4 cores. In 1995 you were doing good to get 8 MB of RAM, now we are looking at around 8GB. One way around the inherent slowness of computers is another one on the network to run some programs. In 1995 there were cool demonstrations where a program could plugin others for some functions. So your word processor wouldn't have a spellcheck, it would just use a third party spell check of your choice. (we sort of do that with shared libraries, but the interface is different) Some of what was done then was better than anything we have today (but see the other replies, making distributed work transparently is not easy and so if we had made it work people would probably hate how often it failed)

armchairhacker 3y ago

If I understand this correctly, this gives users the power to add even more features to C++. Don't get me wrong, this isn't a terrible idea in that it does have some use cases. But also, I wonder if the authors would be better off adding the MOP to a language like C which is simpler and would benefit more from having extra features.

Jtsummers 3y ago
What would it mean to have a MOP for a language which doesn't have objects in the OO sense? Especially C.
- wudangmonk 3y ago
  isn't CLOS OO based on generic functions and not objects? as far as I know Lisp doesn't have objects in the OO sense either.
  - lispm 3y ago
    Objects are instances of classes in CLOS. Classes, Methods, Generic Functions, ... are also instances of classes. Classes support multiple inheritance. Instances have an identity, slots and a class. CLOS does not use methods attached to classes, which can be invoked by message sending or similar. Instead CLOS uses Generic Functions which consist of one or more Methods. Methods are dispatched over classes, using possibly multiple arguments. Generic Functions are themselves objects and they are defined outside of classes. When a Generic Function gets called, all the applicable Methods are combined to an Effective Method that then will be executed.
- toolslive 3y ago
  Well, in C you have function calls, so you can still do reification on that, turn it in to a value (ie a record that holds the parameters and the pointer of the function) and fiddle with it. Some examples: - you can send it to another machine turning it into RPC, and you can encrypt (some of) the parameters because of this - you can add save the program state before you execute it for checkpointing purposes - you can log the parameters for tracing - ...

w10-1 3y ago

Off topic, but on the question of provenance... Chiba worked with folks at PARC, and this is a year after Gregor Kiczales wrote the book, The Art of the Metaobject Protocol. Kiczales designed AspectJ, still in use in Spring today. The three design dimensions for metaprogramming are static vs dynamic, whole-program vs incremental, and raw vs typed. AspectJ committed to incremental (and removed whole-program features like callee-side call join points) because Eclipse's incremental compilation made enterprise programming bearable (and of course Java chose it for loading classes). Staticly, AspectJ did reduce the pointcut shadow at compile-time (unlike (remote) method interception which), but semantically still supported type-safe dynamic checks (mainly instance-of and limited control-flow via a thread-local). But types were the best part: unlike reflection-based proxies in Java (that formed the basis for most of the EJB/Web containers), AspectJ advice could be written to expose only the required context, and only in a type-safe manner. Inter-type declarations were guaranteed valid at compile-time (and supported default methods 20 years before Java did). And most importantly, the code with aspects was binary- and source-compatible with any code using the unmodified code. (Of course, it also helped that Java supported debugging from extrinsic source files for JSP's, so you could step into aspects as you like.) AspectJ static and incremental made it usable, but typed made it safe and correct and understandable. (And btw, Kiczales dropped out of MIT.)

pjmlp 3y ago
And now C# 12 is introducing something similar via interceptors, however its quite clunky versus somethig like PostSharp.

vinkelhake 3y ago

Sean Baxter's Circle [1] is arguably the spiritual successor to MOP. [1] https://www.circle-lang.org/ https://www.circle-lang.org/