Bridges between Python and "steve"

breve allows communication between the different language frontends via special "bridge" objects. A bridge object is an object in one language which acts as a proxy for an object in another language frontend. This allows a user to create and use simulation objects written with one language in another language. Practically speaking, this means that users writing simulations in steve can take advantage of Python's rich libraries and 3rd party code, and that users writing simulations in Python can make use of existing code written in steve without needing to rewrite it.

For the most part, bridge objects appear to be just like every other object in the simulation. Users can call methods in the objects and they can be passed around as arguments to other methods. There are a few important notes, however, to consider when using bridge instances:

• The Python language does not allow the "-" (dash) character in method names, while the steve language uses this character liberally. This character gets mapped to the "_" (underscore) character when interacting with Python objects. This means that to call the method "get-time" for a steve object, you should use the method name "get_time" in Python. Likewise, if a method "export-data" is called from steve on a Python object, Python will execute the method "export_data"
• There is no specific type information for bridge objects. Though bridge objects behave like a specific class in another language, they always "appear" to be of the same type. In Python, for example, a bridge object to any steve class will always appear as a "bridgeObject" instead of the actual steve class name it represents.
• Inspecting the internals of the object will not give accurate information. The dir function in Python, for example, will reveal the contents of the bridge object, and not the underlying steve object.