http://d.puremagic.com/issues/show_bug.cgi?id=6857



--- Comment #42 from Stewart Gordon <smjg@iname.com> 2012-05-04 15:27:45 PDT ---
(In reply to comment #41)
> Example #1 expects behavior based on the static type, which is not polymorphic OOP at all.

True, but it is what this enhancement request is all about.

-- 
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
------- You are receiving this mail because: -------

http://d.puremagic.com/issues/show_bug.cgi?id=6857



--- Comment #43 from Walter Bright <bugzilla@digitalmars.com> 2012-05-04 17:40:19 PDT ---
(In reply to comment #42)
> True, but it is what this enhancement request is all about.

Breaking correct OOP behavior is not an enhancement. It will not break existing wrong-but-just-happens-to-work programs, it will break *correct* programs.

-- 
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
------- You are receiving this mail because: -------

http://d.puremagic.com/issues/show_bug.cgi?id=6857



--- Comment #44 from Stewart Gordon <smjg@iname.com> 2012-05-04 17:50:19 PDT ---
(In reply to comment #43)
> (In reply to comment #42)
>> True, but it is what this enhancement request is all about.
> 
> Breaking correct OOP behavior is not an enhancement.

But going by comment 26, there is no breakage of correct OOP behaviour involved.  So how is this relevant?

-- 
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
------- You are receiving this mail because: -------

http://d.puremagic.com/issues/show_bug.cgi?id=6857



--- Comment #45 from Walter Bright <bugzilla@digitalmars.com> 2012-05-04 18:18:11 PDT ---
(In reply to comment #44)
> But going by comment 26, there is no breakage of correct OOP behaviour involved.  So how is this relevant?

This has already been covered. We're going in circles.

-- 
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
------- You are receiving this mail because: -------

http://d.puremagic.com/issues/show_bug.cgi?id=6857



--- Comment #46 from Don <clugdbug@yahoo.com.au> 2012-05-04 22:58:38 PDT ---
(In reply to comment #45)
> (In reply to comment #44)
> > But going by comment 26, there is no breakage of correct OOP behaviour involved.  So how is this relevant?
> 
> This has already been covered. We're going in circles.

Walter, you haven't understood this at all. None of us have claimed that the
program ever gets into a wrong state. Let me try another way.
Given a module which consists of:
----------
struct F {
   void foo(int n) in { assert( n > 0); } body {}
}

void xyzzy(F f)
{
    f.foo(-1);
}
----------
A theorem prover, or even a compiler that did basic range checking for preconditions, should raise an error at compile time. Not at run time when it's actually called with an F, but at compile time. Nothing controversial there.

Now, change F from a struct to a class. We believe that the code should still fail to compile.

-- 
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
------- You are receiving this mail because: -------

On Saturday, 5 May 2012 at 05:57:31 UTC, Don wrote:
> http://d.puremagic.com/issues/show_bug.cgi?id=6857
>
>
>
> --- Comment #46 from Don <clugdbug@yahoo.com.au> 2012-05-04 22:58:38 PDT ---
> (In reply to comment #45)
>> (In reply to comment #44)
>> > But going by comment 26, there is no breakage of correct OOP behaviour
>> > involved.  So how is this relevant?
>> 
>> This has already been covered. We're going in circles.
>
> Walter, you haven't understood this at all. None of us have claimed that the
> program ever gets into a wrong state.
> Let me try another way.
> Given a module which consists of:
> ----------
> struct F {
>    void foo(int n) in { assert( n > 0); } body {}
> }
>
> void xyzzy(F f)
> {
>     f.foo(-1);
> }
> ----------
> A theorem prover, or even a compiler that did basic range checking for
> preconditions, should raise an error at compile time. Not at run time when it's
> actually called with an F, but at compile time. Nothing controversial there.
>
> Now, change F from a struct to a class. We believe that the code should still
> fail to compile.

Why would one expect the same behavior after changing the struct to a class? The call to foo in the case of struct is statically bound. f.foo *cannot* be bound to any other function than the one declared in F, so it is *always* safe for compiler/theorem prover to statically check the precondition.

Classes are a different story because of dynamic binding. There will be cases where compiler/theorem prover will be able to determine the static type at compile time and detect the error early. Otherwise, it is obvious that the precondition must be checked on the dynamic type at run-time.

http://d.puremagic.com/issues/show_bug.cgi?id=6857



--- Comment #47 from Walter Bright <bugzilla@digitalmars.com> 2012-05-05 02:02:48 PDT ---
(In reply to comment #46)
> Now, change F from a struct to a class. We believe that the code should still fail to compile.

A theorem prover could not produce a compile time error, because it could not prove that f is actually an F, and not of a class derived from F.

OOP is runtime polymorphism, not compile time. A struct type is fundamentally different from a class type.

And lastly, your request is quite different from Example #1, which is asserting
that the contract for A.foo() must always pass, even if it's calling B.foo().

I know I sound like a broken record, but please read Meyer's book. He shows how the behavior of contracts is a derived consequence from OOP principles. It is not a separate invention with separate rules. Hence it is not a matter of belief - it is a matter of proof.

--- Comment #48 from Walter Bright <bugzilla@digitalmars.com> 2012-05-05 02:03:05 PDT ---
(In reply to comment #46)
> Now, change F from a struct to a class. We believe that the code should still fail to compile.

A theorem prover could not produce a compile time error, because it could not prove that f is actually an F, and not of a class derived from F.

OOP is runtime polymorphism, not compile time. A struct type is fundamentally different from a class type.

And lastly, your request is quite different from Example #1, which is asserting
that the contract for A.foo() must always pass, even if it's calling B.foo().

I know I sound like a broken record, but please read Meyer's book. He shows how the behavior of contracts is a derived consequence from OOP principles. It is not a separate invention with separate rules. Hence it is not a matter of belief - it is a matter of proof.

-- 
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
------- You are receiving this mail because: -------

http://d.puremagic.com/issues/show_bug.cgi?id=6857



--- Comment #47 from Walter Bright <bugzilla@digitalmars.com> 2012-05-05 02:02:48 PDT ---
(In reply to comment #46)
> Now, change F from a struct to a class. We believe that the code should still fail to compile.

A theorem prover could not produce a compile time error, because it could not prove that f is actually an F, and not of a class derived from F.

OOP is runtime polymorphism, not compile time. A struct type is fundamentally different from a class type.

And lastly, your request is quite different from Example #1, which is asserting
that the contract for A.foo() must always pass, even if it's calling B.foo().

I know I sound like a broken record, but please read Meyer's book. He shows how the behavior of contracts is a derived consequence from OOP principles. It is not a separate invention with separate rules. Hence it is not a matter of belief - it is a matter of proof.

--- Comment #48 from Walter Bright <bugzilla@digitalmars.com> 2012-05-05 02:03:05 PDT ---
(In reply to comment #46)
> Now, change F from a struct to a class. We believe that the code should still fail to compile.

A theorem prover could not produce a compile time error, because it could not prove that f is actually an F, and not of a class derived from F.

OOP is runtime polymorphism, not compile time. A struct type is fundamentally different from a class type.

And lastly, your request is quite different from Example #1, which is asserting
that the contract for A.foo() must always pass, even if it's calling B.foo().

I know I sound like a broken record, but please read Meyer's book. He shows how the behavior of contracts is a derived consequence from OOP principles. It is not a separate invention with separate rules. Hence it is not a matter of belief - it is a matter of proof.

-- 
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
------- You are receiving this mail because: -------

Please reply on bugzilla, replying here is most likely to be overlooked.

http://d.puremagic.com/issues/show_bug.cgi?id=6857



--- Comment #49 from Stewart Gordon <smjg@iname.com> 2012-05-05 04:40:48 PDT ---
(In reply to comment #47)
> (In reply to comment #46)
> > Now, change F from a struct to a class. We believe that the code should still fail to compile.
> 
> A theorem prover could not produce a compile time error, because it could not prove that f is actually an F, and not of a class derived from F.

You have completely ignored the whole point of this request, which has been explained to you by four of us several times over.

> OOP is runtime polymorphism, not compile time. A struct type is fundamentally different from a class type.

Runtime polymorphism is about overriding behaviour, not overriding legality.

> And lastly, your request is quite different from Example #1, which is asserting
> that the contract for A.foo() must always pass, even if it's calling B.foo().

What are you talking about?

-- 
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
------- You are receiving this mail because: -------