All right, all right! Interim decision regarding qualified Object methods

Steven Schveighoffer schveiguy at yahoo.com
Thu Jul 12 08:51:15 PDT 2012


On Thu, 12 Jul 2012 10:56:13 -0400, H. S. Teoh <hsteoh at quickfur.ath.cx>  
wrote:

> On Thu, Jul 12, 2012 at 09:31:27AM -0400, Steven Schveighoffer wrote:
>> On Thu, 12 Jul 2012 00:15:48 -0400, Andrei Alexandrescu
>> <SeeWebsiteForEmail at erdani.org> wrote:
> [...]
>> >3. opCmp, opEquals, and toHash are all needed primarily for one
>> >thing: built-in hashes. (There's also use of them in the moribund
>> >.sort method.) The thing is, the design of built-in hashes predates
>> >the existence of templates. There are reasons to move to
>> >generic-based hashes instead of today's runtime hashes (such as the
>> >phenomenal success of templated containers in C++), so it can be
>> >argued that opCmp, opEquals, and toHash exist for reasons that are
>> >going extinct.
>>
>> Yes.  Where's that new AA struct, Mr. Teoh? :)
> [...]
>
> The code is still here:
>
> 	https://github.com/quickfur/New-AA-implementation
>
> But I got roadblocked, partially because of constness issues
> (ironically, the problem was that toHash, toString, etc., weren't const,
> and now we're talking about supporting non-const versions of them), but
> more because of problems with IFTI. Or at least, that's where I left it
> about a month ago -- then I was away on vacation and haven't had the
> chance to go back to the code since. :(
>

Hm... chicken vs. egg again...

I think we need both the AA update and the removal of opX from object  
simultaneously.  Should we start a project branch for all the components?   
(is that appropriate for git?)

-Steve


More information about the Digitalmars-d mailing list