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