Communication between the languages is done by creating objects in the other language: Python objects can be created from steve code, and vice versa.
To include a Python file from a steve simulation file, simply use an
"@include" statement with the name of the Python file, just
as steve files are included.
To use a Python class from a steve file, simply create a new instance of the class exactly as you would with a steve object. Likewise, methods can be called in the new object exactly as usual. Because of differences between the two languages, there are a few minor differences in calling objects over the bridge:
Keywords are ignored for arugment passing. Instead, arguments are expected in the order they are defined for a method. When calling Python methods from steve, you can use made-up keyword names (to preserve the normal steve syntax), but be sure to match the argument order of the python method.
steve uses the "-" (dash) character in many method names, but Python does not allow this character in method names. If calling a steve method from Python, use the "_" (underscore) character in place of "-". The character will be converted automatically.
Foreign language objects appear to behave exactly as native objects, meaning that methods are called in native syntax. For typical usage, this is the only thing that matters.
The foreign language objects are not, however, truely native. The objects are actually "bridge objects", which forward method calls to the native object. Practically speaking, this means a couple of things:
Bridge objects always appear to be of the same type, no matter what type they actually represent in their native language.
Functions that inspect internal object state will be inspecting the bridge object, not the object that the bridge represents.
Duplicate object names between steve and Python are not strictly prohibited, but will cause difficulties so be sure to give objects unique name. When mixing objects of the case of built-in breve classes (such as Stationary or Real), it may be necessary to create object subclasses with unique names to resolve ambiguities. This situation may arise, for example, when adding a collision handler for a standard object.
These details are subtle and do not effect most typical object usage. Just remember that bridge objects are "shells" for other objects, and not the actual objects they appear to be.
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.