"Rainer Deyke" <rainerd@eldwood.com> wrote in message news:gsbodm$mjc$1@digitalmars.com...
> Nick Sabalausky wrote:
>> But anyway, like I've said before, syntactic sugar is fine, but this is
>> syntactic sugar that undermines the programmer's ability to rely on
>> compile-time checking of class members. "But only for the classes that
>> use
>> it." No, it undermines that trust across the board because it's
>> non-obvious
>> what classes are using it, so you'd have to always be on guard. "Operator
>> overloading blah blah blah" That only causes problems when it's used
>> *and*
>> abused by a class, while this would cause problems *any* time it's used.
>> Etc
>> etc...
>
> Compile time checking is not undermined at all, even for classes that use this functionality.  opDotExp just makes it easier to create classes with a large, possibly infinite set of members.  There are three possible cases:
>
> 1. The class does not use opDotExp.  Compile time member checking is not undermined.
>
> 2. The body of opDotExp triggers an error at compile time if it receives an unexpected name.  Compile time member checking is not undermined, although the specific error message may have changed.
>
> 3. The body of opDotExp accepts all names.  Compile time member checking is not undermined, we just have a class that has every legal identifier as a member.
>

If the member-name parameter to opDotExp was *required* to be a template paramater, then I agree, and I would have no objections to having that. But it should be pointed out that that would not actually be dynamic invokation, since you wouldn't be able to invoke a member whose name is only known at run-time. (But I would love for that to be possible through a reflection API.)

"Nick Sabalausky" <a@a.a> wrote in message news:gsbru0$rb6$1@digitalmars.com...
> "Don" <nospam@nospam.com> wrote in message news:gsbovk$nbj$1@digitalmars.com...
>>
>> The problem is a lack of notification at compile time. Runtime exceptions are the problem, not the solution.
>>
>> By the way, if the opDot is a template (per Andrei's suggestion), then if
>> it is marked as nothrow, you have a guarantee that if it compiles, it's
>> valid.
>> nothrow opDot(char [])(args...) doesn't have any of the problems which
>> Nick et. al have mentioned.
>
> Ok, now *that* is something I can be happy with.
>

In fact, now that I think about it, as long as the member name was required to be a template parameter, I'd be perfectly happy with it (and wouldn't even want nothrow to be required).

I think that's slightly different from what Andrei's advocated though. Unless I misread something, Andrei, you want it to be possible for the member name to be *either* a template or non-template param, right?

On 18/04/2009 04:54, Steven Schveighoffer wrote:

> I'm all for expanding runtime introspection that remains within the type
> system, I'm even for adding some possibility to create dynamically
> dispatched functions, as long as those functions are called differently
> from normal functions.
>
> -Steve

Here's an idea:
Allow the use of this feature _only_ for appropriately marked types.
dynamic class A {... opDotExp ...} //compiles
dynamic struct B {... opDotExp ...} //compiles

class A {... opDotExp ...} // compile-error: "please mark class as dynamic"
struct B {... opDotExp ...} // as above

now you have an easy way to know if a type is dynamic without changing the method invocation syntax. A proper IDE can easily mark those Types as different, for example, using a different color.

Nick Sabalausky wrote:
> "Nick Sabalausky" <a@a.a> wrote in message news:gsbru0$rb6$1@digitalmars.com...
>> "Don" <nospam@nospam.com> wrote in message news:gsbovk$nbj$1@digitalmars.com...
>>> The problem is a lack of notification at compile time. Runtime exceptions are the problem, not the solution.
>>>
>>> By the way, if the opDot is a template (per Andrei's suggestion), then if it is marked as nothrow, you have a guarantee that if it compiles, it's valid.
>>> nothrow opDot(char [])(args...) doesn't have any of the problems which Nick et. al have mentioned.
>> Ok, now *that* is something I can be happy with.
>>
> 
> In fact, now that I think about it, as long as the member name was required to be a template parameter, I'd be perfectly happy with it (and wouldn't even want nothrow to be required).
> 
> I think that's slightly different from what Andrei's advocated though. Unless I misread something, Andrei, you want it to be possible for the member name to be *either* a template or non-template param, right? 
> 
> 

I think there's a confusion somewhere. Are you sure you know what you don't like? :o)

It's simple, really. First off, there's no way you can pass a variable string as a method name with a regular syntax:

string foo = "bar"';
Dynamic d;
d.foo(); // passes "foo", not "bar"

I hope this clarifies that confusion.

If you want to invoke a method known as a string variable, opDot or whatever has nothing to do with it. You don't need any change to the language at all, because you'd write:

string foo = "bar";
d.call(foo); // call method bar

What opDot does is to allow the regular member syntax while still allowing the callee to look up the name statically or dynamically (assuming the method name is passed into opDot as a template parameter).  Note, again, that opDot has everything to do with the syntax and next to nothing to do with the semantics, which is realizable without any change in the language. And that's how the cookie crumbles. I understand you don't like that, but at least we should be clear on where the feature starts and where it ends.


Andrei

Yigal Chripun wrote:
> On 18/04/2009 04:54, Steven Schveighoffer wrote:
> 
>> I'm all for expanding runtime introspection that remains within the type
>> system, I'm even for adding some possibility to create dynamically
>> dispatched functions, as long as those functions are called differently
>> from normal functions.
>>
>> -Steve
> 
> Here's an idea:
> Allow the use of this feature _only_ for appropriately marked types.
> dynamic class A {... opDotExp ...} //compiles
> dynamic struct B {... opDotExp ...} //compiles
> 
> class A {... opDotExp ...} // compile-error: "please mark class as dynamic"
> struct B {... opDotExp ...} // as above
> 
> now you have an easy way to know if a type is dynamic without changing the method invocation syntax. A proper IDE can easily mark those Types as different, for example, using a different color.

The dynamic behavior is indicated by the use of opDotExp. The redundancy of the two notations doesn't quite sit well.

Andrei

"Andrei Alexandrescu" <SeeWebsiteForEmail@erdani.org> wrote in message news:gsav4n$2ij4$1@digitalmars.com...
>
> It's a good question. opDotExp leaves more flexibility because it allows for a host of compile-time manipulations, e.g. decide to forward to a member etc. Also consider this (probably Nick will turn blue):
>
> struct Pascalize(T)
> {
>     T m;
>     auto opDotExp(string name, T...)(T args)
>     {
>         return mixin("m."~tolower(name))(args);
>     }
> }
>
> struct S { void foo() { ... } }
>
> Pascalize!S s;
> s.foo(); // works
> s.Foo(); // works too
> s.fOo(); // yup, works again
>

It's really late, so I can't come up with much coherent thought, but:

1. Ick.

2. Wasn't the potential for just that sort of abuse a big part of the reason for ditching #define?

3.
struct F { void fooBar() { ... } }
Pascalize!F f; // Can't invoke shit!
// Don't ask me what point I'm trying to make with that,
// I don't even know, myself.

"Andrei Alexandrescu" <SeeWebsiteForEmail@erdani.org> wrote in message news:gsbv56$13c2$1@digitalmars.com...
>
> I think there's a confusion somewhere. Are you sure you know what you don't like? :o)
>

Over here it's 3:30 in the morning at the moment: I don't know a damn thing about anything right now ;) Least of which being why I'm even bothering to make such a completely pointless post or why I'm sitting here reading posts and complaining about the time instead of just going to bed... But I definitely want to read that over later this afternoon, maybe I'll have some better thoughts about the whole thing at that point. I tried to just now, and it's just random letters to me :) I'm sure it'll make perfect sense this afternoon though.

Nick Sabalausky wrote:
> If the member-name parameter to opDotExp was *required* to be a template
> paramater, then I agree, and I would have no objections to having that. But
> it should be pointed out that that would not actually be dynamic invokation,
> since you wouldn't be able to invoke a member whose name is only known at
> run-time. (But I would love for that to be possible through a reflection
> API.)

As we can all clearly see, in obj.someDynamicFunction( "Foo!" ); "someDynamicFunction" is definately known at compile-time, and not something you could change at runtime. Thus, making the member name parameter a template parameter seems the most logical solution. The fact you can't invoke arbitrary members chosen at runtime with it has little to do with opDotExp and much to do with how the D language is. If you want true dynamic invocation you need a separate function anyway, or you'd end up with code like this:

string s = "someDynamicFunction";
obj.opDotExp( s );

Now, you could simply alias "opDotExp" to "invoke" or whatever you please, but having invoke be a separate function does not seem like a horrible trade-off to me.

--
Simen

Op Sat, 18 Apr 2009 09:24:39 +0200 schreef Andrei Alexandrescu <SeeWebsiteForEmail@erdani.org>:

>>  now you have an easy way to know if a type is dynamic without changing the method invocation syntax. A proper IDE can easily mark those Types as different, for example, using a different color.
>
> The dynamic behavior is indicated by the use of opDotExp. The redundancy of the two notations doesn't quite sit well.
>
> Andrei

Not necessarily.

dynamic class A {
 void opDotExp... // compiles
}

class A {
 void opDotExp... // error
}

class A {
 void nothrow opDotExp... // compiles
}


But yea its still redundant ofcourse. The 'proper' IDE could color classes which have an opDotExp (thats allowed to throw) differently just aswell.

Op Sat, 18 Apr 2009 00:22:25 +0200 schreef Christopher Wright <dhasenan@gmail.com>:

> Let's say you integrate D with a scripting language where you can add methods to an object at arbitrary times. Instead of writing:
> scriptObj.invokeMethod("methodname", arguments);

I thought that would be the obvious application, and decided to mention the haXe instead :-)
Guess it's only obvious for someone used to dynamic languages...