Possible way to achieve lazy loading with const objects

Steven Schveighoffer schveiguy at yahoo.com
Thu Sep 29 10:50:01 PDT 2011


On Thu, 29 Sep 2011 13:48:02 -0400, Peter Alexander  
<peter.alexander.au at gmail.com> wrote:

> On 29/09/11 12:33 PM, Steven Schveighoffer wrote:
>> On Wed, 28 Sep 2011 19:21:33 -0400, Peter Alexander
>> <peter.alexander.au at gmail.com> wrote:
>>
>>> On 26/09/11 12:52 PM, Steven Schveighoffer wrote:
>>>> On Sat, 24 Sep 2011 07:19:33 -0400, Peter Alexander
>>>> <peter.alexander.au at gmail.com> wrote:
>>>>
>>>>> I'm happy to not have logical const in D provided that the Object
>>>>> interface (and other similar interfaces) don't require that opEquals
>>>>> is const or any nonsense like that. const means physical const, and
>>>>> opEquals should not require physical const.
>>>>>
>>>>> IMO const/immutable should *only* be used when you need to pass  
>>>>> things
>>>>> between threads i.e. when you *really do* need physical const. If
>>>>> people start using const like you would in C++ then every interface
>>>>> just becomes unnecessarily restrictive.
>>>>
>>>> FYI, this is a bug, not a feature.
>>>>
>>>> http://d.puremagic.com/issues/show_bug.cgi?id=1824
>>>>
>>>> It *will* be fixed eventually. The fact that opEquals is not const is  
>>>> a
>>>> huge problem.
>>>>
>>>> -Steve
>>>
>>> I was arguing that opEquals (and co.) should *not* be const. IMO it
>>> would be a huge problem if they were.
>>
>> why? For what purpose do you need to change an object during comparison?
>
> The comparison may involve comparing a sub-object that is lazily  
> created. It could also involve computing a cached perfect hash for  
> faster comparison, requiring memoization.

Neither of these are required for opEquals to work.  They are  
optimizations.

-Steve


More information about the Digitalmars-d mailing list