MOPs (warning: LONG)

[Craig Brozefsky]

Joachim Durchholz <joachim.durchholz at web.de> writes:

> And, finally, there's the list of things that can be done using MOP,
> but where I think that they are better handled as part of the run-time
> system:
> * (Un-)Marshalling
> * Synchronization
> * Multimethods

The MOP is an interface to the run-time system for common object
services.  I do not understand your position that these would be
better handled by the run-time.

> For (un-)marshalling, I think that this should be closed off and
> hidden from the programmer's powers because it opens up all the
> implementation details of all the objects.

What if I want to (un-)marshall from/to something besides a byte
stream, such as an SQL database?  I don't want one of the object
services my system depends on to be so opaque because a peer thought I
would be better off that way.  Then again, I have never understand the
desire to hide things in programming languages.

> Anybody inspecting source code will have to check the entire sources
> to be sure that a private field in a record is truly private, and
> not accessed via the mechanisms that make user-level implementation
> of (un-)marshalling possible.

If you look at the MOP in CLOS, you can use the slot-value-using-class
method to ensure that getting/setting the slot thru any interface will
trigger the appropriate code.  It does not matter, private, public,
wether they use SLOT-VALUE or an accessor.  This is also useful for
transaction mgmt.

The MOP is an interface to the run-time's object services.



-- 
Sincerely, Craig Brozefsky <craig at red-bean.com>
No war! No racist scapegoating! No attacks on civil liberties!
Chicago Coalition Against War & Racism: www.chicagoantiwar.org