> > I guess you don't really want fields but a possibility to substitute > > fields for methods with no arguments creating accessors on he fly. > That is sufficient ONLY if we can statically compile out all of the > resulting overhead.
FWIW, Dylan took the route of generating automatic accessor methods for all object fields. There isn't even a way for a user of a class to distinguish between a "real" field and handcrafted accessors that just look like fields. The effect is a decoupling between usage sites of a class and its implementation, which makes the code easier to maintain. The Dylan compilers usually do a good job of eliminating the actual method call. Accessing a field boils down to calculating its offset in the memory structure of the object. As long as there is only a single inheritance path for data members, this offset is fixed for all subclasses of the class that introduced the member. There's a mechanism called primary classes to enforce fixed offsets for some members even in the multiple inheritance case. Two more points. One is that in Java, quite a lot of people consider it to be good style to exclusively use accessors, and the automatic refactoring in Eclipse that automatically generates accessors is pretty popular. The other one is that in cases where your compiler can't eliminate the method call, you would have needed some ad-hoc dynamic mechanism anyways. Regards, Andreas Bogk _______________________________________________ bitc-dev mailing list bitc-dev@coyotos.org http://www.coyotos.org/mailman/listinfo/bitc-dev
