On Sunday, 23 February 2014 at 01:37:08 UTC, Steven Schveighoffer
wrote:
> On Sat, 22 Feb 2014 15:17:37 -0500, Frustrated <c1514843@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.

On Saturday, 22 February 2014 at 20:17:37 UTC, Frustrated wrote:
> 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;
>
> }

Why does your WindowsGui violate the iGui contract?

On Sunday, 23 February 2014 at 20:41:30 UTC, Jesse Phillips wrote:
> On Saturday, 22 February 2014 at 20:17:37 UTC, Frustrated wrote:
>> 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;
>>
>> }
>
> Why does your WindowsGui violate the iGui contract?

It doesn't. It simply that one can't specify dependencies in D

if (iGui is WindowsGui) then iButton is WindowsButton;

It's not very hard logic but people are not even trying.

I am attempting to make a mixin to solve the problem. The mixin
will simply overload all methods in the derived class(WindowsGui)
and when WindowsButton is used it will create an overload using
iButton(to satisfy the interface) with the check to make sure the
iButton is a WindowsButton.

It will give me what I want except I have to create the mixin and
then insert it in all the classes. (In theory though it should
not add any overhead is used where it is not suppose to)

But unfortunately when I try to find all members that use
WindowsButton(or whatever) to be able to create the new overload,
I get error due to the inner foreach.

		foreach (am; __traits(derivedMembers, B))
			foreach (m; [__traits(getOverloads, B, am)])
			{
                             // check if method contains an
parameter of type WindowsButton, then create identical method
definition that uses iButton instead. Put a check in the method
and call this method using a cast. This essentially overrides the
virtual method satisfying the interface but passes the work to
the user defined method.
			}

What the above code will do, when working, is create the verbose
code you quoted from the first case:

@property WindowsButton button(WindowsButton b)
{
}

The ***mixin*** turns **ADDS** this

@property WindowsButton button(iButton _b)
{
    if (is(_b : WindowsButton)) assert(0, "Rogue button used");
    auto b = cast(WindowsButton)_b;
    button(b); // Call the user defined function here(hopefully)
}

On Sunday, 23 February 2014 at 21:06:03 UTC, Frustrated wrote:
>> Why does your WindowsGui violate the iGui contract?
>
> It doesn't. It simply that one can't specify dependencies in D
>
> if (iGui is WindowsGui) then iButton is WindowsButton;
>
> It's not very hard logic but people are not even trying.

I understand what you intend your code to do, but that is still breaking the contract which you setup. iGui takes an iButton because you defined it that way, to only handle specific types of iButton is a breach of contract. The language lets you break contracts, but it should not help you do so.

On Sunday, 23 February 2014 at 23:14:24 UTC, Jesse Phillips wrote:
> On Sunday, 23 February 2014 at 21:06:03 UTC, Frustrated wrote:
>>> Why does your WindowsGui violate the iGui contract?
>>
>> It doesn't. It simply that one can't specify dependencies in D
>>
>> if (iGui is WindowsGui) then iButton is WindowsButton;
>>
>> It's not very hard logic but people are not even trying.
>
> I understand what you intend your code to do, but that is still breaking the contract which you setup. iGui takes an iButton because you defined it that way, to only handle specific types of iButton is a breach of contract. The language lets you break contracts, but it should not help you do so.

Nope. It has nothing to do with the contract. You are totally
missing the point.

It is all about reducing typing a bunch of extra shit. Don't know
why you can't see that.

In any case once I get the mixin in finish it will do what I want
and be good enough.

IF the damn language had the ability to specify dependencies then
it wouldn't be a problem. Just because you insist on using D's
current model as the only model you will always be right... I
hope that makes you happy. In the mean time I'll be moving on to
writing cleaner code...

On Sunday, 23 February 2014 at 23:23:07 UTC, Frustrated wrote:
> Nope. It has nothing to do with the contract. You are totally
> missing the point.

iGui has a function which takes any iButton. That is a defined contract of iGui, your denial does not change that.

On Monday, 24 February 2014 at 00:09:55 UTC, Jesse Phillips wrote:
> On Sunday, 23 February 2014 at 23:23:07 UTC, Frustrated wrote:
>> Nope. It has nothing to do with the contract. You are totally
>> missing the point.
>
> iGui has a function which takes any iButton. That is a defined contract of iGui, your denial does not change that.

Let me put this another way. I started with the question of why you need to break the contract you define. In other words, "What is the problem you are trying to solve." But instead you insisted the "it must be solved this way" instead of giving details on what the problem actually is.

D already provides a way to say that WindowsGui only takes WindowsButtons, you did so in your original code, just don't extend iGui since that isn't the contract you fulfill.

On Sun, 23 Feb 2014 08:26:10 -0500, Frustrated <c1514843@drdrb.com> wrote:

> 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).

You have a nasty habit of assuming people do not know as much as you.

Bottom line, I get what you are asking, always have. It could be done, but D won't do it for you, nor will it be modified to do that. The costs of additional runtime type checks are far too great to implicitly add them. Use mixin generation, and be done with it.

-Steve