Return Values vs Status Queries vs Status Messages 
Author Message
 Return Values vs Status Queries vs Status Messages


Quote:
>I think there's really four dimentions:

>1) Does the routine have a side-effect visible outside of the program?
>     (E.g., it write to a file or a terminal)
>2) Does the routine have a side-effect visible inside of the program
>             but outside of the object?
>     (E.g., some non-side-effect function will now return a
>      different result, like "generate next random number" might)
>3) Does the routine return a value (in which case Eiffel calls it a
>       "function" instead of a "procedure", both being "routines")?
>4) Does the routine change state invisibly to the caller?
>     (E.g., does it cache a calculation, or modify other objects and
>      then return them to their original state (say while counting
>      or searching a linked list)?)

>I think all four of these are orthoganol, and I think the CQS
>(Command/Query Separation) principle is to disallow routines that do 3
>along with either 1 or 2.

Combining 3) with 1) and 2) is not bad per se. It is even very useful:
- to avoid cluttering the class state with irrelevant attributes: some
commands yield by-product that do not belong in the class state (e.g. think
of factory methods which are inherently incompatible with the Referential
Transparency Principle)
- as Juergen pointed out, to ensure that nothing changes between the call
and the access to the result, which can be hard to prove in presence of
recursivity and/or inheritance
- to avoid network round-trips in distributed architectures

The problem is that if you use functions to combine 1), 2) and 3) you defeat
the RTP. One way to reconcile the CQS with the need to have by-product
generating commands is to use procedures with "out parameters" - a construct
that is terribly missing in Eiffel.

Quote:
>How well this actually works in practice is
>not directly known to me, altho if you go over to comp.lang.eiffel I'm
>sure you'll hear how wonderful it is.

Maybe you will also hear how not wonderful it is - at least without out
parameters :-)

Regards
Jocelyn

[ FAQ: http://www.*-*-*.com/ ]
[     *  No Flames, No Spam, No Nonsense: Just OO discussion  *   ]



Sun, 02 Sep 2001 03:00:00 GMT  
 Return Values vs Status Queries vs Status Messages

Quote:

> The problem is that if you use functions to combine 1), 2) and 3) you defeat
> the RTP. One way to reconcile the CQS with the need to have by-product
> generating commands is to use procedures with "out parameters" - a construct
> that is terribly missing in Eiffel.

I think that's really a network transparency issue. In this case, you
are sending a message to a remote process, so you have an object in the
message. You call a procedure to set the "in" parameters on the message
(2), then you call a procedure to send the message (1).

Then the remote process calls functions to retrieve the state from the
message (2) , process it (internal work), and put new state back in
(3).  It then returns the message (3).

The original caller gets the message back and looks inside using (2).
Hence, the return values are state in the message packet, not in the
callee.

If your language hides from you the fact that you're actually building a
network message, it's a little harder to see this. Naturally, if your
programmers write code as if there's no network transmission, you're
going to have to make the code uglier to get the compiler to have
low-overhead network transactions.

--
Darren New / Senior Software Architect / MessageMedia, Inc.
     San Diego, CA, USA (PST).  Cryptokeys on demand.
"For efficient programs, practice featurecide regularly."
[ FAQ: http://www.paragon-software.com/comp.object.moderated.faq/ ]
[     *  No Flames, No Spam, No Nonsense: Just OO discussion  *   ]



Mon, 03 Sep 2001 03:00:00 GMT  
 Return Values vs Status Queries vs Status Messages
Darren New a crit dans le message

Quote:

>> The problem is that if you use functions to combine 1), 2) and 3) you
defeat
>> the RTP. One way to reconcile the CQS with the need to have by-product
>> generating commands is to use procedures with "out parameters" - a
construct
>> that is terribly missing in Eiffel.

>I think that's really a network transparency issue.

Network transparency is one of the main goals of architectures based on
DCOM
or CORBA, and to a certain extent SCOOP. What makes them appealing is
that
you can call features on distant objects much the same way you do it
with
local objects. Unfortunately, the CQS principle gets in the way of this
goal
(or rather should I say: Eiffel's support of CQS does) because it
conflicts
with the need to minimize network round-trips.
Anyway, network transparency is only one argument in favor of "out
parameters". The other ones concern modelling (uncluttered class state
spaces)  and correction (assurance that the state has not changed
between
the command and the query calls).

Quote:
>In this case, you
>are sending a message to a remote process, so you have an object in the
>message. You call a procedure to set the "in" parameters on the message
>(2), then you call a procedure to send the message (1).

>Then the remote process calls functions to retrieve the state from the
>message (2) , process it (internal work), and put new state back in
>(3).  It then returns the message (3).

>The original caller gets the message back and looks inside using (2).
>Hence, the return values are state in the message packet, not in the
>callee.

Do you mean that you resend the whole state after each command ? This
can be
overkilling ! Especially when the state contains arrays or other big
structures.

Quote:
>If your language hides from you the fact that you're actually building a
>network message, it's a little harder to see this. Naturally, if your
>programmers write code as if there's no network transmission, you're
>going to have to make the code uglier to get the compiler to have
>low-overhead network transactions.

Or you can have a more universal thus more uniform model based on CQS
with
"out parameters"...

Regards
Jocelyn

[ FAQ: http://www.paragon-software.com/comp.object.moderated.faq/ ]
[     *  No Flames, No Spam, No Nonsense: Just OO discussion  *   ]



Tue, 04 Sep 2001 03:00:00 GMT  
 Return Values vs Status Queries vs Status Messages

Quote:

>- to avoid cluttering the class state with irrelevant attributes: some
>commands yield by-product that do not belong in the class state (e.g. think
>of factory methods which are inherently incompatible with the Referential
>Transparency Principle)

I don't know about that.  In the compiler we're writing, we use
an idiom like this:

        function_call: FUNCTION_CALL

        create_function_call (target: FUNCTION; args: ARRAY[EXPRESSION])

It seems to work ok.

--
--
Patrick Doyle

[ FAQ: http://www.paragon-software.com/comp.object.moderated.faq/ ]
[     *  No Flames, No Spam, No Nonsense: Just OO discussion  *   ]



Tue, 04 Sep 2001 03:00:00 GMT  
 Return Values vs Status Queries vs Status Messages
Patrick Doyle a crit dans le message ...

Quote:
>I don't know about that.  In the compiler we're writing, we use
>an idiom like this:

> function_call: FUNCTION_CALL

> create_function_call (target: FUNCTION; args: ARRAY[EXPRESSION])

>It seems to work ok.

It works if you want your freshly created object to be assigned to an
attribute.
It does not
1) if you want it to be assigned to a local variable
2) if you do not want `create_function_call' to be bound to `function_call'
3) if the attribute is created ad-hoc , i.e. only for the purpose of making
create_function_call work.

1) and 2) can be illustrated by the following example:

make is
  do
    create_function_call(target, args, => function_call)
  end;

function_call: FUNCTION_CALL;

create_function_call(target: FUNCTION; args: ARRAY[EXPRESSION]; out
function_call: FUNCTION_CALL) is
  do
    ...
  end;

Now, `create_function_call' is no more bound to `function_call' and can be
reused in another context:

make is
  local
    function_call2: FUNCTION_CALL;
  do
    create_function_call(target1, args1, => function_call1)
    create_function_call(target2, args2, => function_call2)
  end;

3) can be illustrated by the "class factory pattern": class FACTORY is used
to instantiate objects of a family of related types T1, T2, ... Tn :

class FACTORY is
  create_t1(out v: T1) is do ... end
  create_t2(out v: T2) is do ... end
  create_tn(out v: Tn) is do ... end
end

strict adherence to CQS w/o out parameters would have required n "ad-hoc"
attributes, last_t1, last_t2, ... last_tn.
Note that n can be arbitrarily high. Examples are easy to find: T1, T2, ...,
Tn can represent nodes in an abstract syntax tree for example.

Regards
Jocelyn

[ FAQ: http://www.paragon-software.com/comp.object.moderated.faq/ ]
[     *  No Flames, No Spam, No Nonsense: Just OO discussion  *   ]



Tue, 04 Sep 2001 03:00:00 GMT  
 Return Values vs Status Queries vs Status Messages

Quote:

> Network transparency is one of the main goals of architectures based on
> DCOM
> or CORBA, and to a certain extent SCOOP. What makes them appealing is
> that
> you can call features on distant objects much the same way you do it
> with
> local objects.

The other choice, of course, is to make everything look like "distant"
objects and let the compiler translate local calls into a more efficient
form. This is what Hermes does, and it seems much cleaner than (say)
SCOOP.  It's not really compatible with Eiffel, tho.

I think it's kind of disingenuous to say that DCOM or CORBA *is* network
transparent if you need to start using different programming styles to
avoid noticing the network is in the way.  If you have to program around
network inefficiencies, then your code isn't network transparent even if
it uses the same syntax.

Quote:
> Do you mean that you resend the whole state after each command ? This
> can be
> overkilling ! Especially when the state contains arrays or other big
> structures.

Not at all. What I'm saying is this.

The client calls "res := serv.write_bytes(data)" on the server.  The
server returns the number of bytes written.  This is not CQS, but it's
network-efficient.  You can get the same efficiency by eliminating the
transparency by making the message evident in the transaction.

Client creates "write_bytes" message. Client calls
"write_bytes.store(data)", then "write_bytes.send_to(serv)". Server gets
the message and calls "x := write_bytes.get", then does whatever with X,
then calls "write_bytes.store(res)" and "write_bytes.return_to(client)"
or some such. Client then calls "res := write_bytes.get_res" or some
such. All 100% CQS, but with explicit "write_bytes.send_to(serv)" calls
in it.  If you're really worried about the efficiency, it may be better
to know you're talking to a remote process and exactly when you do.  

In addition, I can imagine bindings where the remote object ("serv") can
write "return write_bytes.get" and have the result returned stored in
the returned packet/buffer/message/whatever that serves as the proxy
object in the Eiffel code. So, like, "serv" could say "return X" and the
client might need to say "proxy.get_result" to get the value of X.  I
don't see these as incompatible.

(Or, in Hermes, if the last variable in a message is an "out" variable,
you can say "res := serv.call(a,b,c)" and that's shorthand for
"serv.call(a,b,c,res)" that you can use in expressions.

Quote:
> Or you can have a more universal thus more uniform model based on CQS
> with
> "out parameters"...

Which is basically what Hermes does, with "in" and "out" and "constant"
attributes and such.

--
Darren New / Senior Software Architect / MessageMedia, Inc.
     San Diego, CA, USA (PST).  Cryptokeys on demand.
"For efficient programs, practice featurecide regularly."
[ FAQ: http://www.paragon-software.com/comp.object.moderated.faq/ ]
[     *  No Flames, No Spam, No Nonsense: Just OO discussion  *   ]



Tue, 04 Sep 2001 03:00:00 GMT  
 Return Values vs Status Queries vs Status Messages


Quote:

>3) can be illustrated by the "class factory pattern": class FACTORY is used
>to instantiate objects of a family of related types T1, T2, ... Tn :

>class FACTORY is
>  create_t1(out v: T1) is do ... end
>  create_t2(out v: T2) is do ... end
>  create_tn(out v: Tn) is do ... end
>end

>strict adherence to CQS w/o out parameters would have required n "ad-hoc"
>attributes, last_t1, last_t2, ... last_tn.

At the risk of revealing that I've missed your whole point...

Isn't this merely a syntactic issue, rather than a semantic one?
That is not to say that syntax is not important--for instance,
your aspects idea is "merely" syntactic, yet is also a good
idea--but I just want to make sure I understand what we're
discussing here.

In particular, it doesn't seem to me that factory methods are
inherently incompatible with referential transparency, as you
said earlier.  Unless, of course, you meant all-in-one factory
methods which create the object and then return it?  In that
case, I would agree that such methods are not transparent.

--
--
Patrick Doyle

[ FAQ: http://www.paragon-software.com/comp.object.moderated.faq/ ]
[     *  No Flames, No Spam, No Nonsense: Just OO discussion  *   ]



Wed, 05 Sep 2001 03:00:00 GMT  
 Return Values vs Status Queries vs Status Messages

--

David Clark
University of Canberra



Quote:

> One way to reconcile the CQS with the need to have by-product
> generating commands is to use procedures with "out parameters" - a
construct
> that is terribly missing in Eiffel.

Well, you do have "out" parameters. Every reference parameter is an out
parameter.
There is nothing to stop you having

proc (x : X) is
do
        x.change
end

Of course you can't have
prox (x : X) is
do
        x := y
end

David
[ FAQ: http://www.paragon-software.com/comp.object.moderated.faq/ ]
[     *  No Flames, No Spam, No Nonsense: Just OO discussion  *   ]



Wed, 05 Sep 2001 03:00:00 GMT  
 
 [ 8 post ] 

 Relevant Pages 

1. stdcall vs c vs cdecl vs pascal vs whosyerdaddy

2. 68K vs CFM68K vs Tk 8.0.3 vs AppearanceLib vs System 7

3. Exceptions vs Error return values

4. PIL: resize vs. thumbnail return values

5. Query on status of Eiffel at Cognos

6. MASM vs TASM vs VC++ vs DJGPP vs A*^ vs PCC vs DEBUG,, "Hello World!"

7. MASM vs TASM vs VC++ vs DJGPP vs A*^ vs PCC vs DEBUG,, "Hello World!"

8. Query about Types SIG status

9. Oratcl Status Query

10. Query: itcl-2.0 status?

11. Return status of Eiffel programms

12. Why does open3.popen return status?

 

 
Powered by phpBB® Forum Software