On 07/11/2012 07:46 PM, Andrei Alexandrescu wrote:
On 7/11/12 1:04 PM, Timon Gehr wrote:
On 07/11/2012 06:45 PM, Andrei Alexandrescu wrote:
On 7/11/12 12:30 PM, H. S. Teoh wrote:
It *is* a problem when you're talking about abstractions. If I have
million node binary trees and I'm testing for equality, I'd like to be
able to cache the results. But being forced to use const means I can't
cache anything. And this isn't just about caching; if my tree is
partially stored in the database, and I have a DB connection object in
my tree class, then I can't use opEquals because I can't modify the DB
state (which is impractical if I have to actually use it to make DB
queries -- the DB engine may have to cache DB pages, etc.). Any
abstraction of opEquals beyond the bitwise level cannot be implemented.
How about the static hash/cache?
Andrei
Will break horribly as soon as it is discovered that the methods should
be pure as well.
I don't think they should be pure. Do you have reasons to think otherwise?
Andrei
I think they should be pure as much as I think they should be const.
The reasoning is analogous for both.
We have immutable class instances that want to provide the methods =>
make them const.
We have pure functions that want to provide the methods => make them pure.
This reasoning is not taking into account the whole picture because
We have implementations of those methods that want to use non-const
methods in their implementation. (eg. database connection)
We have implementation of those methods that want to use non-pure
methods in their implementation (eg. database connection, logging)
