Feature Request: Hashed Based Assertion

[deadalnix via Digitalmars-d]

On Friday, 27 November 2015 at 08:09:27 UTC, tcak wrote:
> On Friday, 27 November 2015 at 05:33:52 UTC, deadalnix wrote:
>> I see many solution here that do not require any language 
>> change. To start, have a linter yell at the programmer when 
>> (s)he submit a diff. Dev commit directly ? What the fuck are 
>> you doing ? Do code review and get a linter.
>>
>> Alternatively, generate a di file and hash it. You can have a 
>> bot do it and commit with a commit hook.
>>
>> DMD can dump infos about the program in json format. hash this 
>> and run with it.
>>
>> You may also change your strategy in term of source control: 
>> https://www.youtube.com/watch?v=W71BTkUbdqE . Unified source 
>> code aleviate completely these kind of issues to boot.
>
> Not one thing in your solutions give any simple solution like:
>
> static assert( __traits( hashOf, std.file.read ) == 0x1234, 
> "They have changed implementation again." );
>
> static assert( __traits( hashOf, facebook.apis.addUser ) == 
> 0x5543, "Check API documentation again for addUser." );
>
>
>
> di file wouldn't work. It doesn't contain implementation code. 
> Also, all APIs are in it. We need specific hash for each API, 
> so it doesn't take long time to find where the problem is.
>
> JSON is same as di. No difference.
>
>
> Yours are not helping, making everything more complex.

If the API signature change, the type system will yell at you. 
All the proposed solution will work.

If the implementation change, you can apply the same solution on 
the binary, tadaaa ! If you want less hash change, a good idea 
can be to dump llvm ir from ldc, and run the cannibalization on 
it using opt.

Also, if you have so much code that rely on implementation 
details that aren't in the API to the extent it is such a problem 
that you need language extension to handle it, you are doing 
something very very wrong.

Indeed I'm not helping. You think you need a language extension, 
when it is quite obvious you have some methodology problem on 
your side and refuse to reconsider.

What about, I know it is crazy, use a unified repository, have 
test and continuous integration, and submit diff with code 
review. If one change an API in a way that break the client code, 
the client ill fail and the CI tool will warn the developer that 
he needs to fix the client code or rework his API change. If the 
client code was not tested, then the problem is clearly not the 
API hash.

Not only this doesn't require language extension, but this solves 
way more problems than the one you want to solve here.

Now, don't get we wrong, I know how it is. Companies with broken 
work culture won't change anything unless the it is on the edge 
of bankruptcy. I understand. This is how it works.

Please understand that, on the other side, it doesn't seems like 
the right move to export broken work environment as language 
features.