Yigal Chripun wrote:
> On 18/04/2009 21:16, Andrei Alexandrescu wrote:
>> bearophile wrote:
>>> Andrei Alexandrescu:
>>>> Yes. The amount of confusion in this thread is staggering.
>>>
>>> I think I have misunderstood about the whole thread then. If the
>>> string isn't determined at run time, then this thing isn't useful for
>>> my purposes, and it's not close to the object-C as I was talking
>>> about, and it's not similar to __getattr__ of Python, etc.
>>>
>>> Bye,
>>> bearophile
>>
>> In the syntax
>>
>> a.b
>>
>> how would either of a and b be identified at runtime? I mean, you write
>> the code somewhere and it gets compiled. It's not like you're reading
>> "a.b" from the console and then call some eval() function against them.
>>
>>
>> Andrei
> 
> what prevents D from having an eval function?

Sure it is possible. It has zero relevance to the topic at hand.

Andrei

Adam Burton wrote:
> Jason House wrote:
> 
>> Andrei Alexandrescu Wrote:
>>
>>> Nick Sabalausky wrote:
>>>> Please do not accuse me of such a thing simply because I haven't
>>>> changed my opinion. You've held your ground as well, so I could just as
>>>> easily accuse you of being closed-minded and merely reaffirming a your
>>>> preconceived opinion. I have indeed listened to the arguments and
>>>> responded to them.
>>> Given my track record, I think it should come at no surprise that I'm
>>> not a fan of dynamic typing.
>>>
>>> Andrei
>> I'm no fan of it either. I will be pissed if one day I'm using a D library
>> and a function name typo becomes a runtime error. There is no program too
>> short for me to introduce typos and bugs.
>>
>> Even still, this dynamic stuff does not bother me much because it only
>> gets turned on if the class designer wanted it. I assume that it'd be a
>> corner of the language I could avoid. The use seems reasonable besides
>> sone bicycle shed coloring, so I plan to sit quietly in the corner and
>> await an outcome.
>>
>> My only 2 cents is to use something other than dot for dynamic function
>> invocation. Given how much I plan to use it, it's probably better for me
>> to abstain.
> I agree.
> 
> Bare with me on this as I am making some assumptions, I don't follow D2 development very closely ... or D as much as I would like these days :-(.
> 
> What about using something like '->' for dynamic calls instead of '.'? 

That's absolutely useless. If I have to write anything different from "." I might as well write "bloodyMaryBloodyMaryBloodyMary".

Andrei

davidl wrote:
> 在 Sun, 19 Apr 2009 03:15:02 +0800，Daniel Keep <daniel.keep.lists@gmail.com> 写道:
> 
>>
>>
>> Andrei Alexandrescu wrote:
>>> Michel Fortin wrote:
>>>> ...
>>>>
>>>> Andrei, I think you, and perhaps everyone here, are overlooking one
>>>> small but important detail.
>>>>
>>>> opDotExp, if a template like you're adovcating, undermines future
>>>> runtime dynamic call capabilities (which are part of most runtime
>>>> reflection systems).
>>>>
>>>> If you're going to have something such as
>>>>
>>>>     d.invoke("foo");
>>>>
>>>> available on any type (using some yet-to-see runtime reflection), it
>>>> will work for a non-template opDotExp (invoke would just forward to
>>>> opDotExp with the string "foo" if it doesn't find the member through
>>>> reflection), but it cannot work for an opDotExp template using "foo"
>>>> as a template argument since string "foo" is a runtime argument. (In
>>>> fact, I don't see how any template can be callable from runtime
>>>> reflection.)
>>>>
>>>> It ensues that if later we add runtime reflection to D, dynamic calls
>>>> won't work for template opDotExp.
>>>>
>>>> So I'm not really convinced that template is the way to go, even
>>>> though it would allow great things. Almost all you can do with a
>>>> template, you already can do by adding members using a mixin. And
>>>> adding members using a mixin will also work with runtime reflection,
>>>> unlike templated opDotExp. The only use case left unadressed by mixins
>>>> and runtime opDotExp is the function with an infinite number of
>>>> members which want compile time dispatching.
>>>>
>>>> Perhaps we need both template and runtime opDotExp...
>>>>
>>>> Anyway, I like the general concept so I hope we'll get it, template or
>>>> not. I just feel the point above has been neglected in the discussion.
>>>
>>> I'm confused. Isn't it clear that at the moment we "have" the ability to
>>> pass a function name as a runtime string? What we're lacking is the
>>> ability to implement that using reflection, but that's an entirely
>>> separated discussion!
>>>
>>> And no, you're not supposed to forward from invoke(string, Variant[]...)
>>> to opDotExp - it's precisely the other way around! I'm not sure where
>>> I'm wrong in explaining this, it looks like I'm unable to remove a very
>>> persisting confusion.
>>>
>>> So let me restate: opDotExp taking a runtime string does not EXPAND your
>>> options, it severely LIMITS them. It's very simple: with the former you
>>> have strictly LESS options and no NOTHING in terms of added power. It's
>>> simple, I swear.
>>>
>>>
>>> Andrei
>>
>> A related issue is that obj.opDotExp!"foo"(...) cannot be reflected over
>> because template instantiations aren't part of the typeinfo.
>>
>> Which means if you DO have any methods accessed via opDotExp, you CAN'T
>> invoke them dynamically at runtime, but you COULD if it took a string
>> argument instead of a string template argument.
>>
> 
> Umm, actually you can... but with bad duplication in code:
> 
> void Invoke(methodname, ...)
> {
>   if (methodname = "compile_time_dispatched_method")    // these sort of comparison exists in template opDot in a static manner.
>   {
>     opDot("compile_time_dispatched_method")(args);
>   }
> }
> 
> Yes, we get duplication here. I don't have an idea to solve the duplication elegantly yet. Maybe string mixins?
> 
>> Just sayin' :)

What you want is:

void opDot(string name, T...)(T args)
{
   invoke(name, variantArray(args));
}

void invoke(string name, Variant[] args)
{
   ...
}

So it's precisely the other way around. I agree you _could_ call things the other way, but it goes against the natural way.


Andrei

Hello Yigal,

> On 18/04/2009 21:16, Andrei Alexandrescu wrote:
> 
>> In the syntax
>> 
>> a.b
>> 
>> how would either of a and b be identified at runtime? I mean, you
>> write the code somewhere and it gets compiled. It's not like you're
>> reading "a.b" from the console and then call some eval() function
>> against them.
>> 
>> Andrei
>> 
> what prevents D from having an eval function?
> suppose someone modifies the DMD front-end to compile a string with
> the
> source code of a function in-memory, than this is processed by
> something
> based on DDL and what you get is an API call that takes source code in
> a
> string and returns a function pointer.

Even then it is *still* going to be compile time. Just a compile time running at runtime... Ooohh, my heads's going to start hearing here in a bit.

Yigal Chripun wrote:
>
> what prevents D from having an eval function?
> suppose someone modifies the DMD front-end to compile a string with the source code of a function in-memory, than this is processed by something based on DDL and what you get is an API call that takes source code in a string and returns a function pointer.

I suggest you read Burton Radons' "The Joy and Gibbering Terror of Custom-Loading Executable".
http://members.shaw.ca/burton-radons/The%20Joy%20and%20Gibbering%20Terror%20of%20Custom-Loading%20Executables.html

--
Simen

bearophile wrote:
> Andrei Alexandrescu:
>> Yes. The amount of confusion in this thread is staggering.
> 
> I think I have misunderstood about the whole thread then. If the string isn't determined at run time, then this thing isn't useful for my purposes, and it's not close to the object-C as I was talking about, and it's not similar to __getattr__ of Python, etc.
> 
> Bye,
> bearophile

There are two issues here:
 - The ability to invoke a method where you did not explicitly create a method with that name.
 - A standardized way of looking up a method to invoke based on a string, where that string may be created at runtime. You can already do this, but there's no standard interface for it. If there were an interface somewhere, like IDispatch { Variant invoke(string, ...); }, that would be nice. Though it doesn't work with structs.

In the former case, the method will not exist unless you call it -- for example, swizzling. This is powerful; it means you can use templates to generate the function body.

The latter case doesn't give you very much. I'd like to see it in the standard library, but it wouldn't be called before issuing a MethodMissingException or the like because it isn't applicable.

Andrei Alexandrescu wrote:

> Adam Burton wrote:
>> Jason House wrote:
>> 
>>> Andrei Alexandrescu Wrote:
>>>
>>>> Nick Sabalausky wrote:
>>>>> Please do not accuse me of such a thing simply because I haven't changed my opinion. You've held your ground as well, so I could just as easily accuse you of being closed-minded and merely reaffirming a your preconceived opinion. I have indeed listened to the arguments and responded to them.
>>>> Given my track record, I think it should come at no surprise that I'm not a fan of dynamic typing.
>>>>
>>>> Andrei
>>> I'm no fan of it either. I will be pissed if one day I'm using a D library and a function name typo becomes a runtime error. There is no program too short for me to introduce typos and bugs.
>>>
>>> Even still, this dynamic stuff does not bother me much because it only gets turned on if the class designer wanted it. I assume that it'd be a corner of the language I could avoid. The use seems reasonable besides sone bicycle shed coloring, so I plan to sit quietly in the corner and await an outcome.
>>>
>>> My only 2 cents is to use something other than dot for dynamic function invocation. Given how much I plan to use it, it's probably better for me to abstain.
>> I agree.
>> 
>> Bare with me on this as I am making some assumptions, I don't follow D2 development very closely ... or D as much as I would like these days :-(.
>> 
>> What about using something like '->' for dynamic calls instead of '.'?
> 
> That's absolutely useless. If I have to write anything different from "." I might as well write "bloodyMaryBloodyMaryBloodyMary".
> 
> Andrei
You could even write 'noodles' but that doesn't really give me a reason as to why it's absolutely useless. Please clarify, I thought it seemed like a reasonable idea, if it isn't I would like to know why.

Adam Burton wrote:
> Andrei Alexandrescu wrote:
>>> What about using something like '->' for dynamic calls instead of '.'?
>> That's absolutely useless. If I have to write anything different from
>> "." I might as well write "bloodyMaryBloodyMaryBloodyMary".
>>
>> Andrei
> You could even write 'noodles' but that doesn't really give me a reason as to why it's absolutely useless. Please clarify, I thought it seemed like a reasonable idea, if it isn't I would like to know why.

I apologize for the snapping. There's no excuse really, but let me mention that this thread has been particularly meandering.

The point of using "." is not syntactic convenience as much as the ability of the Dynamic structure to work out of the box with algorithms that use the standard notation.


Andrei

On Sat, Apr 18, 2009 at 06:10:27PM -0700, Andrei Alexandrescu wrote:
> The point of using "." is not syntactic convenience as much as the ability of the Dynamic structure to work out of the box with algorithms that use the standard notation.

What if the dot remained exactly like it is now and the -> took
the place of the dot in the proposal; regular method calls when
possible and forwarded to opExtension (opDotExp needs a better name)
when that fails?

Thus your generic algorithm can use -> and work in all cases, and the dot operator remains the same as it is now.

The obvious downside is duplication of features, but this might be able to please everyone.

> 
> Andrei

-- 
Adam D. Ruppe
http://arsdnet.net

On 2009-04-18 17:48:33 -0400, Andrei Alexandrescu <SeeWebsiteForEmail@erdani.org> said:

> Michel Fortin wrote:
>> On 2009-04-18 11:19:38 -0400, Andrei Alexandrescu <SeeWebsiteForEmail@erdani.org> said:
>> 
>>> I'm confused. Isn't it clear that at the moment we "have" the ability to pass a function name as a runtime string?
>> 
>> Indeed, you can pass the template argument as a runtime argument to another function. No misunderstanding here.
>> 
>> 
>>> What we're lacking is the ability to implement that using reflection, but that's an entirely separated discussion!
>> 
>> Runtime reflection lacking indeed, but wether runtime reflection is an entirely separated discussion depends on if what we're doing will get in the way of implementing it.
>> 
>> 
>>> And no, you're not supposed to forward from invoke(string, Variant[]...) to opDotExp - it's precisely the other way around!
>> 
>> Wrong. Whether it's one way or another entirely depends on what your goals are.
> 
> Wrong. It's impossible to pass a dynamic string as a static string, so the street is one way.

Indeed it's impossible using a template which requires a static string. And that's exactly the problem: some times you're supposed to make it work both ways, as I've explained in the rest of my post you've cut down. Did you read it?

I won't repeat everything, but here's the important part: not having it go both ways *is* an important drawback. And it doesn't go both ways only if opDotExp is a template.

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