Feature Request: Hashed Based Assertion
deadalnix via Digitalmars-d
digitalmars-d at puremagic.com
Fri Nov 27 14:52:03 PST 2015
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
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
More information about the Digitalmars-d