Nice TWiki > Doc > NiceSwing > AbstractInterfacesPackagingProblem (r1.2) TWiki webs:
Dev | Doc | Main | TWiki | Sandbox
Doc . { Changes | Index | Search | Go }
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

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

Topic AbstractInterfacesPackagingProblem . { Edit | Attach | Ref-By | Printable | Diffs | r1.3 | > | r1.2 | > | r1.1 | More }
Revision r1.2 - 24 Apr 2003 - 23:14 GMT - ArjanB
Parents: WebHome > NiceSwing 		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.