[Grace-core] Encoding classes

[Andrew P. Black]

My conceptual model is like this: an object understands request for ALL of its methods, even the protected ones ("private" in your terminology).  So a class with a method _helper has a different type from a class without the method _helper.  (I don't recall if we settled on the prefix _  meaning protected or not).

Protection comes from a syntactic restriction: method that are protected can be requested only on self and super, not on other receivers.  This does not show up in the type; all the type tells you is that if you request the method, then it will be understood.

There may be another model in which the types are involved in protection, which would mean that an inheritor of an object would see its type differently from another client.  (This is a bit like combining types and encapsulation policies; recall that users and inheritors typically need different policies.)  I'm sure that this model could be worked out, but it seems unnecessarily complicated.  For one thing, you can no longer ask "what's this object's type?", and expect a single answer.  Instead, the answer must be: "who did you say is calling?"

And who by fire, who by water, 
who in the sunshine, who in the night time, 
who by high ordeal, who by common trial, 
...
and who shall I say is calling? 



On 14 Jul 2011, at 17:33, Kim Bruce wrote:

> I continue to worry about whether we have a type-safe encoding of classes as objects with new methods.  Has anyone worked out the details?
> 
> A particular concern is objects with non-public methods (esp those accessible to subclasses, but not the general public).  Let's call those methods "private" for now, even thought they are closer to "protected" in Java and C++.
> 
> For example, suppose we have type Pair
> 
> type Pair {mkDiffPt(dx:Number,dy:Number) -> Pair}
> 
> where mkDiffPt creates a new pair that differs from the old by dx and dy.
> 
> A class PairClass generating objects should then have a type like:
> 
> type PairClassType {new: (x:Number,y:Number) -> Pair}
> 
> However, we notice that all classes generating Pairs that have a constructor taking a pair of numbers have exactly the same type.  This may be fine, but is going to cause difficulty if our class has non-public methods.  For example, suppose PairClass has a private method "helper".
> 
> The problem arises when I want to override "helper":
> 
> class ExtPairClass {x, y -> extends PairClass.new(x,y)
>                                     <override> method helper(...) -> ... {...}
> }
> 
> As I see it, the type system has no way of knowing whether PairClass has a helper method or not and hence whether or not the override is legal.  In particular, if I replace all occurrences of PairClass in the above by another class that also has type PairClassType (but no helper method), it should type check with exactly the same result.
> 
> My point is that Classes are more than constructors and the public methods.  In my languages, the types of classes including all protected features as well as those that were public.  I'm not at all sure how that can be done with this encoding.
> 
> 
> Kim
> 
> 
> 
> _______________________________________________
> Grace-core mailing list
> Grace-core at cecs.pdx.edu
> https://mailhost.cecs.pdx.edu/mailman/listinfo/grace-core