[Prev][Next][Index][Thread]
Re: Dylan & MOP
Dylan has some pretty powerful introspection and the ability to add methods to
GFs at runtime.
See p.343 and onwards of the Dylan Reference manual for type introspection such
as all-superclasses(), but note that it may not work on sealed classes.
See p.351 and onwards of the Dylan Reference manual for function introspection
methods, notably generic-function-methods(), add-method(), function-arguments(),
but note that they may not work on sealed functions or domains.
I don't know how you'd get all the slots for a class, though. This has always
struck me as a security issue,and I'm not entirely convinced by, say, Java's
implementation.
- Rob.
Scott Ribe wrote:
> 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.
References: