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
