| ePolyglot: Examination and development of multilanguage programming using Eiffel, Python, and Haskell | ||
|---|---|---|
| Prev | Chapter 11. Calling Eiffel from Python | Next |
As mentioned before, Eiffel is a properly garbage-collected language, while Python is a reference-counted language. When we were calling Python from Eiffel, it was fairly easy to keep track of this--Eiffel shadow classes updated the reference counts of Python objects during their lifespan, and it was totally acceptable to have Python objects that resided "only" in Eiffel space (in other words, without any other Python objects referencing them)--until the Eiffel shadow classes relinquished control and dereferenced the Python objects, the Python objects would never be deallocated.
The problem comes when Eiffel objects are wholly owned by Python shadow classes. The Eiffel objects don't have an easily-checked-and-modified reference count to prevent their automatic collection. An Eiffel object which is entirely outside the Eiffel "active objects" will be collected by the Eiffel garbage collector--even if a Python shadow class still uses it as an opaque pointer! The results could be disastrous.
The approach taken with our simple demonstration program is very simple--keep the object active until the program is over, meaning that it is never garbage collected. Since our sample program creates this object in its root creation procedure, this is easy to do--but such a simple solution would never work for a complex product.
The best suggestion we have so far is to create a singleton list in Eiffel-space which contains a reference to every Eiffel object which has been shadowed with a Python shadow class. This would require a slight modification to the Python eiffel_object shadow class, which would set the new object's opaque pointer and then add it to the "shadowed objects" list, removing it when the Python shadow object was dereferenced and deallocated, but would automate this sort of paperwork to a high degree. This has not been implemented yet, so users of the library as it currently stands must take care to carefully manage the lifespans of any Eiffel objects which may be shadowed by Python.