Fully dynamic d by opDotExp overloading

[Adam Burton]

BCS wrote:

> Hello Adam,
> 
>> BCS wrote:
>> 
>>> Hello Adam,
>>> 
>>>> 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.
>>> Going the other way would be better; '.' works as Andrei wants and
>>> '->' is an explicit, "don't use the dynamic stuff" invocation. If it
>>> went the other way virtually all template code would end up needing
>>> to use '->' for everything just in cases someone wants to pass in a
>>> type that uses opDotExp.
>>> 
>> Yea and that would be bad, since then as far as I am concerned you
>> have destroyed the purpose of templates. Seems to me templates and
>> dynamic calls are sorta there to solve the same problem, how do you
>> write code that is independent of type? Dynamic takes it to extreme
>> and makes the evaluation of methods (or public types variables I don't
>> see how that would be different) and leave it all to runtime which is
>> far more flexible but potentially has holes if the type doesn't meet
>> the requirements. Templates take a more conservative route by still
>> letting you write independent of type but then using the information
>> provided at call time it can still perform static code checks to make
>> sure the type meets its needs, making it a little more safe than
>> dynamic. However soon as you throw some dynamic calls into a template
>> the guarantees usually provided go out the window since the template
>> is letting that none existent member slip by.
> 
> I see your point but disagree. I see it more as a "what to do if the code
> author doesn't have full API knowledge?" problem. Templates allow the
> author of the consuming code to go with a "I'll just assume this can be
> done and let the compiler check it" approach and the dynamic option allows
> the author of the producer to go with a "Do whatever you want and if I
> didn't say what to do with it use this code to figure it out" approach.
That's essentially what I was trying to say. What I was adding is that when 
you add the dynamic calls inside the template you lose some of the compile-
time checking (and as mentioned in another post how would you use interface 
constraint with that?) and therefore your template ends up relying on "Do 
whatever you want and if I didn't say what to do with it use this code to 
figure it out" for some portions of the code, so you get a weird hybrid that 
has stepped on templates more than it has dynamic.
> (In the above, you seeme to be working with the assumption of the non
> static opDotExp form. I, BTW, see no use for it as it adds no new
> functionality to D where as the static opDotExp(char[],T...)(T t) form
> adds a new ability)
When you say static opDotExp I am assuming you are talking about the example 
where someone writes a "struct Wrapper(T)" in just a few lines of code to 
wrap a type and add logging (I been bit busy to read rest of the threads so 
I only been replying to stuff following the trail leading up to my post for 
the most part, till now)? If so then yea that does look nice and seems like 
something I would use. It also doesn't contain the holes my proposal is 
attempting to solve since the function name is still evaluated at compile 
time, so removing 'open' from 'ServerProxy' wouldn't magically turn into a 
runtime error as the static assert will kick in.

I also agree that the none static version of opDotExp doesn't bring new 
functionality to the table that is worth having. Personally in them cases I 
would prefer to use dispatch(method, params) directly, it feels less 
obscure, non-static opDotExp just seems like a bit of syntax sugar with more 
issues than it is worth. My concern was if that functionality was 
implemented then using '.' for the dynamic runtime calls means is it would 
cause more problems than it is worth, so my proposal isn't a proposal to add 
the feature (since I doubt I would use it) it's one that says if you are 
going to then I think this method of implementing it is less intrusive.
> [ the rest of the post dealt with implications of non-static forms of
> [ opDotExp
I am sure I have seen some people still arguing for it (but this thread is 
so big with lots of sub-threads I am a little confused as to whether people 
are or whether they have settled to just non-static. Also for me the use of 
the word dynamic from the beginning and the subject of the thread meant 
runtime so I wouldn't really consider static opDotExp dynamic, just clever 
compile-time trickery :-P so talk about that has gone off topic from the 
subject imo) and if that is the case then the proposal still stands as a 
method of implementing it. If however people are not arguing for it and have 
settled on static opDotExp then I quite gladdly remove the proposal :-).

Adam