April 17, 2009
On Fri, Apr 17, 2009 at 03:54:47PM -0400, Nick Sabalausky wrote:
> What opDotExp is, is a tool of only occasional use that provides only a small benefit, *and* ends up destroying a much more important tool: compile-time checking on a class's members.

Wouldn't the compile time checking remain the same on any class except the Variant (or whatever) which implements the new operator?

If it is constrained to one type, the destruction seems like it would be acceptable. You can't trust much on a Variant at compile time anyway.

-- 
Adam D. Ruppe
http://arsdnet.net
April 17, 2009
On 17/04/2009 22:54, Nick Sabalausky wrote:
> "Yigal Chripun"<yigal100@gmail.com>  wrote in message
> news:gsam1p$1ut7$1@digitalmars.com...
>> On 17/04/2009 21:58, Steven Schveighoffer wrote:
>>
>> btw, I'm not trying to convince you that dynamic typing is necessary
>> always a better solution. What I'm saying is that I agree with Andrei - we
>> need to be open minded and have as many useful tools as possible in our
>> programmer toolbox. The important thing is to choose the right tool for
>> the job.
>>
>
> Typically, yes, having "as many useful tools as possible in our programmer
> toolbox" is great. But with opDotExp, that's not the whole story. What
> opDotExp is, is a tool of only occasional use that provides only a small
> benefit, *and* ends up destroying a much more important tool: compile-time
> checking on a class's members.
>
> Yea, sure I want more tools in my programmer tool box. But I don't want a
> minor one that's going to mess up one of my major ones just by being in
> there.
>
>
I was talking generally about dynamic vs. static typing and didn't address the specific implementation of opDotExp.
It's just that I wanted to reply to the posts that argued against dynamic typing altogether.
April 17, 2009
Andrei Alexandrescu wrote:
> Nick Sabalausky wrote:
>> "Andrei Alexandrescu" <SeeWebsiteForEmail@erdani.org> wrote in message news:gsak2p$1s8a$1@digitalmars.com...
>>> I think there's merit in binding via strings. It makes for very flexible code that is future-proof, dynamic-linking-friendly, and hot-swappable without recompiling (e.g. you don't need to recompile because you now implement an interface etc.) Reflection is very useful as well.
>>>
>>> I think D can and should allow string lookup for its methods. It's a low-complexity proposition that adds a very interesting tool to D's arsenal.
>>>
>>
>> That's a separate issue. I absolutely agree with the usefulness of being able to invoke static methods via a string identifier at runtime. But I think opDotExp is an extremely flawed way to do it. A much better way would be through a reflection mechanism:
>>
>> class Foo
>> {
>>     void bar() {}
>> }
>>
>> auto foo = new Foo();
>> traits(foo).func("bar").invoke();
>>
>> That way, you can have the benefits of runtime-string-identifier-invocation (and have it on *every* class/method), but without completely loosing compile-time checking on the members of every class which is capable of using it.
> 
> I was expecting this objection. I think it's not based because unifying syntax is a major part of adding such a feature. If we get to dynamic invocation but we can't go the last mile, we failed. Look at IDispatch-based programming in C++ vs. interpreted languages.

I'd even say that this feature is 100% syntax sugar. It doesn't add anything we can't do already (in an ugly way).
April 17, 2009
On Fri, 17 Apr 2009 15:55:43 -0400, Andrei Alexandrescu <SeeWebsiteForEmail@erdani.org> wrote:

> Nick Sabalausky wrote:
>> "Yigal Chripun" <yigal100@gmail.com> wrote in message news:gsam1p$1ut7$1@digitalmars.com...
>>> On 17/04/2009 21:58, Steven Schveighoffer wrote:
>>>
>>> btw, I'm not trying to convince you that dynamic typing is necessary always a better solution. What I'm saying is that I agree with Andrei - we need to be open minded and have as many useful tools as possible in our programmer toolbox. The important thing is to choose the right tool for the job.
>>>
>>  Typically, yes, having "as many useful tools as possible in our programmer toolbox" is great. But with opDotExp, that's not the whole story. What opDotExp is, is a tool of only occasional use that provides only a small benefit, *and* ends up destroying a much more important tool: compile-time checking on a class's members.
>
> s/on a class's members/on the members of the class that actively chose that/

Sure, how do you know that the class actively chose it, or did not actively choose it, or will *never* actively choose it simply by looking at the statement?

The problem with me is that it doesn't *look* different.  If there was some way to denote "call dynamic method" instead of "call static method" or some way to denote "has dynamic methods", then I'd have no problem with it.  Even if you were forced to derive from a special base type in order to use dynamic methods, I wouldn't mind that.

-Steve
April 17, 2009
Nick Sabalausky:
> Maybe so, but I don't see any real benefit from it.

Are you asking me suggestions to help you see such benefits? :-)
Well, find some tasks typically done in such languages, do some of them for few days, trying to follow the typical ways to solve them, and you will probably see the benefits.

Bye,
bearophile
April 17, 2009
"Andrei Alexandrescu" <SeeWebsiteForEmail@erdani.org> wrote in message news:gsamrs$204u$3@digitalmars.com...
>>
>> Typically, yes, having "as many useful tools as possible in our programmer toolbox" is great. But with opDotExp, that's not the whole story. What opDotExp is, is a tool of only occasional use that provides only a small benefit, *and* ends up destroying a much more important tool: compile-time checking on a class's members.
>
> s/on a class's members/on the members of the class that actively chose that/
>

Right, that's what I meant, but that's still worse than not having opDotExp at all.

If someone wants to do dynamic programming, then ok, fine, even though I think they're making a mistake, they're free to go use a dynamic language. But D is supposed to be a static language. That's why I use it. I don't want that staticness to be hijackable just because some people prefer dynamicness. Obviously, if there's a dynamic feature that *doesn't* interfere with the static stuff (the phobos Variant, for example), then that's great. Toss it in and let people use it if they want. Why should I care?

But with opDotExp, its mere *existence* undermines my ability to be sure that non-quoted identifiers are ok as long as they've compiled. That type of tradeoff is obviously fine when the potential benefits are significant enough (operator overloading, for instance). But from everything I've seen so far, opDotExp's benefits are trivial at best. I don't want to have to keep track of "ok, is this class using opDotExp or not, because if it is, then I need to be more careful", just for the sake of a feature that provides such a tiny and questionable benefit.


April 17, 2009
"Adam D. Ruppe" <destructionator@gmail.com> wrote in message news:mailman.1171.1239998473.22690.digitalmars-d@puremagic.com...
> On Fri, Apr 17, 2009 at 03:54:47PM -0400, Nick Sabalausky wrote:
>> What
>> opDotExp is, is a tool of only occasional use that provides only a small
>> benefit, *and* ends up destroying a much more important tool:
>> compile-time
>> checking on a class's members.
>
> Wouldn't the compile time checking remain the same on any class except the Variant (or whatever) which implements the new operator?
>
> If it is constrained to one type, the destruction seems like it would be acceptable. You can't trust much on a Variant at compile time anyway.
>

The problem is there would be no way to tell at a glance whether a given class uses opDotExp or not. You'd have to go look it up for every class. So, ok, we could solve that by requiring a different syntax for dynamic invokation. But we already have that: just pass a string to a dispatch function.


April 17, 2009
Steven Schveighoffer wrote:
> On Fri, 17 Apr 2009 15:55:43 -0400, Andrei Alexandrescu <SeeWebsiteForEmail@erdani.org> wrote:
> 
>> Nick Sabalausky wrote:
>>> "Yigal Chripun" <yigal100@gmail.com> wrote in message news:gsam1p$1ut7$1@digitalmars.com...
>>>> On 17/04/2009 21:58, Steven Schveighoffer wrote:
>>>>
>>>> btw, I'm not trying to convince you that dynamic typing is necessary always a better solution. What I'm saying is that I agree with Andrei - we need to be open minded and have as many useful tools as possible in our programmer toolbox. The important thing is to choose the right tool for the job.
>>>>
>>>  Typically, yes, having "as many useful tools as possible in our programmer toolbox" is great. But with opDotExp, that's not the whole story. What opDotExp is, is a tool of only occasional use that provides only a small benefit, *and* ends up destroying a much more important tool: compile-time checking on a class's members.
>>
>> s/on a class's members/on the members of the class that actively chose that/
> 
> Sure, how do you know that the class actively chose it, or did not actively choose it, or will *never* actively choose it simply by looking at the statement?

You shouldn't worry about it as much as you shouldn't when you iterate a built-in array vs. a user-defined range.

> The problem with me is that it doesn't *look* different.

I understand how it could be a problem. The thing is, it is also an advantage.

>  If there was some way to denote "call dynamic method" instead of "call static method" or some way to denote "has dynamic methods", then I'd have no problem with it.  Even if you were forced to derive from a special base type in order to use dynamic methods, I wouldn't mind that.

Would you like ranges that work very different from built-in arrays, and everybody to special-case around that?

By the way, D's AAs suck partly because they aren't like anything. I *really* hate the way D does AAs.


Andrei
April 17, 2009
Nick Sabalausky wrote:
> "Adam D. Ruppe" <destructionator@gmail.com> wrote in message news:mailman.1171.1239998473.22690.digitalmars-d@puremagic.com...
>> On Fri, Apr 17, 2009 at 03:54:47PM -0400, Nick Sabalausky wrote:
>>> What
>>> opDotExp is, is a tool of only occasional use that provides only a small
>>> benefit, *and* ends up destroying a much more important tool: compile-time
>>> checking on a class's members.
>> Wouldn't the compile time checking remain the same on any class except
>> the Variant (or whatever) which implements the new operator?
>>
>> If it is constrained to one type, the destruction seems like it would be
>> acceptable. You can't trust much on a Variant at compile time anyway.
>>
> 
> The problem is there would be no way to tell at a glance whether a given class uses opDotExp or not. You'd have to go look it up for every class. So, ok, we could solve that by requiring a different syntax for dynamic invokation. But we already have that: just pass a string to a dispatch function. 
> 
> 

Then why overloadable operators? Just write a function call and call it a day. Also, while we're at it, let's prefix all function calls with the word "call" so it's clear that a call is going on. (Some language did that after all.)

The fact of the matter is you're in this discussion only to reaffirm a preconceived opinion. Instead of reiterating your arguments, it might be of great use to listen to those made by others.


Andrei
April 17, 2009
"Leandro Lucarella" <llucax@gmail.com> wrote in message news:20090417191634.GA15139@homero.springfield.home...
> Steven Schveighoffer, el 17 de abril a las 11:27 me escribiste:
>>
>> Sure, but what is the reason to need dynamic methods?  I'm just trying to understand the usefulness of it.
>
> RPC is an example that comes into mind
>
> There is plenty of magic you can do with dynamic methods. Just try a dynamic language and see =)
>

But is there any that can't be done with a dispatch function?

Besides, as I see it, the opDotExp-style syntax for calling a dynamic method is more limited because unless you're using a scripting language, you can't do:

auto foo = new Foo();
char[] func = /* Get from user input */;
foo.func(); // Call function the user specified

But you can do that with either a dispatch method or a reflection API that supports invokation.