Jonathan S. Shapiro wrote: > One thing we have learned in the capability world is that the human > abstractions for objects turn out to provide a very *bad* model for > thinking about objects in computing.
Without intending to continue this part of the discussion here: I'd appreciate pointers towards such results. I'm curious about them. > So I suggest that what we need is > programming languages that channel the brain into the right > intuitions. Having said that, I have no idea how to accomplish that > goal and I don't want to spend forever talking about it here. Let that > be a problem for the *next* poor programming language designer. Well said, and duly noted. The current set of goals of BitC is ambitious enough and will bring the state of the art forward quite a bit when reached. I've seen that you've backed away a bit from proof systems in favour of type systems, but I'm agnostic to whatever the solution looks like, as long as it takes us beyond the brittleness of C code while matching its usability and performance for system level code. > > But I'd like to hold up that deep in there, there's a good idea [in OO]. > Yeah. I thought so too. Then I wrote a book trying to help other > people get on board with C++. Then I realized that I had warped the > minds of about 35,000 readers. Fortunately, by then, my drinking > problem was well established, so I had in hand the right tool for > dealing with that problem. :-) Oh, the poor souls! Of course, I fully see why exposure to C++ might completely ruin the perception of any remotely good idea in it. > > The CLOS world has it much clearer: there are classes in the sense of > data > > storage with a hierarchical taxonomy, and there are generic functions > providing polymorphism. > > Even if I agreed, this isn't a discussion about the "best" OO scheme. > It's a discussion about how to put minimally sufficient support (if > any is needed) into the BitC type system to interoperate sensibly with > C++ and CTS. Well, it was appearing to me as if you were questioning the whole issue of how OO is supported within BitC. If interoperability is the concern, it's possible and maybe even a good idea to keep the foreign code at arm's length with an FFI, instead of letting it dictate how your OO system looks like. I once wrote an FFI bridge from Dylan (which uses CLOS style OO) to gobject (the ad-hoc single-inheritance/vtables object system written in C for the GTK+ GUI framework), so I have a bit of experience to draw from. It is possible to bridge between paradigms. However, since both Dylan and gobject operate on dynamic types, that was probably an easier task than what you are attempting. Don't you necessarily introduce the requirement to deal with dynamic types and class hierarchies in your type system, given the interoperability requirements? Best regards, Andreas Bogk _______________________________________________ bitc-dev mailing list [email protected] http://www.coyotos.org/mailman/listinfo/bitc-dev
