The invariant should only be checked when the code exits out of the class boundary.
e.g. If I have two classes A and B.
B calls a function on an object of class A. This function then calls another method on itself. It is only when the call come back to B, that the invariant needs to be checked.
This is difficult to implement without help from the compiler.
It is also interesting to compare assertions and unit tests.
Assertions have a big advantage over unit tests. They are tested every pass through the code, not just for the cases that get tested by the unit tests. You get a lot more checking, for less effort.
There are even tools that will 'unit test' code that has DBC. They generate lots of values that match the preconditions, run the code to see if the end result doesn't break the postconditions or assertions.
Going forward, there is no doubt that DBC in the code is going to greatly help code checkers such as FxCop.
Producing XML doesn't matter.
Almost all applications can produce output. The difficulty is on the input side. The level of complexity is asymmetric.
Sure lots of users want to run simple spreadsheets. However, in businesses, it is different. It isn't just sharing of the spreadsheet, it really is sharing of the data, so people can manipulate the data in different ways.
For example, download all details of employees of the company from one of the company systems, download details of budgets from different departments, and analyse the results. Not a particularly complex thing, but this illustrates what most spreadsheets now do within a business.
You have to get some sql to do the download from the HR system.
You have to link to spreadsheets produced by different departments (probably not to the same template)
You have to analyse and present the results.
It is all messy. It needs code. It needs integration from other systems that are outside the boundary of what Googlespreadsheet can do.
Nick
I have a decent play with it. It's ok, and there are quite a few bugs and annoyances. Some can be fixed, some can't.
1. Lots of beta gui issues - all fixable
2. Slow
3. Import works well
4. No named ranges - fixable
5. Sharing isn't all it is cracked up to be. I can't see a way of sharing the sheet with the public.
6. API to the sheet. For example, create a little compound interest calculator. How do you embed that in a web page? Would be great and I suspect they can do it.
7. Lack of VBA. Major issue. The great thing about Excel is just what you can make it do. Even just writting your own functions makes a big difference. I doubt they can fix this.
8. Integration. It is all stand alone. This is where it really fails. Almost all non trivial spreadsheets involve consolidating and publishing data. They won't be able to solve this.
Nick
It is false.
Consider a class heirarchy.
To make it really noddy, lets say we have a sqrt class. We have two implementations, OldSqrt and NewSqrt.
The method in the Sqrt class would include a precondition that X >= 0, and a post condition that abs (result * result - X) maxerror
Without DBC, you have to repeat these assertions in every implementation. That goes against a programming principle that you only write the same code in one place. With DBC, the conditions get inherited.
To really do DbC, you need help from the compiler.
Slashdot Mirror
Unfortunately, the emails show they have been manipulating evidence. That's why they don't want to release the raw data.
The Slashdot crowd like to be against "authority" ================== The reason is that have very strong evidence that its the correct decision
The invariant should only be checked when the code exits out of the class boundary. e.g. If I have two classes A and B. B calls a function on an object of class A. This function then calls another method on itself. It is only when the call come back to B, that the invariant needs to be checked. This is difficult to implement without help from the compiler. It is also interesting to compare assertions and unit tests. Assertions have a big advantage over unit tests. They are tested every pass through the code, not just for the cases that get tested by the unit tests. You get a lot more checking, for less effort. There are even tools that will 'unit test' code that has DBC. They generate lots of values that match the preconditions, run the code to see if the end result doesn't break the postconditions or assertions. Going forward, there is no doubt that DBC in the code is going to greatly help code checkers such as FxCop.
Producing XML doesn't matter. Almost all applications can produce output. The difficulty is on the input side. The level of complexity is asymmetric. Sure lots of users want to run simple spreadsheets. However, in businesses, it is different. It isn't just sharing of the spreadsheet, it really is sharing of the data, so people can manipulate the data in different ways. For example, download all details of employees of the company from one of the company systems, download details of budgets from different departments, and analyse the results. Not a particularly complex thing, but this illustrates what most spreadsheets now do within a business. You have to get some sql to do the download from the HR system. You have to link to spreadsheets produced by different departments (probably not to the same template) You have to analyse and present the results. It is all messy. It needs code. It needs integration from other systems that are outside the boundary of what Googlespreadsheet can do. Nick
I have a decent play with it. It's ok, and there are quite a few bugs and annoyances. Some can be fixed, some can't.
1. Lots of beta gui issues - all fixable
2. Slow
3. Import works well
4. No named ranges - fixable
5. Sharing isn't all it is cracked up to be. I can't see a way of sharing the sheet with the public.
6. API to the sheet. For example, create a little compound interest calculator. How do you embed that in a web page? Would be great and I suspect they can do it.
7. Lack of VBA. Major issue. The great thing about Excel is just what you can make it do. Even just writting your own functions makes a big difference. I doubt they can fix this.
8. Integration. It is all stand alone. This is where it really fails. Almost all non trivial spreadsheets involve consolidating and publishing data. They won't be able to solve this.
Nick
It is false. Consider a class heirarchy. To make it really noddy, lets say we have a sqrt class. We have two implementations, OldSqrt and NewSqrt. The method in the Sqrt class would include a precondition that X >= 0, and a post condition that abs (result * result - X) maxerror Without DBC, you have to repeat these assertions in every implementation. That goes against a programming principle that you only write the same code in one place. With DBC, the conditions get inherited. To really do DbC, you need help from the compiler.