On 2009-04-20 07:25:43 -0400, Christopher Wright <dhasenan@gmail.com> said:

> BCS wrote:
>> Hello Christopher,
>> 
>>> The utility is when you are looking for methods to invoke via runtime
>>> reflection, you can determine that a given function is one of these
>>> runtime opDotExp equivalents.
>> 
>> So it is being argued that there should be a standard way to do a run time function invocation system? I'll buy that.
>> 
>>> I don't know how useful this is, in point of fact. Unless there's a
>>> standard system in D for integrating with scripting languages, anyway.
>> 
>> Maybe there should be.
> 
> But there isn't, so this is YAGNI. And if there were, then this particular issue would immediately be solved.

The thing is that with compile-time reflection you can already build your own runtime-reflection system (with some limitations).

-- 
Michel Fortin
michel.fortin@michelf.com
http://michelf.com/

Steven Schveighoffer wrote:
> Haven't used D2 for much stuff, but does this work?  I remember reading something about partial IFTI, so if you have
> 
> opDotExp(string fname, T...) (T args){}
> 
> and you call
> 
> opDotExp!("b")(c, d, e)
> 
> Does it implicitly define T?
> 
> -Steve

It should, but there's a bug related to variadics (right now it only works with non-variadics); I submitted it recently.

Andrei

Andrei Alexandrescu wrote:
> Steven Schveighoffer wrote:
>> Haven't used D2 for much stuff, but does this work?  I remember reading something about partial IFTI, so if you have
>>
>> opDotExp(string fname, T...) (T args){}
>>
>> and you call
>>
>> opDotExp!("b")(c, d, e)
>>
>> Does it implicitly define T?
>>
>> -Steve
> 
> It should, but there's a bug related to variadics (right now it only works with non-variadics); I submitted it recently.

Found it. Walter seems to get genuinely interested in opDot so vote up, fixing this bug may become important starting 2.030 :o).

http://d.puremagic.com/issues/show_bug.cgi?id=2615


Andrei

Michel Fortin wrote:
> On 2009-04-20 07:25:43 -0400, Christopher Wright <dhasenan@gmail.com> said:
> 
>> BCS wrote:
>>> Hello Christopher,
>>>
>>>> The utility is when you are looking for methods to invoke via runtime
>>>> reflection, you can determine that a given function is one of these
>>>> runtime opDotExp equivalents.
>>>
>>> So it is being argued that there should be a standard way to do a run time function invocation system? I'll buy that.
>>>
>>>> I don't know how useful this is, in point of fact. Unless there's a
>>>> standard system in D for integrating with scripting languages, anyway.
>>>
>>> Maybe there should be.
>>
>> But there isn't, so this is YAGNI. And if there were, then this particular issue would immediately be solved.
> 
> The thing is that with compile-time reflection you can already build your own runtime-reflection system (with some limitations).

You're telling me?
http://felt-project.org/reflect/trunk

Danny Wilson wrote:
> Now let's go from that obvious observation to opDotExp()
> 
> You know the class uses opDotExp() because it said so in the docs. Examples that could really benifit from this are:
> - XMLRPC and other kinds of remoting
> - Quick access to: XML / JSON / Yaml / Config files / DB access
> - Calling DLLs without bindings
> - Lots more
> 
> All these would mention it in their docs, guaranteed. Because they use opDotExp it's implicitly mentioned. I don't think anyone would tell a documentation generator to list all public methods except opDotExp .. that would be just braindead. And you could generate the docs yourself if you have to code..

Incidentally, one ugly problem with using opDotExp is that the underlying invocation might allow characters that aren't legal in D identifiers.

For example, let's say I have a dynamic object wrapping a JavaScript library, and I want to access a JQuery object. JavaScript allows the '$' character to appear in identifiers, and the JQuery people cleverly used that name for one of their core objects (which, I think, acts as an ID registry, or something like that).

So, this is a perfectly legal JQuery expression:

   var a = $("hello");

Using the opDotExp syntax, I'd ideally prefer to call it like this:

   auto a = js.$("hello");

But the compiler will reject that syntax, since '$' isn't a legal D identifier. Of course, in cases like that, we'll just use some sort of dynamic invocation method:

   auto a = js.invoke("$", "hello");

Which makes me think this whole discussion is kind of a waste of time, since every single implementation of opDotExp is going to end up delegating to a string-based dispatcher method anyhow.

THAT'S the really interesting discussion. In fact, I think I'll start a new topic...

--benji

davidl wrote:
> Any comments? Do you like this feature?

And here it is (called opDispatch, Michel Fortin's suggestion):

http://www.dsource.org/projects/dmd/changeset?new=trunk%2Fsrc@268&old=trunk%2Fsrc@267

Walter Bright:
> And here it is (called opDispatch, Michel Fortin's suggestion):<

That's short code.
Do you like my related suggestion of opDynamic (that works with run-time method names)?

Bye,
bearophile

bearophile wrote:
> Walter Bright:
>> And here it is (called opDispatch, Michel Fortin's suggestion):<
> 
> That's short code.
> Do you like my related suggestion of opDynamic (that works with run-time method names)?

opDispatch can be written to do runtime method names, no language changes needed.

Walter Bright:
> opDispatch can be written to do runtime method names, no language changes needed.

Very good. Then the opDynamic name wasn't wrong.
Can someone show me a small example of how to use it with runtime method names?

Bye,
bearophile

On Sun, 29 Nov 2009 00:37:34 +0100, Walter Bright <newshound1@digitalmars.com> wrote:

> davidl wrote:
>> Any comments? Do you like this feature?
>
> And here it is (called opDispatch, Michel Fortin's suggestion):
>
> http://www.dsource.org/projects/dmd/changeset?new=trunk%2Fsrc@268&old=trunk%2Fsrc@267

Just tested it - it does not seem to allow template parameters beyond just the
function name. Is this something we can expect in the future?
The use case I have is this:

struct foo {
  void opDispatch( string name, T )( T value ) {
    static if ( is( T == float ) ) {
      // Do something
    } else static if ( T == int ){

    } else {
      static assert( false, "Unsupported argument type." );
    }
  }
}

Thank you,
  Simen