Talk:Command–query separation

message: "A CQS pattern suitable for multithreaded environment" is written above a method that returns a value by assigning it to an out parameter. Simply replacing "return x;" with "*ret = x;" is not Command-Query-Separation. 
Either the line labelling it as CQS or the snippet itself should be changed. --SealedSun (talk) 11:40, 17 July 2009 (UTC)
thread_title: 3rd example in "Drawbacks"

message: A quote from the text:
It is noteworthy that rigid implementation of this specification makes tracking the number of times queries have been issued essentially impossible.
Can someone defend this claim? How does this principle make it impossible to track the number of queries? Please explain?  — Preceding unsigned comment added by 89.31.193.191 (talk) 07:53, 4 July 2012 (UTC)
thread_title:  "tracking the number of times queries have been issued essentially impossible" 

message: The current article has the following paragraph near the bottom:
Finally, here is a thread-safe CQS pattern. This preserves the separation between the mutation of state and reading the resulting value, without introducing a race condition in the caller:
private int x;
private int _x;
public int value()
{
  return x;
}
void increment()
{
  lock _x;   // by some mechanism
  _x = _x + 1;
  x = _x;
  unlock _x; // by some mechanism
}
However, if this is meant to be C++, calling increment() and value() concurrently from two different threads definitely invokes undefined behavior (because the public x is read in value() and modified in increment(), with no synchronization). In Java, because "the memory model doesn't guarantee that you'll see the latest updates from one thread in another thread, without extra memory barriers of some kind", the behavior is also incorrect; "without any explicit volatility or locking, the other thread could see 0 forever." Basically, if value() and increment() need to communicate between different processors, and you can look at the code for value() and *see* that it doesn't contain any inter-processor communication primitives, then you *know* the code can't possibly work.
Therefore I'm removing the paragraph and code sample. –Quuxplusone (talk) 20:50, 28 February 2016 (UTC)
thread_title:  Removed misleading section on multithreading 

message: "In a multi-threaded program, there is a race condition in the caller, between where increment() and value() would be called:"
Shouldn't that be: "between the threads calling increment():"
A single read of a variable can not create a race condition, as in value().
And to follow CQS, shouldn't threads have their own copy of any object. If an object is to be modified, then it must be done in the parent thread.
Shawn H Corey (talk) 14:42, 26 February 2018 (UTC)
thread_title:  2nd example in "Drawbacks" 

message: How does one do error-handling if commands are not allowed to return success/failure information? Antistone (talk) 20:18, 22 May 2018 (UTC)
thread_title:  Error Handling 

message: Why does the "See More" section's sole link consist of the fluent interface page? There are no mentions of how it relates. If a method that evokes state change also returns a value, then this contradicts the summary's statement about commands not returning data.  — Preceding unsigned comment added by Vvanpo (talk • contribs) 06:49, 18 October 2019 (UTC)
thread_title:  Fluent interfaces in "See More" 

message: The "Other Architectural Patterns" section is copied verbatim from https://martinfowler.com/bliki/CQRS.html  — Preceding unsigned comment added by 67.208.190.2 (talk) 15:17, 29 September 2020 (UTC)
thread_title:  Other Architectural Patterns copied from Martin Fowler