why no ++?

Marcin 'Qrczak' Kowalczyk qrczak at knm.org.pl
Thu Aug 9 03:49:44 EDT 2001


6 Aug 2001 21:47:49 GMT, Quinn Dunkan <quinn at retch.ugcs.caltech.edu> pisze:

> Yeah, that's a generally good practice in most imperative languages.
> It's good to keep mutating procedures and non-mutating functions
> clear in your mind.  Eiffel calls this "call query seperation".

Command/query separation.

In some functional languages it's not just a good practice but
a necessity, caused by language rules. In Eiffel and Python it's
merely a convention.

> Eiffel goes even further with this, for example:
> 
> fp.read_line
> s := fp.last_string
> 
> I haven't decided yet if this consistency is of the hobgoblin variety or not.

This is where I disagree with Eiffel. Commands should return a result
directly if applicable, introducing extra state in the object just
to pass the result of a command is bad.

Good parts of command/query separation are IMHO:

- If an operation can be written as either returning a result
  or storing it somewhere, it's generally better to return it.
  I.e. queries should not be unnecessarily expressed as commands.
  Separate gathering inputs, processing, and using outputs.

- Side effects should be documented. The user of a function should
  know whether and how it uses state.

Bad part is the assumption that commands must not return a value.
If some state is unavoidable, it doesn't imply that every communication
of that fragment must be expressed as state changing. This Eiffel's
rule is against the first rule above.

-- 
 __("<  Marcin Kowalczyk * qrczak at knm.org.pl http://qrczak.ids.net.pl/
 \__/
  ^^                      SYGNATURA ZASTĘPCZA
QRCZAK



More information about the Python-list mailing list