Object.opEquals, opCmp, toHash

[foobar]

On Thursday, 16 February 2012 at 21:05:19 UTC, Don wrote:
> On 16.02.2012 20:10, H. S. Teoh wrote:
>> On Thu, Feb 16, 2012 at 01:53:46PM -0500, Jonathan M Davis 
>> wrote:
>>> On Thursday, February 16, 2012 09:38:54 H. S. Teoh wrote:
>>>> This is a non-problem once the compiler implements 
>>>> memoization as an
>>>> optimisation. Which it can't until we go ahead with this 
>>>> change.
>>>> This is the direction that we *should* be going anyway, so 
>>>> why not
>>>> do it now rather than later?
>>>
>>> I would point out that there are no plans to implement any 
>>> kind of
>>> memoization in the language or compiler. Also, while it can 
>>> help
>>> performance, it can also _harm_ performance. So having it 
>>> controlled
>>> by the compiler is not necessarily a great idea anyway. It's 
>>> really
>>> the sort of thing that should involve profiling on the part 
>>> of the
>>> programmer.
>> [...]
>>
>> Then I agree with bearophile that we should have @memoize (or 
>> its
>> negation), so that the programmer can indicate to the compiler 
>> that the
>> function should be memoized (or not).
>
> Unfortunately, that's too simple. Although the compiler can 
> memoize a few simple cases, it can't do it efficiently in 
> general.
>
> Sometimes it makes sense to store the memoized result in the 
> object, sometimes separately. Sometimes only certain cases 
> should be memoized --
> the question of whether to memoize or not may depend on the 
> value of the object (you only want to memoize the complicated 
> cases).
> It's too hard for the poor compiler.

I'll add to Don's comment a question: Compile-time memoization 
means the decision is static. Shouldn't the decision tough be 
made instead at run-time to account for the run-time 
characteristics of the process? E.g. memoize the frequent case. 
This sounds to me more in the realm of a JVM optimization rather 
than a compiler one.