Indices vs. objects

davidnhutch

Matthias,

I notice some RBA methods use or return indices (cell indices, layer indices, perhaps others), while some use or return objects (cell objects, LayerProperties objects, perhaps others).

In some (just a relatively few) cases, there are equivalent methods where I can use, for example, either a cell index or a cell object. But I think in the majority of cases it uses one or the other.

But, it seems the best OO approach would be to have every method return an object. (By "object" of course I mean a non-integer (non-index) object, since even the indices are objects.) Of course, once you have the object it is trivial to get its index, and more often than not it is the object not the index that you want and that is more intuitive, in my opinion. I find I am constantly converting one to the other.

Is the dichotomy between using/returning object and index just historical, and do you plan to eventually deprecate all methods that use or return indices, and just use/return objects? Or is there a reason for the common use of indices?

This of course would be a major change affecting many RBA methods, so I'm not proposing you change it all right now. I'm just trying to understand why things are the way they are.

Thanks,
David

Matthias

Hi Dave,

Initially I used indexes because they are the data types used internally. But noticing that it's more convenient to work with objects I shifted to returning objects and gradually enhanced the interface with convenience methods taking or returning both indexes and objects. I have no plans deprecating the index methods, but when creating new ones I try to use objects.

But mentioning OO style: there is one limitation in the interface which shows up in some places and I added more object style versions. I'm talking about the "object nature" of some objects in the API.

Let me explain:

# Non-OO style interface
layout.rename_cell(cell.cell_index, "NEW_NAME")

# OO style interface: "cell" is an object and allows modifying it's properties,
# specifically "name" to rename the cell:
cell.name = "NEW_NAME"

The first version is close to the internal interface: initially I was trying to save the pointer which makes the cell know the layout the cell is contained it. Since the names are handled by the layout object (to make them unique for example), renaming a cell was a method of the layout. Cells are managed by cell indexes within the layout, so internally, the API is like the one given initially.

Having noticed that spending a few bytes for the layout pointer, I was able to provide the second version but the first one is still there for backward compatibility. But the second version is far more convenient.

Another example is:

# Old style
layout.delete_cell(cell.cell_index)

# OO style
cell.delete

There are similar equivalences in the are of Cell/Instance and Shapes/Shape. I have not introduced the OO style interface in the area of LayerProperties for example. Hence, in order to change layer display properties, you'll need to write:

lv = ... # LayoutView
iter = lv.begin_layers
# ... navigate to the layer you wish to modify ...
properties = iter.current.dup    # create a *copy*
properties.visible = false
lv.set_layer_properties(iter, properties)

An OO style interface would like this:

# NOT THERE YET:
lv = ... # LayoutView
iter = lv.begin_layers
# ... navigate to the layer you wish to modify ...
iter.current.visible = false

Matthias