On Friday, 27 November 2015 at 18:51:54 UTC, tcak wrote:
On Friday, 27 November 2015 at 16:18:52 UTC, bitwise wrote:
On Friday, 27 November 2015 at 08:09:27 UTC, tcak wrote:
Yours are not helping, making everything more complex.
Yes, because to achieve what you're asking for, you NEED a
complex solution.
The code WILL change with every release..thats the point of a
release.. so any hashing mechanism like you're describing will
just trigger every time, making it useless. Even if this was
not the case, you still wouldn't know where the changes were.
Bit
Let me explain:
It is not complex. What makes it complex is that you envision a
very detailed thing.
Hash of a Function = MD5( Token List of Function /* but ignore
comments */ );
You do not have to know where the changes are. You need to know
what has changed,
how it acts currently briefly.
If behaviour of code changes, it is good that you know it. With
above hashing method, a piece of code that hasn't changed would
have same hash value always. And
if you do not like it, don't check the hash value. Just
continue writing your codes as you wish. But in business
perspective, if the software's consistency is worth millions of
dollars, a software engineer would want it to be giving error
whenever
codes change. Do we want D to be a child language, or have more
useful features?
Your approach is prone to false positives.
if(1) doSomething();
if(1) { doSomething(); }
Same behaviour, different code.
I hope you have a heck of a coding standard written up ;)
Worse still, consider the following example:
void foo() { if(bar()) deleteSomeFiles(); }
int bar() { return 0; }
Your proposed approach would not notify you that foo(), a
potentially dangerous function, has changed it's behaviour if
someone made bar() return 1.
*insert witty comeback to your comment about "business
perspective" here*
Bit
