On Thursday, 26 November 2015 at 11:12:07 UTC, tcak wrote:
I brought this topic in "Learn" a while ago, but I want to talk
about it again.
You are in a big team or working with a big code base. APIs are
being defined/modified, configuration constants are
defined/modified, structures are defined/modified for data.
You are coding on business logic side, and relying everything
based on current APIs, configuration, and data structures. A
part of codes have been updated on API side, but you are not
aware of it, or time has passed, and you assume that your code
will work properly. Nobody would be checking every single part
of business logic line by line.
On runtime, you will get unexpected results, and lose some hair
till finding where the problem is. Also finding expected
results on a long running processes would cause much more
trouble.
---
What I do currently is that: I calculate the hash of API code
(function, configuration, etc together) with a hash function,
and store it where the API is defined as a constant.
public enum HASH_OF_THIS_API = 0x1234;
// Hash is calculated from here
public void my_api_function(){}
public enum my_api_constant = 5;
// till here
Then wherever I use that API, I insert a "static assert(
HASH_OF_THIS_API == 0x1234 );".
Whoever modifies the API, after the modification, calculates
the most recent code's hash value and updates the constant.
This allows compiler to warn the business logic programmer
about changes on API codes. So, changing parts can be reviewed
and changes are made if required.
---
The feature request part comes here: It is possible that API
programmer forgets to update the hash value in the code. Also,
comments in the code shouldn't affect the hash value.
Automation is required on compile-time, so the compiler
automatically calculates the hash value of code, and it can be
read on compile-time. Hence, no constant is required to store
the hash value.
What is needed is to be able to bind a hash value to any block
with a name.
I'm wondering if a diff tool could be somehow combined with a
parser to create a list of functions/symbols which may have
experienced behavioural changes between versions of dmd. What I'm
suggesting is a diff tool which is aware of a symbol's
dependancies so that even if a function body wasn't changed, its
dependant symbols could be checked as well.
If such a tool existed, it could be ran against each new release
of dmd, and produce a comma separated list of functions that may
have experienced behavioural changes. With that list in hand, one
could then simply grep for each symbol in their own repository
each time they upgrade dmd.
I hearby place this idea in the public domain ;)
Bit