[Siop-development] Passing by value and by reference
Status: Pre-Alpha
Brought to you by:
slobberchops
From: Rapheal K. <ra...@ma...> - 2006-06-29 07:43:36
|
I've added a "ref" and "val"... err... modifier? Not sure what to call them. They are intended to be simple markers that a host language can use as a hint to the bridge so that the bridge knows to over-ride the default parameter behavior for an object being passed to a peer either via parameters or return value. Remember, scalar values are passed by value by default while collections are passed by reference by default. These little keyword thingies can over-ride this default behavior. So, let's say you were calling a method that uses a list. It might be the case that the programmer can figure out that it would be an optimization to send the list to the other side, especially if the code over there does a lot of random access: remote_object.helpful_method( val( [ "a", "b", "c", "d" ] ) ) The example above would send a reference to the list if it were not for the modifier wrapper object. This is very useful in the example wxWidgets code where we needed to construct native Python tuples and dictionaries in order to be able to create new classes: # Helper method to define Python types # Class creation requires actual Python tuples, not pretenders # TODO: This can be disposed of when it is possible to pass # tuples by-value def tuple( *stuff ) list = $types.ListType.call for thing in stuff list.append( thing ) end $types.TupleType( list ) end # Helper method to define Python class # In the future, may provide helper library to do this def pyclass( name, *parents, &definition ) klass = $types.ClassType( name.to_s, tuple( *parents ), $types.DictType.call ) klass.instance_eval &definition unless definition.nil? klass end Now it's a little easier: # Helper method to define Python class # In the future, may provide helper library to do this def pyclass( name, *parents, &definition ) klass = $types.ClassType( name.to_s, Siop::val( Siop::Tuple( *parents ) ), Siop::val( {} ) ) klass.instance_eval &definition unless definition.nil? klass end Anyone who thinks they follow this and cares to voice their opinion as to wether this seems ok or is cumbersome, or thinks there might be a more preferable way, please tell me. - Rafe |