[Grace-core] Encoding classes

[James Noble]

> [THIS IS LONG BUT IMPORTANT -- PLEASE READ!]

Ok I've looked at it briefly - be interested to see what others think. 

> Good news:  Classes can be encoded as objects in ways that respect the type system.  

Right - so the key issues here are respecting the type system and a primitive extends operator?

> (Caveat -- I didn't write out all the details of the encoding and I'm not even sure how to write a method that returns a closure -- would writing it with {{ ... }} be proper?)

write the message or write the type?

I'd write. m -> { apply(A) -> B } {
 return { a: A -> a.toB } }

for message and type returned with all types explicit

J



> 
> Bad news:  No one in their right mind would want to write out classes by hand in this way.  (Can you imagine how helpful the error messages would be if your wrote it with this encoding and made a slight mistake?)
> 
> To get a properly-type encoding of classes as objects in their object calculus takes a fair amount of work, and is significantly more complex than the one we've been talking about.
> 
> There may be an alternative type-safe way of doing this encoding (there are a few simple modifications that I see, but they don't simplify things much), but I suspect that overall they will be of the same complexity as this.
> 
> So, if we want to continue to treat classes as encodings we need to:
> 
> 1.  Work out all the gory details of any proposal to ensure that it works in a type-safe way.
> 
> 2.  Convince ourselves that the results is (nearly as) understandable as the more traditional way of handling classes.
> 
> Unless we can do this, I highly recommend that we scrub the idea of encoding classes as objects and just have classes as primitives.  (Of course it is trivial to write objects as encodings using classes -- just write the obvious class with parameterless constructor and invoke new.)
> 
> Kim
> 
> 
> 
> On Jul 15, 2011, at 2:34 AM, James Noble 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?
>> 
>> Nope...
>> 
>>> 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.
>> 
>> This is why we (currently)may only write "extends Classname.new(x,y)" 
>> Irrespective of the encoding (or otherwise) used to implement factories and classes,
>> so long as the subclass declaration (ExtPairClass) can only extend a manifest
>> superclass (PairClass) I don't see any problem.
>> 
>> Even if the private methods aren't in the type either of the factory or the instance objects
>> produced by the PairClass class declaration, ExtPairClass can still consult the PairClass
>> _declaration_ and get all the information there. 
>> 
>>> 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.
>> 
>> Right. It's not just override, there may be other annotations (we will need final or some analogue of that,
>> at least for some of the earlier "language levels") with consistency conditions across subclasses.
>> This is why I think classes can only inherit from classes.  If we want object extension, for practical reasons,
>> objects should be restricted to inherit only from classes too. 
>> 
>>> 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.  
>> 
>> We could do it that way - I guess we have to decide, I don't know what's best.
>> I guess the question is: do we put *all* the information about a class into its type, or not? 
>> 
>>> (I don't recall if we settled on the prefix _  meaning protected or not).
>> 
>> No we didn't, and we didn't garner any discussion on the blog.
>> I had a few emails about it however, all of which made good points,
>> none of which agreed...
>> 
>> James
> 
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mailhost.cecs.pdx.edu/mailman/private/grace-core/attachments/20110716/6e13a661/attachment-0001.html>