> So I don't really see the relation. Even though it may seem at first > sight that you do not have to bother with individual objects in case > of split heaps, in practice you do because you have to make sure that > no pointer to any of those objects can escape beyond where you free > the split heap.
The issue is to provide some relief from leaks caused by heavily object laden applications written by programmers who know how to write objects, but don't know how to free them. If I'm sure of the scope of a group of objects, and also that one or more are leaking, then I could at least stop the leak in the short term by a mark and release. At any rate, I've found that while you or I might be very diligent at explicitly freeing resources, on a complicated system, some programmers simply are not, and we have to work with these programmers. > > 2) Contract programming. We have to be able to show proof of > That remains to be seen. This is the business side of software development which you may or may not be interested in. My concern for Contract Programming is based on a couple of issues we can certainly argue about, but I'm fairly certain that the future is going to unfold this way: 1) Internet is the emerging platform. The OS is just another background process. 2) Buggy applications are tolerated because they run on each "personal computer" island. User experiences with bugs are insulated. 3) Make the same app an internet process, and now bugs affect more users from fewer points of failure. Even trivial internet apps become mission-critical. The point is, the traditional software warranties won't be tolerated by business in the future. We have to carry responsibility and liability for our work, so we have to come up with techniques that prove "due diligence" that we've done everything we can to build our applications in an **accountable and auditable way**. Programmers at Lockheed turn their car keys over to test pilots. If an accident happens due to software, and provided the test pilot is still alive, the test pilot gets the car. That's an extreme example of a person's life on the line because of a programmer's work, but as the internet is exploited more and more as the platform it should be, the lives of lots of businesses will be affected in a serious way. Given two competing applications with matching metrics, the application that provides built-in accountability will get the job. This isn't a programming issue like whether we should support generics or whatever new language feature. It's a business issue. > This has been mentioned by many people before you, but it is quite > difficult to actually come up with such a model which is both easy/ > intuitive and correct. Feel free to add your own proposal. Just putting out feelers and would love to contribute to such a project. But I think it's a hell of a lot more important than just talking about it as a buzzy or fashionable concept. It's got to happen before the internet can be fully realized. > Note that extremely unlikely that things will happen just because you > say/think they are important. In most commercial project it depends > on whether you represent a lot of money which threatens to disappear > if your requirements are not met, because money is the primary value > there. I'm under no illusions about that. I am convinced that these are necessary projects for the future though. To imply that it is unlikely that they won't happen just because I think they're important simply means that you aren't convinced of their value. Respectfully, I believe you'll change your mind on this in the future. > In non-commercial projects, contributors/maintainers are the primary > value, and thus actually submitting something rather than saying what > should be done in your opinion is most likely to have any positive > effect (there is no shortage of people with great ideas about what we > should spend our time on). I can appreciate that, and I'm sure you guys who have done a brilliant job are tired of being hounded for new requests for years. I just wanted to gauge community interest. James _______________________________________________ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
