On 2011-02-04 05:07, Jonathan M Davis wrote:
On Thursday 03 February 2011 19:29:15 Robert Jacques wrote:
On Thu, 03 Feb 2011 08:49:54 -0500, Jacob Carlborg<d...@me.com> wrote:
On 2011-02-03 05:52, Robert Jacques wrote:
On Wed, 02 Feb 2011 12:55:37 -0500, %u<f...@jhgjhb.com> wrote:
I know is possible to create an object from its name. It's possible to
call a method from that object if the name is only known at runtime?
Would something like the following be possible?
string classname, methodname;
// Ask the user for class and method.
auto obj = Object.factory(classname);
invoke(methodname, obj, param1, param2);
Thanks
I've been working on an update to std.variant, which includes a
compile-time reflection to runtime-reflection system. (See
https://jshare.johnshopkins.edu/rjacque2/public_html/) From the docs:
Manually registers a class with Variant's runtime-reflection system.
Note that Variant automatically registers any types it is exposed. Note
how in the example below, only Student is manually registered; Grade is
automatically registered by Variant via compile-time reflection of
Student.
module example;
class Grade { real mark; }
class Student { Grade grade; }
void main(string[] args) {
Variant.__register!Student;
Variant grade = Object.factory("example.Grade");
grade.mark(96.6);
assert(grade.mark == 96.6);
}
And dynamic method/field calls are handled via the __reflect(string
name, Variant[] args...) method like so:
grade.__reflect("mark",Variant(96.6));
assert(grade.__reflect("mark") == 96.6);
Why would you need to pass in Variants in __reflect? Why not just make
it a variadic method and automatically convert to Variant?
Well, opDispatch does exactly that. __reflect, on the other hand, was
designed as a quasi-backend function primarily for a) internal use (hence
the double underscore), b) scripting language interfacing/implementing and
c) user-extension. So efficiency was of key importance. And the reflection
system is extensible, as Variant knows to call __reflect on user defined
types. This makes things like prototype style objects possible. (There's
even a beta implementation of a prototype object in the library) But this
requires that the use __reflect methods not be templated.
I'm not well versed in dynamic reflection and its use cases, so when I
considered the combination of a runtime method name and compile-time
argument type information, I classed it as 'rare in practice'. But if
that's not the case, I'd like to know and would greatly appreciate a use
case/unit test.
Most of the good examples of runtime reflection that I'm aware of require user-
defined attributes. But there are libraries in Java (and presumably C#) that do
stuff like allow you to mark your classes with certain attributes indicating
what
type of XML elements that they should be, and then another library which knows
_nothing_ about your classes is able to serialize them to and from XML. Another
example would be Hibernate, which does the same sort of stuff only it deals with
talking to databases. Full-on runtime reflection combined with user-defined
attributes can do some powerful stuff. However, I do think that runtime
reflection
without user-defined attributes doesn't tend to be anywhere near as useful. To
really get that sort of stuff working, we'd need D to properly support both
user-
defined attributes and runtime reflection. Both are future possibilities but
obviously aren't happening any time soon.
- Jonathan M Davis
Ruby seems to get along without any kind of attributes/annotations. But
on the other hand you can call a method in a class declaration and this
will behave much the same as a attribute.
ActiveRecord in Rails is a good example of runtime reflection. Also the
Ruby XML library "builder" is a good example of runtime reflection.
Maybe not acutally runtime reflection but is uses the "method_missing"
method, equivalent to the "opDispatch" method in D, heavily.
http://builder.rubyforge.org/
--
/Jacob Carlborg
