www.digitalmars.com         C & C++   DMDScript  

digitalmars.D - UCFS, Reflection/Metadata, Overload Resolution, Templates, and other issues

reply %u <wfunction hotmail.com> writes:
I was trying to write a "Dynamic" class for D, which uses opDispatch
to allow for late binding, but I ran into a problem:

While my class works well for regular methods inside a class, it
fails to work for:
(1) Template methods inside a class
(2) Methods with overloads
(3) Global methods that have nothing to do with a class, like
writeln
Furthermore, it would also fail to work for (4) UCFS if/when it's
implemented.

It seems like templates by design *don't* allow for anything to
happen dynamically, and at the same time, it seems like _everything_
is becoming a template nowadays.

So my question is, is there anything we can do about it (either now
or later)? Or is a dynamic extension simply beyond the reach of D?
Apr 07 2011
next sibling parent reply "Steven Schveighoffer" <schveiguy yahoo.com> writes:
On Thu, 07 Apr 2011 14:20:53 -0400, %u <wfunction hotmail.com> wrote:

 I was trying to write a "Dynamic" class for D, which uses opDispatch
 to allow for late binding, but I ran into a problem:

 While my class works well for regular methods inside a class, it
 fails to work for:
 (1) Template methods inside a class
 (2) Methods with overloads
 (3) Global methods that have nothing to do with a class, like
 writeln
 Furthermore, it would also fail to work for (4) UCFS if/when it's
 implemented.

 It seems like templates by design *don't* allow for anything to
 happen dynamically, and at the same time, it seems like _everything_
 is becoming a template nowadays.

 So my question is, is there anything we can do about it (either now
 or later)? Or is a dynamic extension simply beyond the reach of D?

I tried a "wrapper" type using opDispatch in dcollections, but what I ran into is, opDispatch uses its called parameter types to decide the function parameter types, you have very little control over that. I basically ended up abandoning the use of opDispatch and implemented each covered function by hand. I filed an enhancement request for it, which probably doesn't cover everything you listed, but it might help: http://d.puremagic.com/issues/show_bug.cgi?id=4998 -Steve
Apr 07 2011
next sibling parent reply %u <wfunction hotmail.com> writes:
 I tried a "wrapper" type using opDispatch in dcollections, but what

the function parameter types, you have very little control over that. I basically ended up abandoning the use of opDispatch and implemented each covered function by hand. I managed to get this far (my file attached), using D-style runtime variadic functions... it seems to work well in most cases, with the notable exceptions being: (1) Things I already mentioned (2) Possibly ref/out/lazy parameters (I haven't tested them yet) Any thoughts?
Apr 07 2011
parent %u <wfunction hotmail.com> writes:
 What's UCFS?

Whoops, typo. xD Uniform Function Call Syntax. :)
Apr 07 2011
prev sibling parent Caligo <iteronvexor gmail.com> writes:
What's UCFS?
Apr 07 2011
prev sibling parent reply "Robert Jacques" <sandford jhu.edu> writes:
On Thu, 07 Apr 2011 14:20:53 -0400, %u <wfunction hotmail.com> wrote:

 I was trying to write a "Dynamic" class for D, which uses opDispatch
 to allow for late binding, but I ran into a problem:

 While my class works well for regular methods inside a class, it
 fails to work for:
 (1) Template methods inside a class
 (2) Methods with overloads
 (3) Global methods that have nothing to do with a class, like
 writeln
 Furthermore, it would also fail to work for (4) UCFS if/when it's
 implemented.

 It seems like templates by design *don't* allow for anything to
 happen dynamically, and at the same time, it seems like _everything_
 is becoming a template nowadays.

 So my question is, is there anything we can do about it (either now
 or later)? Or is a dynamic extension simply beyond the reach of D?

I've added reflection capabilities to an update to std.variant I'm working on. Overloads work. General functions work. (Although a few bugs with opCall and opDispatch prevents the ideal syntax: var.x(5) vs var.x = 5 and var.call(5) vs var(5), but I assume those will be eventually fixed). I've also added an internal type database, so you can auto-magically build a Variant(TypeInfo, void*) or Variant(Object) and then call methods on the real, underlying type. Templates, I think, will out of the range of dynamic D capabilities for some time to come. Also, because I'm wrapping / unwrapping all arguments, ref doesn't work.
Apr 07 2011
next sibling parent reply %u <wfunction hotmail.com> writes:
 I've added reflection capabilities to an update to std.variant I'm working on.
Overloads work.

var.x(5) vs var.x = 5 and var.call(5) vs var(5), but I assume those will be eventually fixed). I've also added an internal type database, so you can auto-magically build a Variant(TypeInfo, void*) or Variant(Object) and then call methods on the real, underlying type. Whoa nice. I'm eagerly waiting to see it. :)
 Templates, I think, will out of the range of dynamic D capabilities for some
time to come.

Yeah, 'cause I just realized they basically need you to implement the entire compiler.
Apr 08 2011
parent reply %u <wfunction hotmail.com> writes:
Thanks for the link!

I tried compiling the file, and I got these errors:

variant.d(454): Warning: statement is not reachable
variant.d(454): Warning: statement is not reachable
variant.d(454): Warning: statement is not reachable
variant.d(634): Warning: statement is not reachable
variant.d(660): Warning: statement is not reachable
variant.d(337): Error: template variant.Variant.Box.opAssign(A : Variant) does
not match any function template declaration
variant.d(337): Error: template variant.Variant.Box.opAssign(A : Variant)
cannot deduce template function from argument types !
()(char[])
variant.d(612): Error: template instance variant.Variant.Box.opAssign!(char[])
error instantiating
variant.d(1041): instantiated from here: __vtableOf!(char[])
variant.d(605): instantiated from here: opAssign!(char[])
variant.d(757): instantiated from here: SaveResult!(char[])
    ... (23 instantiations, -v to show) ...
variant.d(376): instantiated from here: SaveResult!(TypeInfo)
variant.d(351): instantiated from here: __vtableOf!(void)

Any ideas how I should fix them?
Apr 09 2011
parent reply %u <wfunction hotmail.com> writes:
 Sorry. It was late and I forgot to mention some things. A) My code is
dependent on patch 5155, and B) I forgot about

docs. Let me know if you have any issues with this. (And please include a brief description of what/how you're building it: i.e. dmd 2.052, debug mode, etc) Also, if you want to try my updated std.json, it requires a few more patches, each listed at the top of the file. Whoops my bad. I'm using DMD 2.052, the version on the website, to compile variant.d. I tried recompiling the file (standalone) and got the same error again; I suspect it's because of the patch 5155 you mentioned, which I haven't applied. I'm actually not familiar with the patching system yet, so I'll try to use your file when I find a bit more time to figure it out. Thanks! :)
Apr 09 2011
parent %u <wfunction hotmail.com> writes:
 Well, 5155 is fairly simple. The bug report details four one line

http://d.puremagic.com/issues/show_bug.cgi?id=5155 Also, If that doesn't do the trick, please e-mail me as I would like to fix the root cause. (And let you test the library) Oops sorry, I got a bit busier these couple of days and totally forgot about this. I'll try to come back to it in the near future, and I'll let you know if I have any success/failure. Thanks for the info! :)
Apr 12 2011
prev sibling next sibling parent "Robert Jacques" <sandford jhu.edu> writes:
On Fri, 08 Apr 2011 11:31:48 -0400, %u <wfunction hotmail.com> wrote:

 I've added reflection capabilities to an update to std.variant I'm  
 working on. Overloads work.

prevents the ideal syntax: var.x(5) vs var.x = 5 and var.call(5) vs var(5), but I assume those will be eventually fixed). I've also added an internal type database, so you can auto-magically build a Variant(TypeInfo, void*) or Variant(Object) and then call methods on the real, underlying type. Whoa nice. I'm eagerly waiting to see it. :)

Here's a snapshot I posted a while ago, if you'd like to have a look: https://jshare.johnshopkins.edu/rjacque2/public_html/ I'd love some feedback, particularly with regard to the runtime-reflection API.
 Templates, I think, will out of the range of dynamic D capabilities for  
 some time to come.

Yeah, 'cause I just realized they basically need you to implement the entire compiler.

Yah, you'd need a VM.
Apr 08 2011
prev sibling next sibling parent "Robert Jacques" <sandford jhu.edu> writes:
On Sat, 09 Apr 2011 04:07:11 -0400, %u <wfunction hotmail.com> wrote:

 Thanks for the link!

 I tried compiling the file, and I got these errors:

 variant.d(454): Warning: statement is not reachable
 variant.d(454): Warning: statement is not reachable
 variant.d(454): Warning: statement is not reachable
 variant.d(634): Warning: statement is not reachable
 variant.d(660): Warning: statement is not reachable
 variant.d(337): Error: template variant.Variant.Box.opAssign(A :  
 Variant) does not match any function template declaration
 variant.d(337): Error: template variant.Variant.Box.opAssign(A :  
 Variant) cannot deduce template function from argument types !
 ()(char[])
 variant.d(612): Error: template instance  
 variant.Variant.Box.opAssign!(char[]) error instantiating
 variant.d(1041): instantiated from here: __vtableOf!(char[])
 variant.d(605): instantiated from here: opAssign!(char[])
 variant.d(757): instantiated from here: SaveResult!(char[])
     ... (23 instantiations, -v to show) ...
 variant.d(376): instantiated from here: SaveResult!(TypeInfo)
 variant.d(351): instantiated from here: __vtableOf!(void)

 Any ideas how I should fix them?

Sorry. It was late and I forgot to mention some things. A) My code is dependent on patch 5155, and B) I forgot about changes, etc, that I had to make to go from DMD 2.051 to DMD 2.052. I've uploaded my current working copy and remade the docs. Let me know if you have any issues with this. (And please include a brief description of what/how you're building it: i.e. dmd 2.052, debug mode, etc) Also, if you want to try my updated std.json, it requires a few more patches, each listed at the top of the file.
Apr 09 2011
prev sibling parent "Robert Jacques" <sandford jhu.edu> writes:
On Sat, 09 Apr 2011 18:08:58 -0400, %u <wfunction hotmail.com> wrote:

 Sorry. It was late and I forgot to mention some things. A) My code is  
 dependent on patch 5155, and B) I forgot about

uploaded my current working copy and remade the docs. Let me know if you have any issues with this. (And please include a brief description of what/how you're building it: i.e. dmd 2.052, debug mode, etc) Also, if you want to try my updated std.json, it requires a few more patches, each listed at the top of the file. Whoops my bad. I'm using DMD 2.052, the version on the website, to compile variant.d. I tried recompiling the file (standalone) and got the same error again; I suspect it's because of the patch 5155 you mentioned, which I haven't applied. I'm actually not familiar with the patching system yet, so I'll try to use your file when I find a bit more time to figure it out. Thanks! :)

Well, 5155 is fairly simple. The bug report details four one line changes to Object.di and Object_.d. See http://d.puremagic.com/issues/show_bug.cgi?id=5155 Also, If that doesn't do the trick, please e-mail me as I would like to fix the root cause. (And let you test the library)
Apr 10 2011