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 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

As far as I'm aware there is no way to do this in any of the standard
libraries. This said, it is possible (at least to some extent), to do
some runtime reflection by parsing symbols out of the object file and
demangling them - this is what I'm using, but it's not as extensive as
what you're requesting, it's very use specific (mainly missing calling
methods with any number of parameters). It should be possible with some
work though.
--
Robert
http://octarineparrot.com/

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

As far as I'm aware there is no way to do this in any of the standard
libraries. This said, it is possible (at least to some extent), to do
some runtime reflection by parsing symbols out of the object file and
demangling them - this is what I'm using, but it's not as extensive as
what you're requesting, it's very use specific (mainly missing calling
methods with any number of parameters). It should be possible with some
work though.

Another possibility would be to using __traits with some allMembers,
collecting all the names and a delegate in a hash and store it in the
object.
--
/Jacob Carlborg

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

As far as I'm aware there is no way to do this in any of the standard
libraries. This said, it is possible (at least to some extent), to do
some runtime reflection by parsing symbols out of the object file and
demangling them - this is what I'm using, but it's not as extensive as
what you're requesting, it's very use specific (mainly missing calling
methods with any number of parameters). It should be possible with some
work though.

Another possibility would be to using __traits with some allMembers,
collecting all the names and a delegate in a hash and store it in the
object.

If it's possible to do this, you should, it's what I'd be using if I had
access to it, unfortunately, there's no such love for D1.
--
Robert
http://octarineparrot.com/

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

As far as I'm aware there is no way to do this in any of the standard
libraries. This said, it is possible (at least to some extent), to do
some runtime reflection by parsing symbols out of the object file and
demangling them - this is what I'm using, but it's not as extensive as
what you're requesting, it's very use specific (mainly missing calling
methods with any number of parameters). It should be possible with some
work though.

Another possibility would be to using __traits with some allMembers,
collecting all the names and a delegate in a hash and store it in the
object.

If it's possible to do this, you should, it's what I'd be using if I had
access to it, unfortunately, there's no such love for D1.

AFAIK, D2's TypeInfo and friends do have an interface for runtime
reflection (methods offTi() and getMembers()), though a quick glance
shows they're not implemented, i.e. return null all the time.

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

As far as I'm aware there is no way to do this in any of the standard
libraries. This said, it is possible (at least to some extent), to do
some runtime reflection by parsing symbols out of the object file and
demangling them - this is what I'm using, but it's not as extensive as
what you're requesting, it's very use specific (mainly missing calling
methods with any number of parameters). It should be possible with some
work though.

Another possibility would be to using __traits with some allMembers,
collecting all the names and a delegate in a hash and store it in the
object.

If it's possible to do this, you should, it's what I'd be using if I had
access to it, unfortunately, there's no such love for D1.

AFAIK, D2's TypeInfo and friends do have an interface for runtime
reflection (methods offTi() and getMembers()), though a quick glance
shows they're not implemented, i.e. return null all the time.

I think the const is incorrect as well on getMembers.
--
/Jacob Carlborg

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

As far as I'm aware there is no way to do this in any of the standard
libraries. This said, it is possible (at least to some extent), to do
some runtime reflection by parsing symbols out of the object file and
demangling them - this is what I'm using, but it's not as extensive as
what you're requesting, it's very use specific (mainly missing calling
methods with any number of parameters). It should be possible with some
work though.

Another possibility would be to using __traits with some allMembers,
collecting all the names and a delegate in a hash and store it in the
object.

If it's possible to do this, you should, it's what I'd be using if I had
access to it, unfortunately, there's no such love for D1.

Same here, but you would probably need to inherit from a common base
class or use a mixin.
--
/Jacob Carlborg

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 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 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

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

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

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

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/

I'm still reading up on Ruby, but so far, there are two major difference
between serialization in Ruby and in D. First, Ruby isn't a systems
programming language with pointers/unions/etc, so serializing all
members of a class is generally okay in Ruby but isn't in D. This is the
major advantage of annotations: its a fast, simple way of declaring what
should and shouldn't be serialized. Second, Ruby's support for
serialization creates a back door around its variable protection
annotations (i.e. private,package,protected,public). Now, Ruby doesn't
actually have user defined annotations as far as I can tell, but methods
are always public and variables are always private. I don't believe that
a reflection system should bypass encapsulation. The advantage of
annotations is that they allow you to declare programmer intent and
possibly separate APIs (ala const(T)) for special purposes.

Ok, lets have a look at how a serialization annotation could look like in D:
class Foo
{
NonSerialized int x = 3;
}
Now the same can be done in Ruby, without any special syntax, like this:
class Foo
x = 3
non_serialized :x
end
In the Ruby example "non_serialized" would be a class/static method
which recives a symbol indicating what field to skip during
serialization. Actually since Ruby is a dynamically typed language I
don't have declare "x".
What I'm trying to say is that Ruby doesn't need a special syntax for
annotations since you can in Ruby do all (most of) the things you can do
with annotations but with class methods instead.
In general, serialization breaks encapsulation, not just in Ruby. You
can break encapsulation in D as well using .tupleof and delegates to
methods.
Ruby just has a different attitude. It allows you to
* Call private methods using "send"
* Add/remove/change methods on existing classes
* Change variables declared as const
It's no like Java which holds your hand all the time. It's the same with
D, but in a different way. In D there's instead:
* Pointers
* Unions
* malloc/free/delete
--
/Jacob Carlborg

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.

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

c) user-extension. So efficiency was of key importance. And the

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.

I would argue that if user-defined attributes could be implemented and tied
into the existing compile time reflection system, we could reap similar
benefits. One popular pattern in the serialization libraries you describe is
that, for performance reasons, runtime reflection can be abandoned in favor
of runtime code generation, where the same reflection system is used once to
dynamically write code that can be used repeatedly. D has the advantage that
such code can be written at compile time.
True, runtime reflection would make this sort of thing more clean and
decoupled, but even using compile time reflection, quite a bit is feasible
if user-defined attributes are defined.
--20cf3054a2e94c3e43049b6d3e3c
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable
<br><br><div class=3D"gmail_quote">On Thu, Feb 3, 2011 at 10:07 PM, Jonatha=
n M Davis <span dir=3D"ltr">&lt;<a href=3D"mailto:jmdavisProg gmx.com">jmda=
visProg gmx.com</a>&gt;</span> wrote:<br><blockquote class=3D"gmail_quote" =
style=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">
<div><div></div><div class=3D"h5">On Thursday 03 February 2011 19:29:15 Rob=
ert Jacques wrote:<br>
&gt; On Thu, 03 Feb 2011 08:49:54 -0500, Jacob Carlborg &lt;<a href=3D"mail=
to:doob me.com">doob me.com</a>&gt; wrote:<br>
&gt; &gt; On 2011-02-03 05:52, Robert Jacques wrote:<br>
&gt; &gt;&gt; On Wed, 02 Feb 2011 12:55:37 -0500, %u &lt;<a href=3D"mailto:=
fghf jhgjhb.com">fghf jhgjhb.com</a>&gt; wrote:<br>
&gt; &gt;&gt;&gt; I know is possible to create an object from its name. It&=
#39;s possible to<br>
&gt; &gt;&gt;&gt; call a method from that object if the name is only known =
at runtime?<br>
&gt; &gt;&gt;&gt;<br>
&gt; &gt;&gt;&gt; Would something like the following be possible?<br>
&gt; &gt;&gt;&gt;<br>
&gt; &gt;&gt;&gt; string classname, methodname;<br>
&gt; &gt;&gt;&gt; // Ask the user for class and method.<br>
&gt; &gt;&gt;&gt; auto obj =3D Object.factory(classname);<br>
&gt; &gt;&gt;&gt; invoke(methodname, obj, param1, param2);<br>
&gt; &gt;&gt;&gt;<br>
&gt; &gt;&gt;&gt; Thanks<br>
&gt; &gt;&gt;<br>
&gt; &gt;&gt; I&#39;ve been working on an update to std.variant, which incl=
udes a<br>
&gt; &gt;&gt; compile-time reflection to runtime-reflection system. (See<br=

ml/" target=3D"_blank">https://jshare.johnshopkins.edu/rjacque2/public_html=
/</a>) From the docs:<br>
&gt; &gt;&gt;<br>
&gt; &gt;&gt; Manually registers a class with Variant&#39;s runtime-reflect=
ion system.<br>
&gt; &gt;&gt; Note that Variant automatically registers any types it is exp=
osed. Note<br>
&gt; &gt;&gt; how in the example below, only Student is manually registered=
; Grade is<br>
&gt; &gt;&gt; automatically registered by Variant via compile-time reflecti=
on of<br>
&gt; &gt;&gt; Student.<br>
&gt; &gt;&gt;<br>
&gt; &gt;&gt; module example;<br>
&gt; &gt;&gt; class Grade { real mark; }<br>
&gt; &gt;&gt; class Student { Grade grade; }<br>
&gt; &gt;&gt; void main(string[] args) {<br>
&gt; &gt;&gt; Variant.__register!Student;<br>
&gt; &gt;&gt; Variant grade =3D Object.factory(&quot;example.Grade&quot;);<=
br>
&gt; &gt;&gt; grade.mark(96.6);<br>
&gt; &gt;&gt; assert(grade.mark =3D=3D 96.6);<br>
&gt; &gt;&gt; }<br>
&gt; &gt;&gt;<br>
&gt; &gt;&gt; And dynamic method/field calls are handled via the __reflect(=
string<br>
&gt; &gt;&gt; name, Variant[] args...) method like so:<br>
&gt; &gt;&gt;<br>
&gt; &gt;&gt; grade.__reflect(&quot;mark&quot;,Variant(96.6));<br>
&gt; &gt;&gt; assert(grade.__reflect(&quot;mark&quot;) =3D=3D 96.6);<br>
&gt; &gt;<br>
&gt; &gt; Why would you need to pass in Variants in __reflect? Why not just=
make<br>
&gt; &gt; it a variadic method and automatically convert to Variant?<br>
&gt;<br>
&gt; Well, opDispatch does exactly that. __reflect, on the other hand, was<=
br>
&gt; designed as a quasi-backend function primarily for a) internal use (he=
nce<br>
&gt; the double underscore), b) scripting language interfacing/implementing=
and<br>
&gt; c) user-extension. So efficiency was of key importance. And the reflec=
tion<br>
&gt; system is extensible, as Variant knows to call __reflect on user defin=
ed<br>
&gt; types. This makes things like prototype style objects possible. (There=
&#39;s<br>
&gt; even a beta implementation of a prototype object in the library) But t=
his<br>
&gt; requires that the use __reflect methods not be templated.<br>
&gt;<br>
&gt; I&#39;m not well versed in dynamic reflection and its use cases, so wh=
en I<br>
&gt; considered the combination of a runtime method name and compile-time<b=
r>
&gt; argument type information, I classed it as &#39;rare in practice&#39;.=
But if<br>
&gt; that&#39;s not the case, I&#39;d like to know and would greatly apprec=
iate a use<br>
&gt; case/unit test.<br>
<br>
</div></div>Most of the good examples of runtime reflection that I&#39;m aw=
are of require user-<br>
defined attributes. But there are libraries in Java (and presumably C#) tha=
t do<br>
stuff like allow you to mark your classes with certain attributes indicatin=
g what<br>
type of XML elements that they should be, and then another library which kn=
ows<br>
_nothing_ about your classes is able to serialize them to and from XML. Ano=
ther<br>
example would be Hibernate, which does the same sort of stuff only it deals=
with<br>
talking to databases. Full-on runtime reflection combined with user-defined=
<br>
attributes can do some powerful stuff. However, I do think that runtime ref=
lection<br>
without user-defined attributes doesn&#39;t tend to be anywhere near as use=
ful. To<br>
really get that sort of stuff working, we&#39;d need D to properly support =
both user-<br>
defined attributes and runtime reflection. Both are future possibilities bu=
t<br>
obviously aren&#39;t happening any time soon.</blockquote><div><br></div><d=
iv>I would argue that if user-defined attributes could be implemented and t=
ied into the existing compile time reflection system, we could reap similar=
benefits. One popular pattern in the serialization libraries you describe =
is that, for performance reasons, runtime reflection can be abandoned in fa=
vor of runtime code generation, where the same reflection system is used on=
ce to dynamically write code that can be used repeatedly. D has the advanta=
ge that such code can be written at compile time.</div>
<div>True, runtime reflection would make this sort of thing more clean and =
decoupled, but even using compile time reflection, quite a bit is feasible =
if user-defined attributes are defined.</div></div><br>
--20cf3054a2e94c3e43049b6d3e3c--

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

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.

I recommend looking at Ruby, it has very good support for runtime
reflection. ActiveRecord in Rails is hevaly based on runtime reflection.
For example, given the following Ruby class:
class Post < ActiveRecord::Base
end
The class "Post" maps to the database table "posts", no configuration is
necessary. Then you can use the column names in the table as fields to
set and get data, like this:
post = Post.new
post.title = "some title"
post.body = "the body"
post.save # will update the database
All this is done using runtime reflection. Then you can query the
database, also using runtime reflection:
Post.find_by_name_and_body("some title", "the body")
Will find the first row where "title" and "body" matches the given values.
--
/Jacob Carlborg

The class "Post" maps to the database table "posts", no configuration is
necessary. Then you can use the column names in the table as fields to
set and get data, like this:
post = Post.new
post.title = "some title"
post.body = "the body"
post.save # will update the database

Note that you can do this kind of thing with D's compile time
reflection and CTFE as well. That particular example works
in my own DataObject class (except I called it "commitChanges"
instead of "save").
Some of the stuff is just dynamic; just sugar around a string[string].
Most my own use of "runtime reflection" is just having some CTFE
go through and put the compile time info into those strings which
are used at runtime.
I do that for calling functions by name too, but mine does rely
upon some static info that probably isn't available to the OP.
For example for both, my new newsreader does both:
http://arsdnet.net/d-web-site/nntp/get-message
That screen is automatically generated by this prototype:
Post getMessage(string newsgroup, string messageId) {
The name of the function and arguments in the URL are pulled from
that single line of code. It uses the types of the arguments to
automatically generate an appropriate form.
The way I did it was to put all the public functions in a static
struct. Then, I mixin a template (called FancyMain!(methodStruct))
which scans the struct and generates the needed hashmaps and
delegates to call its methods by name.
http://arsdnet.net/d-web-site/arsd/web.d
That code is very ugly... but look at the prepareReflection and
generateWrapper functions.

The class "Post" maps to the database table "posts", no configuration is
necessary. Then you can use the column names in the table as fields to
set and get data, like this:
post = Post.new
post.title = "some title"
post.body = "the body"
post.save # will update the database

Note that you can do this kind of thing with D's compile time
reflection and CTFE as well. That particular example works
in my own DataObject class (except I called it "commitChanges"
instead of "save").

Yeah, I tried to do the same. But in this case the static type system
was kind of in the way of what I wanted to do. This is so much easier
with a dynamic type system.
--
/Jacob Carlborg

I recommend looking at Ruby, it has very good support for runtime
reflection.
ActiveRecord in Rails is hevaly based on runtime reflection. For
example, given
the following Ruby class:
class Post < ActiveRecord::Base
end
The class "Post" maps to the database table "posts", no configuration is
necessary. Then you can use the column names in the table as fields to
set and
get data, like this:
post = Post.new
post.title = "some title"
post.body = "the body"
post.save # will update the database
All this is done using runtime reflection. Then you can query the
database,
also using runtime reflection:
Post.find_by_name_and_body("some title", "the body")
Will find the first row where "title" and "body" matches the given
values.

Actually I never showed how to do "call by name" in Ruby, just how it
can be used. Ruby has "built in" (not in the language but in the Object
class) support for this:
p Object.new.send(:to_s) # :to_s is a symbol, basically an immutable
lightweight string
The above will print something like: "#<Object:0x101279bb8>"
To implement the "find_by" methods used in my previous examples you
implement the "method_missing" method:
class Foo
def method_missing (method, *args, &block)
p method, args
end
end
Foo.new.bar 3, 4
Will print:
:bar
[3, 4]
--
/Jacob Carlborg

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/

I'm still reading up on Ruby, but so far, there are two major difference
between serialization in Ruby and in D. First, Ruby isn't a systems
programming language with pointers/unions/etc, so serializing all members
of a class is generally okay in Ruby but isn't in D. This is the major
advantage of annotations: its a fast, simple way of declaring what should
and shouldn't be serialized. Second, Ruby's support for serialization
creates a back door around its variable protection annotations (i.e.
private,package,protected,public). Now, Ruby doesn't actually have user
defined annotations as far as I can tell, but methods are always public
and variables are always private. I don't believe that a reflection system
should bypass encapsulation. The advantage of annotations is that they
allow you to declare programmer intent and possibly separate APIs (ala
const(T)) for special purposes.

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

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.

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.

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.

I would argue that if user-defined attributes could be implemented and tied
into the existing compile time reflection system, we could reap similar
benefits. One popular pattern in the serialization libraries you describe
is that, for performance reasons, runtime reflection can be abandoned in
favor of runtime code generation, where the same reflection system is used
once to dynamically write code that can be used repeatedly. D has the
advantage that such code can be written at compile time.
True, runtime reflection would make this sort of thing more clean and
decoupled, but even using compile time reflection, quite a bit is feasible
if user-defined attributes are defined.

I've never really sat down to try and figure out how well compile time
reflection
would work for that sort of thing (particularly since D is the only language I
know of with any kind of compile time reflection), but since we don't have user-
defined attributes yet, we can't do it regardless. If we could pull it off with
compile time reflection, then maybe we wouldn't really need runtime reflection.
I
don't know. But we'll need user-defined attributes before we can do anything
like
that, and exactly what the limitations and possibilities are may not be
particularly clear before we can actually play around with user-defined
attributes and compile time reflection. You may be right though, and runtime
wouldn't be needed to do some of the cooler things that you can do with runtime
reflection in languages like Java. Regardless, I've found compile time
reflection
to be far more helpful in my everday code than I've ever found runtime
reflection
to be.
- Jonathan M Davis

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.

I recommend looking at Ruby, it has very good support for runtime reflection.
ActiveRecord in Rails is hevaly based on runtime reflection. For example, given
the following Ruby class:
class Post < ActiveRecord::Base
end
The class "Post" maps to the database table "posts", no configuration is
necessary. Then you can use the column names in the table as fields to set and
get data, like this:
post = Post.new
post.title = "some title"
post.body = "the body"
post.save # will update the database
All this is done using runtime reflection. Then you can query the database,
also using runtime reflection:
Post.find_by_name_and_body("some title", "the body")
Will find the first row where "title" and "body" matches the given values.