Nice TWiki > Dev > NiceCasts (r1.3) TWiki webs:
Dev | Doc | Main | TWiki | Sandbox
Dev . { Changes | Index | Search | Go }
Here are some examples where I had to use cast or notNull 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

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.

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.


      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


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

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


   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.

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

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


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

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


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

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


   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

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


more to come...

-- AlexGreif - 22 Apr 2003

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

Topic NiceCasts . { Edit | Attach | Ref-By | Printable | Diffs | r1.24 | > | r1.23 | > | r1.22 | More }
Revision r1.3 - 23 Apr 2003 - 08:04 GMT - DanielBonniot
Parents: WebHome
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.