[Prev][Next][Index][Thread]
Dylan & MOP
-
Subject: Dylan & MOP
-
From: Scott Ribe <sribe@miqs.com>
-
Date: Thu, 11 Nov 1999 15:00:05 -0500 (EST)
-
Organization: (None)
-
Reply-To: sribe@miqs.com
-
Xref: grapevine.lcs.mit.edu comp.lang.dylan:11133
OK,
I touched on these issues in my previous post, but this deserves its own
discussion. Dylan as specified has some of the pieces needed for a
metaobject protocol, but not all. Do I need to defend the utility of a
MOP in Dylan? Right now, I'm assuming not. If it does need defending
after all, that could be a different post or more likely a whole thread
;-)
I realize that the features I'm talking about don't come free of runtime
performance expense. That's life and I'd deal with it. Actually, that's
a lie. First I'll lobby for the functionality, then _after_ I get it
I'll bitch for improved performance ;-)
The first part is introspection:
Given an object, you can find its class. Given a class, you can find its
superclasses, and subclasses. You cannot find a class by name, and you
cannot get the slots of a class.
Given a generic function, you can find its methods and info about
required keywords, specializers, arguments, return values and so on. You
cannot find a generic function by name.
Given a method, you can find info about specializers, arguments, return
values and so on. You cannot find a method by name.
I think you should be able to find classes and generic functions by
name. I'm not sure it makes sense to find a method by name outside the
context of its containing generic function. I think you should be able
to get information about a class's direct slots.
The second part is manipulation:
You can create a class. The provided capability looks pretty functional
and useful.
You can create a generic function, add and remove methods, and apply the
function. Such a function is by nature anonymous, there is no way to
bind it to a module-level name and call it by that name, nor is there
apparently any way to "fake up" that kind of behavior. Of course, if one
could create a new, named generic function that would at runtime match
up to existing calls in the code, there is the little issue of how you
could possibly control export and visibility of such functions. (Maybe
my thread on MOP & object/relational mapping actually just does not fit
with Dylan and I have to reorient myself. Hmm.)
You can't hook into or modify the behavior of method dispatch at all. I
don't see a need (other than discussed above for "hooking up" method
calls to dynamically generated gfs) for this. But that may just be a
result of my inexperience with MOP concepts and their uses.
Follow-Ups: