Why bother with accessors at all? IMO, you're better off just specifying
usage constraints on fields. All you need are mutability and visibility
constraints. Take C#'s property accessors:
public Foo Bar { get; private set; }
You can just as easily take this as a usage specification for a Bar
field with no loss of generality, and no method overhead.
Sandro
On 25/03/2010 6:23 AM, b...@hisolutions.com wrote:
>>> 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
_______________________________________________
bitc-dev mailing list
bitc-dev@coyotos.org
http://www.coyotos.org/mailman/listinfo/bitc-dev
