[bitc-dev] Are type classes just abstract, generic classes?

[Sandro Magi]

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, bogk at 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 at coyotos.org
> http://www.coyotos.org/mailman/listinfo/bitc-dev