Talk:Covariance-aware assertions

--Ericb 09:17, 23 April 2007 (CEST): I raised this issue at the last ECMA meeting. I suggested using implies instead of and then. But no decision was made.

--Juliant 17:28, 23 April 2007 (CEST)

Thanks for the hint Eric, I added implies to the solution for the second problem.

But it will still not solve the first example where a Void argument is allowed by the feature, but the object test on a Void argument will always fail. By changing to implies the assertions will still not be evaluated on a Void argument although they should. But as I wrote in the article, in case of a detached argument type, a void test has to be made together with the object test to check assertions on a Void argument.

--Peter gummer 11:46, 23 April 2007 (CEST) This is a digression (sorry), but reading this article I'm left with the feeling that ECMA's object test syntax runs contrary to Eiffel's aim of being legible to non-propeller-heads. I may not be be the archetypal propeller-head, but I found the object test syntax impeded my comprehension of the article.

({y: STRING} x) and then (True)

In order to comprehend this, I have to translate it into something like, "x is a STRING and then True." I would be much more comfortable if Eiffel's object test looked like this:

x is {STRING} and then True

Note that I haven't declared the y variable, because the variable is unused in the assertion. There is an example later in the article, however, where the full object test syntax would be needed:

if x is {y: STRING} then
        -- Do something with y

My proposed syntax is more readable at the cost of being a bit more verbose; but because the variable declaration is optional, sometimes it's just as concise. The is keyword, just when we thought we'd seen the end of it, makes a small come-back; inherit might be ok instead, to be parsimonious with keywords, although it would be less legible and concise.

--Juliant 18:38, 23 April 2007 (CEST)

I have to agree that the syntax does not look like other Eiffel constructs, and it is not really intuitive the first time around. I like yours much better, but I am still lacking the notion of assigning of the value to y. To make it more clear we could have something along the lines of

-- without assignment
x is {STRING}
-- assignment to y
x is {STRING} assign y
-- in an if-then-clause
if x is {STRING} assign y then
  -- use y
end

This should make it clear that an assignment to y takes place. The problem here is that the variable y has no type declaration, and repeating the type would be cumbersome. You could require to declare y as a local variable, but this would not work in the precondition for example...