On Tue, Mar 23, 2010 at 5:01 PM, Sandro Magi <[email protected]> wrote: > On 23/03/2010 7:15 PM, Jonathan S. Shapiro wrote: >> If you start from a C++ background, it seems very natural to ask: >> shouldn't classes subsume structures/records, and it seems natural >> that the answer to this should "obviously" be yes. O-classes do not >> have this subsumption property, and in consequence, they will carry a >> high runtime performance overhead. An O-class defines a dictionary, so >> in general its "methods" must be invoked through a dictionary with the >> associated costs of that invocation. More problematic, an O-class has >> no fields, so simple getters and setters have prohibitive cost. > > What kinds of getters and setters are you considering?
It seems plausible that some classes might have properties (in the sense of C#). For such properties you have a getter and a setter in the dictionary/v-table. So you have one indirection to reach the v-table, and then you need to call a procedure in order to implement what should have been a single load/store instruction. Abstraction comes at a run-time cost. While it is often a good and useful thing to do, it is neither so good nor so useful that a systems programming language can afford to impose its use. > A field shared by all instances of a class X seems unlikely, since in > all likelihood you'd factor it out into a separate class Y which > encloses a reference to class X now lacking the field. Perhaps I am missing something, but this sounds (at first reading) like *exactly* the kind of expensive, imposed abstraction that I had in mind. > If for some reason there is indeed a field shared by all instances of a > class, you could introduce a special type of method, a > selector/accessor, which in the method dictionary is just an offset into > the instance record instead of a function pointer. But that is *also* an extra indirection. We wish to compile these out! > I'm not convinced that you would have all of these shared fields, and so > the need for accessors is unclear to me. Unless you're also trying to > unify record calculi with GADTs and type classes? That sounds neat, but > ambitious. :-) I think, rather, that I am drifting to the realization that they have always been unified, and that this unification has mainly been obscured by syntax restrictions and differences of lexicography. As I keep saying, more later (i.e. tonight). It is dinner time here, and then my son needs his bath. Some concrete things are more important than abstractions. shap _______________________________________________ bitc-dev mailing list [email protected] http://www.coyotos.org/mailman/listinfo/bitc-dev
