On Wed, Jul 2, 2014 at 4:00 PM, Matt Oliveri <[email protected]> wrote:
> On Wed, Jul 2, 2014 at 3:37 PM, Jonathan S. Shapiro <[email protected]> > wrote: > >> So than no direct access to private fields of another object of the > >> same class. Gotcha. > > > > You're making an assumption that the entire notion of public and private > > fields isn't hopelessly boogered... :-) > > You're right, I did assume that. :) I think I can even figure out a > translation to existential types, in the style of abstract data types. > protected fields are the part that's boogered. Just to clarify: do you mean this generically (protected and private fields) or did you actually mean fields that are syntactically labeled as protected? Because from a programming perspective, I always felt that it was the "private" fields that were boogered, and that in nearly all cases private fields ought to have been protected. But it's instructive to consider a reference counted pointer implementation in which the reference count is stored in a common superclass. The reference count field is very peculiar: - It actually shouldn't be visible in the target object at all. The only class that should be able to reference it is the counted pointer class. What this mainly reveals is that the desired visibility access isn't always hierarchical or even lexical in nature. - The count field needs to be mutable even if the object is constant What's really going on is that the counting stuff and the target object are conceptually two completely different things that are being abutted for (a fairly important) convenience of implementation. In C++ the only way you can express that is with inheritance, which gets you into a world of problems. Hmm. It's only just occurred to me that there's another possible design for that which is probably better. shap
_______________________________________________ bitc-dev mailing list [email protected] http://www.coyotos.org/mailman/listinfo/bitc-dev
