www.digitalmars.com         C & C++   DMDScript  

digitalmars.D - Calling method by name.

reply %u <fghf jhgjhb.com> writes:
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
Feb 02 2011
next sibling parent reply Robert Clipsham <robert octarineparrot.com> writes:
On 02/02/11 17:55, %u 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


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/
Feb 02 2011
parent reply Jacob Carlborg <doob me.com> writes:
On 2011-02-02 20:42, Robert Clipsham wrote:

 On 02/02/11 17:55, %u 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


 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
Feb 02 2011
parent reply Robert Clipsham <robert octarineparrot.com> writes:
On 02/02/11 20:00, Jacob Carlborg wrote:

 On 2011-02-02 20:42, Robert Clipsham wrote:

 On 02/02/11 17:55, %u 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


 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/
Feb 02 2011
next sibling parent reply Stanislav Blinov <stanislav.blinov gmail.com> writes:
On 02/02/2011 11:11 PM, Robert Clipsham wrote:

 On 02/02/11 20:00, Jacob Carlborg wrote:

 On 2011-02-02 20:42, Robert Clipsham wrote:

 On 02/02/11 17:55, %u 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


 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.
Feb 02 2011
next sibling parent Andrej Mitrovic <andrej.mitrovich gmail.com> writes:
On 2/2/11, Stanislav Blinov <stanislav.blinov gmail.com> wrote:

 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.


Talk about posting this after I've spent 20 minutes trying to figure
out why getMembers doesn't work!
Feb 02 2011
prev sibling parent reply Jacob Carlborg <doob me.com> writes:
On 2011-02-02 22:51, Stanislav Blinov wrote:

 On 02/02/2011 11:11 PM, Robert Clipsham wrote:

 On 02/02/11 20:00, Jacob Carlborg wrote:

 On 2011-02-02 20:42, Robert Clipsham wrote:

 On 02/02/11 17:55, %u 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


 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
Feb 03 2011
parent Stanislav Blinov <blinov loniir.ru> writes:
03.02.2011 12:54, Jacob Carlborg пишет:

 On 2011-02-02 22:51, Stanislav Blinov wrote:

 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.


Actually, it's that those TypeInfo, MemberInfo et al. are not 
const-correct, as is the case for Object and other Object-related classes.
Feb 03 2011
prev sibling parent Jacob Carlborg <doob me.com> writes:
On 2011-02-02 21:11, Robert Clipsham wrote:

 On 02/02/11 20:00, Jacob Carlborg wrote:

 On 2011-02-02 20:42, Robert Clipsham wrote:

 On 02/02/11 17:55, %u 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


 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
Feb 03 2011
prev sibling next sibling parent reply "Robert Jacques" <sandford jhu.edu> writes:
On Wed, 02 Feb 2011 12:55:37 -0500, %u <fghf 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);
Feb 02 2011
parent reply Jacob Carlborg <doob me.com> writes:
On 2011-02-03 05:52, Robert Jacques wrote:

 On Wed, 02 Feb 2011 12:55:37 -0500, %u <fghf 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?

-- 
/Jacob Carlborg
Feb 03 2011
parent reply "Robert Jacques" <sandford jhu.edu> writes:
On Thu, 03 Feb 2011 08:49:54 -0500, Jacob Carlborg <doob me.com> wrote:


 On 2011-02-03 05:52, Robert Jacques wrote:

 On Wed, 02 Feb 2011 12:55:37 -0500, %u <fghf 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.
Feb 03 2011
next sibling parent reply Jonathan M Davis <jmdavisProg gmx.com> writes:
On Thursday 03 February 2011 19:29:15 Robert Jacques wrote:

 On Thu, 03 Feb 2011 08:49:54 -0500, Jacob Carlborg <doob me.com> wrote:

 On 2011-02-03 05:52, Robert Jacques wrote:

 On Wed, 02 Feb 2011 12:55:37 -0500, %u <fghf 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-

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
Feb 03 2011
parent reply Jacob Carlborg <doob me.com> writes:
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<doob me.com>  wrote:

 On 2011-02-03 05:52, Robert Jacques wrote:

 On Wed, 02 Feb 2011 12:55:37 -0500, %u<fghf 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-

 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
Feb 05 2011
parent reply "Robert Jacques" <sandford jhu.edu> writes:
On Sat, 05 Feb 2011 13:14:42 -0500, Jacob Carlborg <doob me.com> wrote:

 On 2011-02-04 05:07, Jonathan M Davis wrote:


[snip]

 Most of the good examples of runtime reflection that I'm aware of  
 require user-

 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.
Feb 07 2011
parent Jacob Carlborg <doob me.com> writes:
On 2011-02-08 05:54, Robert Jacques wrote:

 On Sat, 05 Feb 2011 13:14:42 -0500, Jacob Carlborg <doob me.com> wrote:

 On 2011-02-04 05:07, Jonathan M Davis wrote:


 [snip]

 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

 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
Feb 08 2011
prev sibling next sibling parent Andrew Wiley <debio264 gmail.com> writes:
On Thu, Feb 3, 2011 at 10:07 PM, Jonathan M Davis <jmdavisProg gmx.com>wrote:


 On Thursday 03 February 2011 19:29:15 Robert Jacques wrote:

 On Thu, 03 Feb 2011 08:49:54 -0500, Jacob Carlborg <doob me.com> wrote:

 On 2011-02-03 05:52, Robert Jacques wrote:

 On Wed, 02 Feb 2011 12:55:37 -0500, %u <fghf 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-

 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.
Feb 03 2011
prev sibling parent reply Jacob Carlborg <doob me.com> writes:
On 2011-02-04 04:29, Robert Jacques wrote:

 On Thu, 03 Feb 2011 08:49:54 -0500, Jacob Carlborg <doob me.com> wrote:


 On 2011-02-03 05:52, Robert Jacques wrote:

 On Wed, 02 Feb 2011 12:55:37 -0500, %u <fghf 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.


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"


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
Feb 04 2011
next sibling parent reply Adam Ruppe <destructionator gmail.com> writes:
Jacob Carlborg wrote:

 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"



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.
Feb 04 2011
parent Jacob Carlborg <doob me.com> writes:
On 2011-02-04 17:17, Adam Ruppe wrote:

 Jacob Carlborg wrote:

 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"



 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
Feb 05 2011
prev sibling parent reply spir <denis.spir gmail.com> writes:
On 02/04/2011 04:33 PM, Jacob Carlborg wrote:

 On 2011-02-04 04:29, Robert Jacques wrote:

 On Thu, 03 Feb 2011 08:49:54 -0500, Jacob Carlborg <doob me.com> wrote:





 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"


 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.


FWIW, python example of "Calling method by name" (using no exotic feature):

class C:
     def __init__(self, x):
         self.x = x
     def write (self, thing):
         print "%s == %s ? %s" \
               %(self.x,thing, self.x==thing)

def runMethodWithArgs (object, name, *args):
     method = getattr(object, name)
     method(*args)

c= C(1.11)
runMethodWithArgs(c, "write", 2.22)


(Explanations if needed.)

Denis
-- 
_________________
vita es estrany
spir.wikidot.com
Feb 04 2011
parent Jacob Carlborg <doob me.com> writes:
On 2011-02-04 20:03, spir wrote:

 On 02/04/2011 04:33 PM, Jacob Carlborg wrote:

 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"


 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.


 FWIW, python example of "Calling method by name" (using no exotic feature):

 class C:
 def __init__(self, x):
 self.x = x
 def write (self, thing):
 print "%s == %s ? %s" \
 %(self.x,thing, self.x==thing)

 def runMethodWithArgs (object, name, *args):
 method = getattr(object, name)
 method(*args)

 c= C(1.11)
 runMethodWithArgs(c, "write", 2.22)


 (Explanations if needed.)

 Denis


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:


lightweight string



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
Feb 06 2011
prev sibling parent Jonathan M Davis <jmdavisProg gmx.com> writes:
On Thursday 03 February 2011 20:23:25 Andrew Wiley wrote:

 On Thu, Feb 3, 2011 at 10:07 PM, Jonathan M Davis <jmdavisProg gmx.com>wrote:

 On Thursday 03 February 2011 19:29:15 Robert Jacques wrote:

 On Thu, 03 Feb 2011 08:49:54 -0500, Jacob Carlborg <doob me.com> wrote:

 On 2011-02-03 05:52, Robert Jacques wrote:

 On Wed, 02 Feb 2011 12:55:37 -0500, %u <fghf 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-

 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
Feb 03 2011