Talk:Covariance-aware assertions - Revision history

Juliant at 16:38, 23 April 2007

2007-04-23T16:38:54Z

Juliant at 15:28, 23 April 2007

2007-04-23T15:28:42Z

Peter gummer at 09:46, 23 April 2007

2007-04-23T09:46:19Z

Ericb at 07:17, 23 April 2007

2007-04-23T07:17:53Z

New page

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

← Older revision		Revision as of 16:38, 23 April 2007
Line 27:		Line 27:

	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 <e>is</e> keyword, just when we thought we'd seen the end of it, makes a small come-back; <e>inherit</e> might be ok instead, to be parsimonious with keywords, although it would be less legible and concise.		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 <e>is</e> keyword, just when we thought we'd seen the end of it, makes a small come-back; <e>inherit</e> might be ok instead, to be parsimonious with keywords, although it would be less legible and concise.
		+
		+	:--[[User:Juliant\|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
		+	<e>
		+	-- 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
		+	</e>
		+	:This should make it clear that an assignment to y takes place. The problem here is that the variable <e>y</e> has no type declaration, and repeating the type would be cumbersome. You could require to declare <e>y</e> as a local variable, but this would not work in the precondition for example...

← Older revision		Revision as of 15:28, 23 April 2007
Line 1:		Line 1:
	--[[User:Ericb\|Ericb]] 09:17, 23 April 2007 (CEST): I raised this issue at the last ECMA meeting. I suggested using <eiffel>implies</eiffel> instead of <eiffel>and then</eiffel>. But no decision was made.		--[[User:Ericb\|Ericb]] 09:17, 23 April 2007 (CEST): I raised this issue at the last ECMA meeting. I suggested using <eiffel>implies</eiffel> instead of <eiffel>and then</eiffel>. But no decision was made.
		+
		+	:--[[User:Juliant\|Juliant]] 17:28, 23 April 2007 (CEST)
		+	:Thanks for the hint Eric, I added <e>implies</e> to the solution for the second problem.
		+
		+	:But it will still not solve the first example where a <e>Void</e> argument is allowed by the feature, but the object test on a <e>Void</e> argument will always fail. By changing to <e>implies</e> the assertions will still not be evaluated on a <e>Void</e> 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 <e>Void</e> argument.
		+

	--[[User:Peter gummer\|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.		--[[User:Peter gummer\|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.

← Older revision		Revision as of 09:46, 23 April 2007
Line 1:		Line 1:
	--[[User:Ericb\|Ericb]] 09:17, 23 April 2007 (CEST): I raised this issue at the last ECMA meeting. I suggested using <eiffel>implies</eiffel> instead of <eiffel>and then</eiffel>. But no decision was made.		--[[User:Ericb\|Ericb]] 09:17, 23 April 2007 (CEST): I raised this issue at the last ECMA meeting. I suggested using <eiffel>implies</eiffel> instead of <eiffel>and then</eiffel>. But no decision was made.
		+
		+	--[[User:Peter gummer\|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.
		+
		+	<e>
		+	({y: STRING} x) and then (True)
		+	</e>
		+
		+	In order to comprehend this, I have to translate it into something like, "<e>x</e> is a <e>STRING</e> and then <e>True</e>." I would be much more comfortable if Eiffel's object test looked like this:
		+
		+	<e>
		+	x is {STRING} and then True
		+	</e>
		+
		+	Note that I haven't declared the <e>y</e> 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:
		+
		+	<e>
		+	if x is {y: STRING} then
		+	-- Do something with y
		+	</e>
		+
		+	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 <e>is</e> keyword, just when we thought we'd seen the end of it, makes a small come-back; <e>inherit</e> might be ok instead, to be parsimonious with keywords, although it would be less legible and concise.