Nice TWiki > Dev > NiceCasts (r1.1 vs. r1.24) TWiki webs:
Dev | Doc | Main | TWiki | Sandbox
Dev . { Changes | Index | Search | Go }
 <<O>>  Difference Topic NiceCasts (r1.24 - 06 Jun 2003 - AlexGreif)
Deleted:
<
<

Daniel asked me to make this list in order to optimize the compiler.

OK, I'll try to clean up the cases where we have advanced, so that this page does not become incomprehensible. Please check you agree with the changes.

Alex, could you clean up the cases that were solved by Nice 0.7.9? We will see better what is left. -- Daniel

Deleted:
<
<


 <<O>>  Difference Topic NiceCasts (r1.23 - 06 Jun 2003 - AlexGreif)
Deleted:
<
<

      Rectangle rect = this.getHandlesBoundsRect();
      int width = cast(rect.getWidth());
      int height = cast(rect.getHeight());
getters return double

You should use:

      Rectangle rect = this.getHandlesBoundsRect();
      int width = int(rect.getWidth());
      int height = int(rect.getHeight());

int(...) in Nice is equivalent to (int) ... in Java. See http://nice.sourceforge.net/manual.html#conversion


Deleted:
<
<

public class ConnectionHandle? extends Handle implements ConnectorListener? { ... }

java.util.List connectionHandles = this.getHandles().filter(asConnectionHandle); ConnectionHandle? connectionHandle = connectionHandles.get(connectionHandleIndex); ?java.util.List connectorListeners = conn.getConnectorListeners(); if (connectorListeners != null && notNull(connectorListeners).contains(connectionHandle)) {...}

   [nicec] src/nice/flow4j/designer/figure/Connection.nice: line 211, column 80:
    [nicec] No possible call for contains.
    [nicec] Arguments: (?java.util.List<flow4j.designer.figure.ConnectorListener>, <t1691, U' | U' < nice.lang.Maybe> U'<t1691>)
    [nicec] Possibilities:
    [nicec] nice.lang.boolean contains(java.nio.charset.Charset, ?java.nio.charset.Charset)
    [nicec] nice.lang.boolean contains(flow4j.designer.figure.Handle this, Point)
    [nicec] nice.lang.boolean contains(flow4j.designer.figure.Figure this, Point)
    [nicec] nice.lang.boolean contains(flow4j.designer.figure.Connector this, Point)
    [nicec] nice.lang.boolean contains(java.awt.Component, ?java.awt.Point)
    [nicec] nice.lang.boolean contains(javax.accessibility.AccessibleRelationSet, ?java.lang.String)
    [nicec] nice.lang.boolean contains(javax.accessibility.AccessibleStateSet, ?javax.accessibility.AccessibleState)
    [nicec] nice.lang.boolean contains(javax.accessibility.AccessibleComponent, ?java.awt.Point)
    [nicec] nice.lang.boolean contains(java.awt.Polygon, ?java.awt.Point)
    [nicec] nice.lang.boolean contains(java.awt.Rectangle, ?java.awt.Rectangle)
    [nicec] nice.lang.boolean contains(java.awt.Rectangle, ?java.awt.Point)
    [nicec] nice.lang.boolean contains(java.awt.Shape, ?java.awt.geom.Point2D)
    [nicec] nice.lang.boolean contains(java.awt.Shape, ?java.awt.geom.Rectangle2D)
    [nicec] <Any K, Any V> nice.lang.boolean contains(java.util.Hashtable<K, V>, V)
    [nicec] <Any E> nice.lang.boolean contains(java.util.Collection<E>, E)
<verbatim>
<nop>

 <<O>>  Difference Topic NiceCasts (r1.22 - 06 Jun 2003 - AlexGreif)
Deleted:
<
<


      JOptionPane.showMessageDialog(flowWindow,
         object("Errors in flow...."),
         "Error",
         JOptionPane.ERROR_MESSAGE);
flowWindow extends JInternalFrame

The second argument is supposed to be an Object in Java. Nice does not make value automatically subtypes of Object. You can use the object(...) function instead of cast(...) to do that.

For this kind of issue, I think the best is to use retyping. After checking the javadoc, one can see that the second argument can really be of any class. So we can declare:

< void showMessageDialog(Component parentComponent, T message, String title, int messageType)
  = native void JOptionPane.showMessageDialog(Component, Object, String, int);
After that, you should be able to call the method without cast not object(...).

Are you aware of the NiceSwing project? This was done by Martin. It contains many retypings for java.awt, java.beans and javax.swing. It also has utility methods and classes, to do GUI stuff more easily, using Nice features like anonymous functions. At the moment, I think it is only available as a CVS module, but jars should be made at some point (a problem is that Martin is very busy at the moment). I just added some retypings for JOptionPane.

It would be interesting to see how that can help writing the GUI for flow4j. Also, related to the Eclipse plugin, a similar library could be done on top of SWT. -- DanielBonniot


 <<O>>  Difference Topic NiceCasts (r1.21 - 04 Jun 2003 - ArjanB)
Added:
>
>

Which problems are not solved yet in 0.8? -- ArjanB


 <<O>>  Difference Topic NiceCasts (r1.20 - 25 Apr 2003 - DanielBonniot)
Changed:
<
<

OK, I'll try to clean up the cases where we have advanced, so that this page does not become incomprehensible. Please check you agree with the changes. -- Daniel

>
>

OK, I'll try to clean up the cases where we have advanced, so that this page does not become incomprehensible. Please check you agree with the changes.

Alex, could you clean up the cases that were solved by Nice 0.7.9? We will see better what is left. -- Daniel

Changed:
<
<

Are you aware of the NiceSwing? project? This was done by Martin. It contains many retypings for java.awt, java.beans and javax.swing. It also has utility methods and classes, to do GUI stuff more easily, using Nice features like anonymous functions. At the moment, I think it is only available as a CVS module, but jars should be made at some point (a problem is that Martin is very busy at the moment). I just added some retypings for JOptionPane.

>
>

Are you aware of the NiceSwing project? This was done by Martin. It contains many retypings for java.awt, java.beans and javax.swing. It also has utility methods and classes, to do GUI stuff more easily, using Nice features like anonymous functions. At the moment, I think it is only available as a CVS module, but jars should be made at some point (a problem is that Martin is very busy at the moment). I just added some retypings for JOptionPane.

Added:
>
>

Added:
>
>


 <<O>>  Difference Topic NiceCasts (r1.19 - 24 Apr 2003 - DanielBonniot)
Added:
>
>

:-) Seriously, Arjan, you should write something to put in the Statements section. -- Daniel


 <<O>>  Difference Topic NiceCasts (r1.18 - 23 Apr 2003 - ArjanB)
Added:
>
>

I changed the retypings so the cast isn't needed anymore in the next DevelopmentVersion -- Arjan


 <<O>>  Difference Topic NiceCasts (r1.17 - 23 Apr 2003 - DanielBonniot)
Changed:
<
<

For this kind of issue, I think the best is to use retyping. In particular, are you aware of the NiceSwing? project? -- DanielBonniot

>
>

For this kind of issue, I think the best is to use retyping. After checking the javadoc, one can see that the second argument can really be of any class. So we can declare:

< void showMessageDialog(Component parentComponent, T message, String title, int messageType)
  = native void JOptionPane.showMessageDialog(Component, Object, String, int);
After that, you should be able to call the method without cast not object(...).

Are you aware of the NiceSwing? project? This was done by Martin. It contains many retypings for java.awt, java.beans and javax.swing. It also has utility methods and classes, to do GUI stuff more easily, using Nice features like anonymous functions. At the moment, I think it is only available as a CVS module, but jars should be made at some point (a problem is that Martin is very busy at the moment). I just added some retypings for JOptionPane.

It would be interesting to see how that can help writing the GUI for flow4j. Also, related to the Eclipse plugin, a similar library could be done on top of SWT. -- DanielBonniot

Added:
>
>

Are you not sure it is safe, or if it is useful? I checked the javadoc, it is true that you cannot add elements, so this must be safe. I'm not sure how useful it will be, but it does not harm to do it. Maybe it will turn out useful in some situations. And we can say that Nice allows this, while Java 1.5 cannot! :-) -- Daniel


 <<O>>  Difference Topic NiceCasts (r1.16 - 23 Apr 2003 - ArjanB)
Changed:
<
<

<K, K0, V0, V | K0 <: K, V <: ?V0> ?V0 get(java.util.Map, K0) =

>
>

<K, K0, V0, V | K <: K0, V <: ?V0> ?V0 get(java.util.Map, K0) =

Changed:
<
<

This type is equivalent to the current one. I suppose you mean K <: K0 ? Yes, it makes sense. JSR 14 (Java Generics) does use Object for the key in get. So we are still more strict and safe than them.

>
>

Yes, it makes sense. JSR 14 (Java Generics) does use Object for the key in get. So we are still more strict and safe than them.

Changed:
<
<

-- Daniel

>
>

-- Daniel

Ok but I'm not sure about one kind of retypings:

<K, K0, V | K <: K0> java.util.Set<K0> keySet(java.util.Map<K, V>) =
  native java.util.Set java.util.Map.keySet();

this is safe because a keyset is read/remove only. -- Arjan


 <<O>>  Difference Topic NiceCasts (r1.15 - 23 Apr 2003 - DanielBonniot)
Changed:
<
<

For this kind of issue, I think the best is to use retyping. In particular, are you aware of the NiceSwing? project? But I would like to hear that the above fix works first. -- DanielBonniot

>
>

For this kind of issue, I think the best is to use retyping. In particular, are you aware of the NiceSwing? project? -- DanielBonniot

Changed:
<
<

Interesting too. But IMO not very nice design, because the class Figure (the super class of all) has the member List handles. And I want to store all handles in one List. A Connection has this speciality that it has two types of handles. Besides this I can iterate easily if all Handles are in one List. -- AlexGreif

>
>

Interesting too. But IMO not very nice design, because the class Figure (the super class of all) has the member List<Handle> handles. And I want to store all handles in one List. A Connection has this speciality that it has two types of handles. Besides this I can iterate easily if all Handles are in one List. -- AlexGreif

Added:
>
>

The type information is not redundant. A benefit is that you make sure that there is no cast, that might fail at runtime in some strange condition. On the other hand, it is true that you then need to guarantee that the value in the field is the same as in the list. If you have a set method in the parent to build the list, then you could override it to set the fields when the index is 0 or length - 1, and the call super.

I agree that the benefit is discutable. An alternative is to use the cast. In a future version of Nice, I could imagine that you could do:

Hand h = cast(handles.get(handles.size()-1));
assert h instanceof ConnectionHandle;
// Now you can use h as a ConnectionHandle.
Changed:
<
<

Yes but if I'm consistent then should almost all methods of the collection be retyped to get a co\contra-variant type. the methods in Map will get uglier retyping then.

>
>

Yes but if I'm consistent then should almost all methods of the collection be retyped to get a co/contra-variant type. the methods in Map will get uglier retyping then.

Changed:
<
<

?V0 get(java.util.Map, K0)=

>
>

<K, K0, V0, V | K0 <: K, V <: ?V0> ?V0 get(java.util.Map, K0) =

Added:
>
>

This type is equivalent to the current one. I suppose you mean K <: K0 ? Yes, it makes sense. JSR 14 (Java Generics) does use Object for the key in get. So we are still more strict and safe than them.

I don't think it matters too much if the retypings become more complicated, especially if it means they will be usable in more situations. -- Daniel

Changed:
<
<

It's possible, but that's still a case.

>
>

It's possible, but that's still a cast.


 <<O>>  Difference Topic NiceCasts (r1.14 - 23 Apr 2003 - ArjanB)
Changed:
<
<


>
>


Changed:
<
<

here is the selfcontained code to test. take notNull away and the compiler complains.

>
>

Yes but if I'm consistent then should almost all methods of the collection be retyped to get a co\contra-variant type. the methods in Map will get uglier retyping then.

Changed:
<
<

package test; import java.util.*;

public class Connector { ?java.util.List connectorListeners = null;

void deleteFigure(); deleteFigure() { if (connectorListeners == null) return;

for (Iterator iter = notNull(connectorListeners).iterator(); iter.hasNext();) { ConnectorListener? ltnr = iter.next(); } } }

interface ConnectorListener? {}

>
>

?V0 get(java.util.Map, K0)= native Object java.util.Map.get(Object);

Changed:
<
<

-- AlexGreif

That not a bug see http://sourceforge.net/tracker/index.php?func=detail&aid=671444&group_id=12788&atid=362788 You could copy the field to a local variable. -- ArjanB

>
>

It reminds me that I still should write something about retyping, at least the is no shortage of examples -- ArjanB

Added:
>
>

It should be in the manual that you need to look in the changelog. ;-) -- ArjanB


 <<O>>  Difference Topic NiceCasts (r1.13 - 23 Apr 2003 - AlexGreif)
Added:
>
>

Then the info is redundant, and I have to update both. Where do I profit if I introduce two fields? -- Alex


 <<O>>  Difference Topic NiceCasts (r1.12 - 23 Apr 2003 - DanielBonniot)
Added:
>
>

OK, I'll try to clean up the cases where we have advanced, so that this page does not become incomprehensible. Please check you agree with the changes. -- Daniel

Changed:
<
<

JOptionPane?.showMessageDialog(cast(flowWindow), cast("Errors in flow.\nFlow byte code could not be generated.\nFlow will be saved without byte code."), cast("Error"),

>
>

JOptionPane?.showMessageDialog(flowWindow, object("Errors in flow...."), "Error",

Changed:
<
<

Can you say more about the types of the methods used? Ideally, the cases should be self-contained.

The first and third arguments should not need a cast, they are Component and String as expected. The second is supposed to be an Object in Java. Nice does not make value automatically subtypes of Object. You can use the object(...) function instead of cast(...) to do that.

>
>

The second argument is supposed to be an Object in Java. Nice does not make value automatically subtypes of Object. You can use the object(...) function instead of cast(...) to do that.

Deleted:
<
<

when I leave all casts away then the following is reported by the compiler:

   [nicec] Arguments (flow4j.designer.window.flowwindow.FlowWindow, java.lang.String, java.lang.String, nice.lang.int) do not fit: 
    [nicec] nice.lang.void showMessageDialog(?java.awt.Component, ?java.lang.Object, ?java.lang.String, nice.lang.int)
Thats why I had to use the cast -- AlexGreif

This is logical for the second argument, as I said above. Does it work if you use object(...) on the second argument, and no cast? -- DanielBonniot

yes it works :)) -- AlexGreif

Added:
>
>

OK. Then could you add in Connection the two fields, while keeping everything in the list? -- Daniel

Changed:
<
<

if (connectorListeners != null && notNull(connectorListeners).contains(cast(connectionHandle))) {...}

>
>

if (connectorListeners != null && notNull(connectorListeners).contains(connectionHandle)) {...}

Changed:
<
<

If ConnectionHandle implements ConnectorListener?, then the cast should not be necessary either. What is the error message you get without the cast? -- DanielBonniot

you are right without cast, it compiles fine. -- AlexGreif

>
>

With 0.7.8 I dont need the cast but need the notNull. If I leave the notNull off then the above problem is reported.

Changed:
<
<

with 0.7.8 I dont need the cast but need the notNull. If I leave the notNull off then the above problem is reported.

>
>

I'm surprised. You should not need notNull, because you test a local variable here. Can I have a self-contained testcase, please?

Changed:
<
<

Flowlet flowlet = cast(notNull(figure));

>
>

Flowlet flowlet = cast(figure);

Changed:
<
<

At least the notNull should not be necessary, because you tested for null above. Does it work to remove it? -- DanielBonniot

yes it compiles. -- AlexGreif

OK, so just the cast remains. The problem is now like with ConnectionHandle?. Could you modify the design a bit, so that the type of the expression is Flowlet and not Figure?

>
>

The problem is now like with ConnectionHandle?. Could you modify the design a bit, so that the type of the expression is Flowlet and not Figure?

Changed:
<
<

Do you really need notNull? Why? -- DanielBonniot

without I get:

    [nicec] src/nice/flow4j/designer/figure/Connector.nice: line 136, column 76:
    [nicec] Arguments (?java.util.List<flow4j.designer.figure.ConnectorListener>) do not fit: 
    [nicec] <Any T> java.util.Iterator<T> iterator(java.util.Collection<T>)

Is this with 0.7.8? Then it looks like a bug. Could you produce a self-contained version?

>
>

You need notNull, because connectorListeners is not a local variable. This is explained in OptionTypes. A solution is there too.

Added:
>
>

OK! Doesn't removeAll also need to get a contravariant type? -- DanielBonniot

Added:
>
>

I think it's in the changelog only, at the moment. You see, Arjan, documentation is needed! :-) -- DanielBonniot


 <<O>>  Difference Topic NiceCasts (r1.11 - 23 Apr 2003 - ArjanB)
Added:
>
>

Another example to show why contains should be contravariant.

<T,U,V | U <: T, V <: T> Set<T> intersection(Set<U>, Set<V>);

intersection<T,U,V>(s1@Set, s2@Set) {
   Set<T> res = new HashSet();
   if (s1.size() < s2.size()) {
       for(U elem : s1) 
           if (s2.contains(elem)) res.add(elem);
   } else {
       for(V elem : s2) 
           if (s1.contains(elem)) res.add(elem);
   }
   return res;
}
Should I reapply that patch then Daniel? -- ArjanB
Added:
>
>

That not a bug see http://sourceforge.net/tracker/index.php?func=detail&aid=671444&group_id=12788&atid=362788 You could copy the field to a local variable. -- ArjanB


 <<O>>  Difference Topic NiceCasts (r1.10 - 23 Apr 2003 - AlexGreif)
Added:
>
>

I think Arjan is right, I will test it -- AlexGreif

Changed:
<
<

After that, you won't need this cast.

>
>

After that, you won't need this cast. -- DanielBonniot

here is the selfcontained code to test. take notNull away and the compiler complains.

package test;
import java.util.*;

public class Connector {
   ?java.util.List<ConnectorListener> connectorListeners = null;

   void deleteFigure();
   deleteFigure() {
      if (connectorListeners == null)   return;
      
      for (Iterator<ConnectorListener> iter = notNull(connectorListeners).iterator(); iter.hasNext();) {
         ConnectorListener ltnr = iter.next();
      }
   }
}

interface ConnectorListener {}
-- AlexGreif
Changed:
<
<

Is getFromConnection reimplemented for DecisionFlowlet??

>
>

Is getFromConnections reimplemented for DecisionFlowlet? -- DanielBonniot

No. Only implemented in Flowlet class. Thus I have to return a List with the lowest common denom.. --Main.AlexGreif

Added:
>
>

-- DanielBonniot

OOps did I miss that? Is it documented somewhere? -- AlexGreif


 <<O>>  Difference Topic NiceCasts (r1.9 - 23 Apr 2003 - AlexGreif)
Added:
>
>

yes it works :)) -- AlexGreif

Added:
>
>

--Main.DanielBonniot

Interesting too. But IMO not very nice design, because the class Figure (the super class of all) has the member List handles. And I want to store all handles in one List. A Connection has this speciality that it has two types of handles. Besides this I can iterate easily if all Handles are in one List. -- AlexGreif

Changed:
<
<

What a shame I used 0.7.7 :((
Without notNull and 0.7.8 the following error is reported (you mean this is with Nice version 0.7.7?)

>
>

I compile with 0.7.8.
Without notNull the following error is reported

Changed:
<
<

I'm confused. Does everything work fine with Nice 0.7.8? Or dou you still need the cast, but not notNull?

>
>

with 0.7.8 I dont need the cast but need the notNull. If I leave the notNull off then the above problem is reported.

Added:
>
>

No. Figure is the superclass of all drawable Items. Flowlets are items that can be connected together. Connections cannot be connected. Thats why they are Figures.

Here is the class hierarchy:
Figure <- PolygonFigure
PolygonFigure <- Flowlet
PolygonFigure <- Connection
-- AlexGreif


 <<O>>  Difference Topic NiceCasts (r1.8 - 23 Apr 2003 - ArjanB)
Added:
>
>

Isn't this code equivalent to the following -- ArjanB

          if (connectorListeners == null)   return;
      connectorListeners.removeAll(cast(figure.getHandles()));

 <<O>>  Difference Topic NiceCasts (r1.7 - 23 Apr 2003 - DanielBonniot)
Added:
>
>

This is logical for the second argument, as I said above. Does it work if you use object(...) on the second argument, and no cast? -- DanielBonniot

Added:
>
>

Interesting. Here it is the logic of the system that guarantees the cast will not fail. I think you could take into account this logic in the types. One possibility is to keep a reference to the handles on both extremities in fields of type ConnectionHandle. If you wish, you can encapsulate the handles in a Handle class:

class Handles
{
  List<Handle> handles;
  ConnectionHandle first;
  CollectionHandle last;
}
// Some methods to manipulate handles.
Added:
>
>

(you mean this is with Nice version 0.7.7?)

Added:
>
>

I'm confused. Does everything work fine with Nice 0.7.8? Or dou you still need the cast, but not notNull?

Added:
>
>

OK, so just the cast remains. The problem is now like with ConnectionHandle?. Could you modify the design a bit, so that the type of the expression is Flowlet and not Figure?

Added:
>
>

Is this with 0.7.8? Then it looks like a bug. Could you produce a self-contained version?

Added:
>
>

Interesting. So you have a value of type A, a List<B> with B extends A, and you want to know if the value is in the list, right? We were discussing with Arjan if this is ever needed. The point is, it can only be true if the value is of type B. But now I can believe this is really useful.

If it is really this, we will change the type of contains in nice.lang. After that, you won't need this cast.

Added:
>
>

Is getFromConnection reimplemented for DecisionFlowlet??

Added:
>
>

It's possible, but that's still a case.

Note that using get on a List in a loop can be bad, in case the List is a linked list: you will traverse n**2 elements, instead of n. This is ideal for the new for syntax of version 0.7.8:

   getFromConnection(state) {
      java.util.List<DecisionConnection> followings = cast(this.getFromConnections());
      
      for (DecisionConnection connection : followings) {
         if (connection.getState() == state) {
            return connection;
         }
      }
      return null;
   }

 <<O>>  Difference Topic NiceCasts (r1.6 - 23 Apr 2003 - AlexGreif)
Changed:
<
<

At least the notNull should not be necessary, because you tested for null above. Does it work to remove it?

>
>

At least the notNull should not be necessary, because you tested for null above. Does it work to remove it? -- DanielBonniot

yes it compiles. -- AlexGreif

Added:
>
>

if (connectorListeners == null) return;

Changed:
<
<

Do you really need notNull? Why?

>
>

Do you really need notNull? Why? -- DanielBonniot

without I get:

    [nicec] src/nice/flow4j/designer/figure/Connector.nice: line 136, column 76:
    [nicec] Arguments (?java.util.List<flow4j.designer.figure.ConnectorListener>) do not fit: 
    [nicec] <Any T> java.util.Iterator<T> iterator(java.util.Collection<T>)
Added:
>
>

   java.util.List<Handle> getHandles() = handles;

ConnectorHandle, that extends Handle implements ConnectorListener

Changed:
<
<

Why don't you declare that this.getFromConnections() returns a List<DecisionConnection>?

>
>

Why don't you declare that this.getFromConnections() returns a List<DecisionConnection>? -- DanielBonniot

The code above is in DecisionFlowlet, but this.getFromConnections() is declared in Flowlet that returns Connection objects.

Should I use :

      java.util.List<DecisionConnection> followings = cast(this.getFromConnections());
-- AlexGreif

 <<O>>  Difference Topic NiceCasts (r1.5 - 23 Apr 2003 - AlexGreif)
Deleted:
<
<

Changed:
<
<

The notNull should not be necessary, since Nice 0.7.8! :-)

>
>

The notNull should not be necessary, since Nice 0.7.8! :-) -- DanielBonniot

What a shame I used 0.7.7 :((
Without notNull and 0.7.8 the following error is reported

   [nicec] src/nice/flow4j/designer/figure/Connection.nice: line 211, column 80:
    [nicec] No possible call for contains.
    [nicec] Arguments: (?java.util.List<flow4j.designer.figure.ConnectorListener>, <t1691, U' | U' < nice.lang.Maybe> U'<t1691>)
    [nicec] Possibilities:
    [nicec] nice.lang.boolean contains(java.nio.charset.Charset, ?java.nio.charset.Charset)
    [nicec] nice.lang.boolean contains(flow4j.designer.figure.Handle this, Point)
    [nicec] nice.lang.boolean contains(flow4j.designer.figure.Figure this, Point)
    [nicec] nice.lang.boolean contains(flow4j.designer.figure.Connector this, Point)
    [nicec] nice.lang.boolean contains(java.awt.Component, ?java.awt.Point)
    [nicec] nice.lang.boolean contains(javax.accessibility.AccessibleRelationSet, ?java.lang.String)
    [nicec] nice.lang.boolean contains(javax.accessibility.AccessibleStateSet, ?javax.accessibility.AccessibleState)
    [nicec] nice.lang.boolean contains(javax.accessibility.AccessibleComponent, ?java.awt.Point)
    [nicec] nice.lang.boolean contains(java.awt.Polygon, ?java.awt.Point)
    [nicec] nice.lang.boolean contains(java.awt.Rectangle, ?java.awt.Rectangle)
    [nicec] nice.lang.boolean contains(java.awt.Rectangle, ?java.awt.Point)
    [nicec] nice.lang.boolean contains(java.awt.Shape, ?java.awt.geom.Point2D)
    [nicec] nice.lang.boolean contains(java.awt.Shape, ?java.awt.geom.Rectangle2D)
    [nicec] <Any K, Any V> nice.lang.boolean contains(java.util.Hashtable<K, V>, V)
    [nicec] <Any E> nice.lang.boolean contains(java.util.Collection<E>, E)
-- AlexGreif

If ConnectionHandle implements ConnectorListener?, then the cast should not be necessary either. What is the error message you get without the cast? -- DanielBonniot

Changed:
<
<

If ConnectionHandle implements ConnectorListener?, then the cast should not be necessary either. What is the error message you get without the cast?

>
>

you are right without cast, it compiles fine. -- AlexGreif


 <<O>>  Difference Topic NiceCasts (r1.4 - 23 Apr 2003 - AlexGreif)
Added:
>
>


Changed:
<
<

For this kind of issue, I think the best is to use retyping. In particular, are you aware of the NiceSwing? project? But I would like to hear that the above fix works first.

>
>

For this kind of issue, I think the best is to use retyping. In particular, are you aware of the NiceSwing? project? But I would like to hear that the above fix works first. -- DanielBonniot

Added:
>
>

when I leave all casts away then the following is reported by the compiler:

   [nicec] Arguments (flow4j.designer.window.flowwindow.FlowWindow, java.lang.String, java.lang.String, nice.lang.int) do not fit: 
    [nicec] nice.lang.void showMessageDialog(?java.awt.Component, ?java.lang.Object, ?java.lang.String, nice.lang.int)
Thats why I had to use the cast -- AlexGreif
Changed:
<
<

How do you know that the last element has the right type?

>
>

How do you know that the last element has the right type? -- DanielBonniot

The draggable points of a Connection are Handles. The first and the last are connected to flowlets, thats why they are called ConnectionHandles, and the handles in between are EllbowHandles. There can be zero or more EllbowHandles?. I defined it like this. -- AlexGreif


 <<O>>  Difference Topic NiceCasts (r1.3 - 23 Apr 2003 - DanielBonniot)
Changed:
<
<

Here are some examples where I had to use cast=s or =notNull in my project

>
>

Here are some examples where I had to use cast or notNull in my project.

Added:
>
>

The first and third arguments should not need a cast, they are Component and String as expected. The second is supposed to be an Object in Java. Nice does not make value automatically subtypes of Object. You can use the object(...) function instead of cast(...) to do that.

For this kind of issue, I think the best is to use retyping. In particular, are you aware of the NiceSwing? project? But I would like to hear that the above fix works first.

Added:
>
>

If ConnectionHandle implements ConnectorListener?, then the cast should not be necessary either. What is the error message you get without the cast?

Changed:
<
<

Why don't you declare that this.getFromConnections() returns a List?

>
>

Why don't you declare that this.getFromConnections() returns a List<DecisionConnection>?


 <<O>>  Difference Topic NiceCasts (r1.2 - 22 Apr 2003 - DanielBonniot)
Changed:
<
<

here are some examples where I had to use casts in my project

>
>

Here are some examples where I had to use cast=s or =notNull in my project

Added:
>
>

Can you say more about the types of the methods used? Ideally, the cases should be self-contained.

Added:
>
>

You should use:

      Rectangle rect = this.getHandlesBoundsRect();
      int width = int(rect.getWidth());
      int height = int(rect.getHeight());

int(...) in Nice is equivalent to (int) ... in Java. See http://nice.sourceforge.net/manual.html#conversion

Added:
>
>

Added:
>
>

How do you know that the last element has the right type?

Added:
>
>

The notNull should not be necessary, since Nice 0.7.8! :-)

Added:
>
>

At least the notNull should not be necessary, because you tested for null above. Does it work to remove it?

Added:
>
>

Do you really need notNull? Why? What is the type of figure.getHandles() ?

Added:
>
>

Why don't you declare that this.getFromConnections() returns a List?

Deleted:
<
<

Added:
>
>

OK, thanks. I'll treat them progressively.

For those that are solved, if you feel that some documentation should be added (for the numeric types, I updated the User manual, so that it compares with the Java syntax). After that they can be deleted.

Some will probably need to stay, when they are a good example of a typing problem, and how to solve it. So we can keep those there.

-- DanielBonniot - 22 Apr 2003


 <<O>>  Difference Topic NiceCasts (r1.1 - 22 Apr 2003 - AlexGreif)
Added:
>
>

%META:TOPICINFO{author="AlexGreif" date="1051028461" format="1.0" version="1.1"}% %META:TOPICPARENT{name="WebHome"}% here are some examples where I had to use casts in my project
Daniel asked me to make this list in order to optimize the compiler.

      JOptionPane.showMessageDialog(cast(flowWindow),
         cast("Errors in flow.\nFlow byte code could not be generated.\nFlow will be saved without byte code."),
         cast("Error"),
         JOptionPane.ERROR_MESSAGE);
flowWindow extends JInternalFrame

      Rectangle rect = this.getHandlesBoundsRect();
      int width = cast(rect.getWidth());
      int height = cast(rect.getHeight());
getters return double


   java.util.List<Handle> handles = new ArrayList();
   ...
      ConnectionHandle ch;
      ch = cast(handles.get(handles.size()-1));
ConnectionHandle extends Handle


   public class ConnectionHandle extends Handle
      implements ConnectorListener
   {
      ...
   }

   java.util.List<ConnectionHandle> connectionHandles = this.getHandles().filter(asConnectionHandle);
   ConnectionHandle connectionHandle = connectionHandles.get(connectionHandleIndex);
   ?java.util.List<ConnectorListener> connectorListeners = conn.getConnectorListeners();
   if (connectorListeners != null  &&  notNull(connectorListeners).contains(cast(connectionHandle))) {...}
In the last line I check the existence of a ConnectorListener in a List of ConnectorListeners. The local instance connectionHandle implements ConnectorListener.


      ?Figure figure = getFrontFlowWindowDrawArea().getDrawing().getFigureExcept(
                  mousePos, this);
      if (figure == null)   return;
      Flowlet flowlet = cast(notNull(figure));
Flowlet extends Figure


      for (Iterator<ConnectorListener> iter = notNull(connectorListeners).iterator(); iter.hasNext();) {
         ConnectorListener ltnr = iter.next();
         
         if (figure.getHandles().contains(cast(ltnr))) {
            iter.remove();
            //println(" deleted: " + ltnr);
         }
      }


   getFromConnection(state) {
      java.util.List<Connection> followings = this.getFromConnections();
      
      for (int i = 0; i < followings.size(); i++) {
         DecisionConnection connection = cast(followings.get(i));
         if (connection.getState() == state) {
            return connection;
         }
      }
      return null;
   }
DecisionConnection extends Connection

more to come...

-- AlexGreif - 22 Apr 2003


Topic NiceCasts . { View | Diffs | r1.24 | > | r1.23 | > | r1.22 | More }
Revision r1.1 - 22 Apr 2003 - 16:21 GMT - AlexGreif
Revision r1.24 - 06 Jun 2003 - 20:26 GMT - AlexGreif
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.