I don't think i'm saying pass-by-value be the default for local
services,
what i'm asking is if operations are possible between local
components using
different data bindings, and if so then it seems more user
friendly that the
default be that it just works without having to define anything
extra to
make it work.
Sure if you can do the data transformation by-value which would be
really difficult to achieve with most databinding frameworks.
Otherwise the wire must be by-ref and the only way to do that is
when the target service contract explicitly declares its
remotability. This is extremely important to be declared in the
contract, as opposed to being the default, since the semantics of
the data are affected and the client cannot treat it as by-ref.
I think there are use cases where local pass-by-value makes sense.
For example, if the data is immutable then the framework can make a
copy to a different format and not break the semantic contract.
Taking this further, if the data is mutable but the target does not
modify it then we can again make a copy and still preserve the
semantic.
One way to do this would be to support something like an @ReadOnly
annotation that the target can declare on a parameter. In the local
(by-ref) case this would allow the runtime to make copies to
support incompatible data types; in the remote (by-value) case this
would allow the runtime to avoid making a copy if it didn't need
to. This could also be done at the type level with an @Immutable
annotation on the class.
Yea this like a good solution as since it forces that decision to be
explicit. The notion of read-only should probably be proposed to the
spec for local services. For the remotable case, we have the "allows
by-ref" marker. That means local service contracts must explicitly
declare this, and it is not the default. For remotable contracts, the
default would imply copying of params and nothing needs to be
proposed I believe.
Jim makes a good point about not repeating the mistakes from
earlier frameworks. I think the biggest mistake that they made was
to focus on the "how" (as in by-ref, by-val) semantics rather than
the "what" (read-only, immuatable) characteristics of the
interaction. I think if we do that we can provide the function Ant
would like.
That's why it is "allows" instead of "is" by reference ;-) Good
point, though.
--
Jeremy
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
