[ve-dev] VE model discussion

[Rich Kulp <richkulp@xxxxxxxxxx>]

Hi,

We are needing to extend the VE model.
This is the JCMMethod class that describes what Java instances are in a
particular initialization method.

Currently the JCMMethod has the following
two features:

1. "members":  This feature is used to store Java instances that have a variable (member) in the method:
          Label lable = new Label(...);
          TreeViewer treeViewer = new TreeViewer(...);
   
2. "properties": This feature is used to store Java instances that are just property settings. Property settings do not have a variable nor do they have and properties set on them:
          label.setText("xyz");
   
   An example that looks similiar BUT is not a property is:
          String str = "xyz";
          label.setText(str);
   
   This is because str is a member, even though it has no properties set on it.

We want to add the following two features:

1. "implicits": This is for storing implicit Java instances that do not have a variable (member) in the method:
          treeVewer.getTree();
          treeVewer.getTree().setBackground(...);
   
   What makes it different is there is no variable for it, but it can have properties set on it, and it itself is actually a property of another instance (in this case treeViewer).
   
   If we promoted it to a member (i.e. it has variable), it would no longer be in the implicits feature:
          Tree tree = treeViewer.getTree();
          tree.setBackground();
   
   The terminology in these cases is we have an implicit allocation (treeViewer.getTree()) and an implicit declaration for the first case. For the second case we still have an implicit allocation but now we have an explicit declaration.
   
2. "values": These are part way between members and properties. These are for objects that have an explicit allocation but an implicit declaration:
          new Label();
          new Label().setText();
   
   Here we have no variable assigned, but it is no a property of another member. The Java syntax of this format allows at most one property to be set. If you needed to set two properties it would need to be an explicit declaration (a variable) so that it can be referenced twice.
   
   This construct is useful in SWT GridLayout. We need to declare many filler labels but these labels don't need to have any properties set on them. The current scheme requires us to create a variable for each one. But the modern compilers flag these as unused variable warning. If we could generate without the variable then the warnings would go away.
   
   Another strange result of this is the following (though the example is strained, it is possible):
          label.setAlignment(new Label(parent, SWT.LEFT).getAlignment());
   
   In here "label" is a member, "new Label(parent, SWT.LEFT)" is a value (and not a property), "new Label(parent, SWT.LEFT).getAlignment()" is a property with an allocation that calls a method (getAlignment) on a value instance ref (new Label(...). Our current scheme doesn't turn this into an implicit, it just executes it on the remote vm.
   
   However, the case could be made that in this case "new Label(parent, SWT.LEFT).getAlignment()" is really a property.This can be debated and model wise it would still work. It may cause problems with code parsing and they could decide which way to view this. The reason it could be tricky to decide which is because for Label we really want it to be a value because under the covers "new Label() " creates a setting of the "controls" setting of the parent composite and we don't want to loose that by treating the entire _expression_ as just a property with no reference to the label in controls feature. But something like:
          label.setAlignment(new Integer(SWT.LEFT).intValue()):
   Should be treated as just a simple property and not as a value with a method call on it.
   
   So the use of values within a property setting needs to be thought out very carefully.
   

Thanks,
Rich