Nice TWiki > Doc > AbstractInterfacesPackagingProblem (r1.1 vs. r1.3) TWiki webs:
Dev | Doc | Main | TWiki | Sandbox
Doc . { Changes | Index | Search | Go }
 <<O>>  Difference Topic AbstractInterfacesPackagingProblem (r1.3 - 30 Apr 2003 - DanielBonniot)
Added:
>
>

In my research article on kinds (and my dissertation), I have proved sufficient conditions for abstract interfaces to be sound. They are hard to explain, so I was looking for a simpler condition that implied the real one. I made a mistake in thinking that the locality restriction was a good candidate. But as Martin said, it is restrictive, and as Arjan shows it is not even safe! When I get the time, I will get back on this, implement a safe condition, and hopefully it will not be restrictive in practice.

-- DanielBonniot - 30 Apr 2003


 <<O>>  Difference Topic AbstractInterfacesPackagingProblem (r1.2 - 24 Apr 2003 - ArjanB)
Added:
>
>

Currently it's not allowed to extend a AI from another package. But that's annoying restriction and worse it doesn't solve the problem because you can bypass it.

package b;
abstract interface foo2 extends a.foo {} // BYPASS
class javax.swing.JComponent implements foo2;

void main(String[] args)
{
  JComponent jc = f(new JTable()); // BOUM!
}

Can restricting some kinds of polymorpic return types of AI methods be a solution to this problem ???

-- ArjanB - 24 Apr 2003


 <<O>>  Difference Topic AbstractInterfacesPackagingProblem (r1.1 - 24 Apr 2003 - ArjanB)
Added:
>
>

%META:TOPICINFO{author="ArjanB" date="1051224074" format="1.0" version="1.1"}% %META:TOPICPARENT{name="NiceSwing"}% The problem of non-local AI is a very complex one, so you cannot expect it to be modified soon. We have to tackle with it. Here is a justification that I cannot allow non-local AI implementation:

package a;
abstract interface foo { alike f(); }
class java.awt.Component implements foo;

f(x) = x;
f(x#javax.swing.JComponent) = new java.awt.Button();

package b;
class javax.swing.JComponent implements a.foo; // ILLEGAL

void main(String[] args)
{
  JComponent jc = f(new JTable()); // BOUM!
}
If I allowed the line marked illegal, then the boum line would be well-typed. But at runtime, it would try to store a java.awt.Button in a JComponent, which would throw a ClassCastException?. This issue is complex, and it can endanger Nice's type safety, which is not acceptable.

Imported from email dicussion with DanielBonniot

-- MartinGamsjaeger? - 30 Oct 2002


Topic AbstractInterfacesPackagingProblem . { View | Diffs | r1.3 | > | r1.2 | > | r1.1 | More }
Revision r1.1 - 24 Apr 2003 - 22:41 GMT - ArjanB
Revision r1.3 - 30 Apr 2003 - 21:48 GMT - DanielBonniot
Copyright © 1999-2003 by the contributing authors. All material on this collaboration platform is the property of the contributing authors.
Ideas, requests, problems regarding TWiki? Send feedback.