Szegedi Attila wrote: > Hello all, > > I finally got around to packaging up the current state-of-art of my > metaobject protocol library as a downloadable release (source + binaries > + documentation), plus putting up a very basic website (hosting an > information page + JavaDoc) for it.
Notes as I work through the implementation. * I know we talked about this at one point, but it would fit better with JSR292 and even current hotspot optimizations if the MOP provided a way to invoke by querying for method objects. So rather than Object call(Object target, Object id, CallProtocol protocol, Map args) You'd have Callable query(Object id, Map args) (args for signature selection where appropriate) And use the resulting callable. The largest performance gains we've seen in JRuby have resulted from moving away from call() invocation to getMethod().invoke() invocation, since it brings the target method (presumably either a reflected method or in JRuby's case a code-generated stub) closer to the call site. Bottom line: reduce the distance between call site and target code. call() interface makes it at least one hop. * For languages that don't support keyword arguments, I think it may be better to have the call(..., Map) signature to take SortedMap instead. Otherwise there's no way to predictably map the arguments into an array. Right now I'm using .values().toArray(), which will not work predictably for args.length > 1. * I presume there's no affordance for a closure parameter on the call signatures because it would be just another argument (or arguments) to the method, yeah? Or perhaps because Java has no standard way to pass closures yet, so anyone using the Java API would need to implement their own mechanism anyway? * I'm debating the best way to implement the property accessors. In Ruby, there's no distinction between properties (attributes) and normal methods. Setting an attribute is done through a foo= method, and getting is done through a foo method. I can make a property named "foo" to calling these methods, but that seems a little strange. However mapping it to instance variables seems even more wrong, since ivars are never public in Ruby unless you provide attribute accessors for them. Thoughts? * There is no apparent way to represent method visibility. For the moment, I'm implementing it to ignore the visibility of the target methods. * I'm using results as follows: - noAuthority if it's not an IRubyObject (though we want to move toward all invocations working with Object instead of IRubyObject) - noRepresentation if any parameters are not IRubyObject instance or for methods that don't map correctly like integer property access - notDeletable for all deletes since attributes don't support the notion of deletion, only setting and getting * How would one map propertyIds to a language that doesn't support a separate notion of properties? There's nothing for me to list. This also applies to has(). * Is representAs intended to be only for coercion to normal Java types? There doesn't appear to be a good way to use this for Ruby's built-in coercion from one Ruby type to another since they sometimes don't have Java type equivalents. If it's only intended for actual Class types, that's probably ok, but it will have a reduced applicability. Implementing to return noAuthority for now. * Why does put(Object, Object || long, Object, CallProtocol) pass protocol but get does not? * Plural enums and types bug me. It should be "Result", not "Results". * Are the call methods with no target intended to represent calling static methods? In Ruby's case, there's no distinction between "static" and "instance" methods, since all methods can only be called on an instance of something. The rough equivalent to static methods would be instance methods on the metaclass, and that's how I'm implementing these call methods. And now I've completed the implementation for the moment. I've attached a patch to our RubyClass object that shows the implementations, and they're also available here: http://pastie.caboo.se/121597 I'm interested in talking through the bullets above and discussing how to improve the MOP. - Charlie --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "JVM Languages" group. To post to this group, send email to [email protected] To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/jvm-languages?hl=en -~----------~----~----~----~------~----~------~--~---
