Metaobject protocol:Why is it known as an important concept

Question

Metaobject protocol is protocol for metaobjects in a programming languages. Although I understand it on simple terms, I want to know the reason and a summary of real world usage patterns of this protocol. So, why exactly is metaobject and more importantly metaobject protocol is such a good idea. I want to know the problem which led to its evolution and also, its high power usage. Opinions as well as general overview/description/alternate explanations are also welcome.

Answer 1

The Perl library Moose is using the MOP to allow a large ecosystem of extensions to work smoothly together. It also allows for introspection and reflection, for instance the generation of a web form by providing an object. The reflector would look at the class, take (for example) it's attributes or attributes that implement a specific behavior, and generate form fields depending on the attributes and their types.

There are of course many other implementations and use cases for the MOP, Moose is just the one I use most frequently.

Answer 2

One way of thinking about a meta-object protocol is that it's like aspect-oriented programming. AOP really came out of MOP, but extended it with point-cuts (and probably other stuff).

So, things that AOP is good for I would expect MOP to be good for. The classic example is, of course, profiling. You want to take an existing program and modify it to e.g. record every method that is invoked. With MOP you could do with this some kind of proxy object which intercepts messages, records the profile data and then passes control onto the original message handler.

Answer 3

Meta-object protocols are very good to decouple clients from servers.

• Web services use WSDL
• OSGI does some of this ( but AFAIK lacks a lot of the introspection tools)
• JINI (Java based) on regular networks ( quite quietly popular in the defence space)

Some control systems I've worked on I added meta-object protocols and it worked really well. The exchange of messages look like this....

• Dear Server, what do you do ?
• Dear Client, I have the following commands .....
• Dear Server, what data do you publish ?
• Dear Client, I have the following subscribable notifications .....
• Dear Server please tell me more about "Paint fence"
• Dear Client, Paint fence takes an integer, number of robots to use.
• Dear Server, please give me a help file on command "paint fence
• Dear Client, Here is a help file
• Dear Server, subscribe me to "robot #1 coordinates"
• Dear Server, subscribe me to "robot .. coordinates"

• Dear Server, subscribe me to "robot #42 coordinates"

• Dear Server, execute paint fence, 42

• Dear Client, your command completion id is 11.
• Dear Client, robot #1 coordinates new value 123.3434,34.232312,55.222312

So the overhead of messages you use for real tasks is low because they can even be a compact binary from, and the server is self-documenting for integrators.

Allows integration really easily.

Also allows you to extend the server really easily IF you can add stuff to the server using the meta-protocol. Does start to look like AOP

• Dear Server, add delegated command FOO (no arguements, "does foo")

• Dear Client, you are the FOO delegate.

• Dear Server, override value for external temperature, new value 3.5 So now all consumers get the externally supplied value. Works best if you can ask questions like this..

• Dear Server, get control value for external temperature

• Dear Client, external temperature set to external source, hostname SMART_TEMP_SENSOR