siop-development

[Siop-development] Send by reference or by value?

[Rapheal K. <ra...@ma...>]

  Question for folks... should the default mode of returning/sending values 
from method calls be by reference or by value for abstract types?  By 
reference would make for better network performance and would be closer to 
the way languages actually function, whereas by value would probably be 
better for compatibility.

  There is also a question of consistency.  Scalar values such as floats, 
integers and booleans always get sent by value by default.  So, if a function 
returns a boolean, SIOP will return to the client a boolean value for that 
platform rather than a reference to a boolean object.  However, as currently 
implemented non-scalar values, like lists and tuples are only returned by 
reference.  You need to make a call to "fetch-value" in order to have the 
server send a copy of those objects back to the client.

  When it comes to parameters, it should be possible to use simple object 
wrappers to indicate to the bridge to send objects by reference or value 
explicitly.  For example:

  remote_object.calculate_some_stuff( by_value( list_of_stuff ) )

  The function above might return another list of values.  Right now, this 
means that the client would receive a proxy that is a referenc to the list on 
the server.  If we changed the policy to be by default by value it a) makes 
the network traffic go up by default and b) makes it more difficult to keep 
the results of an operation on the server.

  Also how would we indicate how to return references by value or by 
reference?

  Maybe we could have by-reference proxies and by-value proxies.

  So, to explicity get the above reference by-value, you could do:

  value_proxy( remote_object ).calculate_some_stuff( list_of_stuff )

  All method calls to the value proxy could call a by value version of 
fetch-attribute and send-message instead of he default.

  Anybody care to venture thoughts?  Does any of this make sense?

  - Rafe

Re: [Siop-development] Send by reference or by value?

[Kevin S. <wx...@qu...>]

On Sat, 2006-06-17 at 17:05 -0700, Rapheal Kaplan wrote:
>   Question for folks... should the default mode of returning/sending values 
> from method calls be by reference or by value for abstract types?  

Speaking from a ruby standpoint, I think by-reference would be easiest
and least surprising. In ruby, simple objects like integers are
(conceptually) passed by reference...but they are immutable objects, so
the effect is as if you had passed them by value.

Speaking from an agile standpoint, I would be inclined to support only
by-reference until a case came up that made it unworkable. At that
point, a by_value wrapper would (hopefully) solve it.

Kevin

Re: [Siop-development] Send by reference or by value?

[Rapheal K. <ra...@ma...>]

> >   Question for folks... should the default mode of returning/sending
> > values from method calls be by reference or by value for abstract types?
>
> Speaking from a ruby standpoint, I think by-reference would be easiest
> and least surprising. In ruby, simple objects like integers are
> (conceptually) passed by reference...but they are immutable objects, so
> the effect is as if you had passed them by value.
>
> Speaking from an agile standpoint, I would be inclined to support only
> by-reference until a case came up that made it unworkable. At that
> point, a by_value wrapper would (hopefully) solve it.
>

  That was my thinking on it.  Integers and floats, however, will be passed by 
value.

  There is sort of already a use case, and as this is geared toward being 
compatible, it makes sense to support code where it requires an explicit 
certain type rather than just an interface.  This will certainly be the case 
for things like Java and it is already the case for the Python class 
structure, where the inheritence parameters require an actual tuple object.  
That's why in my example I use the Python tuple class to construct a tuple 
rather than just passing in a Ruby list which I would have definitely 
preferred to have done.

  But you are right, I am not going to rush it.  I think the next "Level" of 
SIOP should deal with these data typing/casting issues.