Steven Schveighoffer wrote:
On Fri, 17 Apr 2009 15:55:43 -0400, Andrei Alexandrescu
<seewebsiteforem...@erdani.org> wrote:
Nick Sabalausky wrote:
"Yigal Chripun" <yigal...@gmail.com> wrote in message
news:gsam1p$1ut...@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
