On Sunday, 23 February 2014 at 01:37:08 UTC, Steven Schveighoffer
wrote:
On Sat, 22 Feb 2014 15:17:37 -0500, Frustrated
<c1514...@drdrb.com> wrote:
It is legal exactly because I will always guarantee that the
proper button will be used.
Static typing says it's not legal. D does not do dynamic type
checking upon calling virtual functions.
It is not logically legal as mentioned several times... no one
needs to mention that. But it is legal within the context of
the
code. I'll never use a RogueButton so why force me to code for
the chance I might?
You may not be the only one using WindowsGui. You can't
guarantee other code won't do it. In any case, the compiler
cannot possibly know your intentions.
Basically, the point is, the compiler could enforce the above
but
make the code more readable.
e.g.,
I do this:
@property WindowsButton button(WindowsButton b)
{
}
The compiler turns this into
@property WindowsButton button(iButton _b)
{
if (is(_b : WindowsButton)) assert(0, "Rogue button used");
auto b = cast(WindowsButton)_b;
}
This solution is not as efficient as the one I outlined. If you
have a WindowsGui object, no need to accept iButton when you
require WindowsButton.
One allows me to program in a natural way while the other makes
me jump through hoops which litters the code with a bunch of
casts and checks which are only there in the odd event that I
assign the wrong type(which, I'm not going to do on purpose).
Sorry, if you want a dynamically typed language, use one. D is
not that.
Again, the whole point of why it is illegal because you can
pass
a RogueButton... BUT I DON'T INTEND TO PASS THEM! If I could
absolutely guarantee that I won't pass them then there should
be
no problem(no asserts). Since I can't guarantee it I have to
litter my code with checks? The compiler could do this for me.
You can't guarantee it. That is the point. The compiler could
do the checks for you, but D is not dynamically typed. The best
you can do is encapsulate the type checking code as a mixin.
-Steve
It has nothing to do with being dynamically typed. We can't solve
this problem until you get your head out of the gutter(the gutter
being how D does things already. Can't make progress on something
if you ever look beyond what it can do).
This has to do with simply adding checks to enforce the type. I
can guarantee it, but like you said, I can't guarantee what
others do. Hence the check.
The fact is, I presented two versions of the code. One represents
the other. It is a representational problem, nothing more,
nothing less. Please understand that from now on.
e.g., a switch statement is just a representational form of if
statements to simplify. I'll I'm talking about is adding a switch
statement. (if you take that literal and can't see how it relates
to the original problem then you are completely missing the point
of the whole discussion)
I did think it might be possible to use CT reflection to generate
all the type checking automatically but this might be difficult
and would have to generate a new class. It seems like the only
way to get at this problem in D.
