Skip to content

Super-contract broken when overriding empty-paren method with field #3144

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Closed
scabug opened this issue Mar 4, 2010 · 5 comments
Closed

Super-contract broken when overriding empty-paren method with field #3144

scabug opened this issue Mar 4, 2010 · 5 comments

Comments

@scabug
Copy link

scabug commented Mar 4, 2010

Tested against:
Scala Eclipse plug-in nightly of 2010-03-03
Version: 2.8.0.r21030-b20100302035619

This is a redefinition of ticket #3138.

/*
 * Bug: Super-contract broken when overriding empty-paren method with field. 
 *
 * Tested against:
 * Scala Eclipse plug-in nightly of 2010-03-03
 * Version: 2.8.0.r21030-b20100302035619
 * 
 * This is a (rather innocent) flaw in type-safety.
 *
 */

// an abstract class with an empty-paren method
abstract class C { 
	def a(): Unit
}

// an implementation class for C
class D extends C {
	val a = ()	// implement an empty-paren method with a val.
}

// some 'client' code
object BugValOverridesEmptyParen2 extends Application {
	
	val d = new D
	
	require (d.isInstanceOf[C]) // passes, as expected 
	
	d.a()		//  -> compile error ("c does not take parameters"), 
				//     The contract of supertype C of d is obviously broken!!

	// This breaks the substitutability principle (and therefore type-safety.)
	// It also breaks the "uniform access principle, which says that 
	// client code should not be affected by a decision
	// to implement an attribute as a field or method." (1) ;-)

	// I've noticed this in Scala 2.7.7 as well.
	
	// BTW: If we upcast d to C, we *can* access the overridden method 
	// (So that can function as a work-around).
	(d: C).a()	// no error!

/*
 * My proposal is to extend the language to allow the empty-parens syntax for a member 
 * for which its type lineairization defines its name with empty-parens.
 * So d.a() would compile in te example above. 
 * This seems a clean, simple and correct solution to such cases.	
*/	
	
/* Related literature:
 * 
 * (1) Programming in Scala v6, Odersky et al. page 212
 * 
 * ()  The Scala Language Specification, page 54, par. 5.1.4 ?
 * (However, I couldn't find the case of fields overriding methods there..:-/)  
 */
}
@scabug
Copy link
Author

scabug commented Mar 4, 2010

Imported From: https://issues.scala-lang.org/browse/SI-3144?orig=1
Reporter: me (scalll)
Attachments:

@scabug
Copy link
Author

scabug commented Mar 4, 2010

me (scalll) said:
Correction:[[BR]]
"My proposal is to extend the language to allow the empty-parens syntax for a field
in a value-expression, if the name of the field is declared with empty-parens in its enclosing type lineairization.[[BR]]
So d.a() would compile in the example above.[[BR]]
This seems a clean, simple and correct solution to such cases.[[BR]]
This construct would be analogue to parameterless methods being invoked using empty-parens syntax."

@scabug
Copy link
Author

scabug commented Mar 4, 2010

me (scalll) said:
Source to reproduce

@scabug
Copy link
Author

scabug commented Mar 9, 2010

@axel22 said:
Implementation of these features is already dangerously messy, due to interoperability with Java. For this reason, we've decided not to fix this.

Thanks.

@scabug
Copy link
Author

scabug commented Mar 10, 2010

@harrah said:
The reporter's statement about the specification not covering vals/vars overriding methods seems valid. Perhaps it is not urgent for 2.8, but reopen for a post-2.8 fix?

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

1 participant