Feature Request: Hashed Based Assertion

tcak via Digitalmars-d digitalmars-d at puremagic.com
Fri Nov 27 12:19:39 PST 2015


On Friday, 27 November 2015 at 20:00:16 UTC, bitwise wrote:
> 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

Question: Has the behaviour of foo changed?

If foo cares about bar's behaviour, foo checks bar's hash value.

--

if(1) doSomething();
if(1) { doSomething(); }

You are correct here about hash calculation, but unless someone 
touches to codes, this never happens, and no hash changes would 
be seen. If someone is touching it as you exampled, checking the 
documentation about what has happened would be the correct 
approach. Importance of behaviour change is perceptional, 
computer cannot know that already.


More information about the Digitalmars-d mailing list