<html><body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;"><br>On 11 Nov 2014, at 16:20, Michael Homer <<a href="mailto:mwh@ecs.vuw.ac.nz">mwh@ecs.vuw.ac.nz</a>> wrote:<div><br></div><div>Michael, if you move your sentences out of the passive voice and give them subjects, I think that you</div><div>will find that you are saying that <i>you</i> never found a use for inheritance between classes. ("It’s intended that" => </div><div>"I intended that”). That’s fair enough. But I did find such a use: four classes (sequence, list, set, dictionary)</div><div>that all share the same methods (empty, with, withAll)). </div><div><br></div><div><blockquote type="cite">You're creating extra fresh objects as a hack to get inheritance<br>behaviour</blockquote><div><br></div>Yes, that’s right. I’m creating extra fresh objects because the language definition requires that I create extra fresh</div><div>objects. In this situation they are stateless, so this is quite unnecessary, but that’s the way that we have defined</div><div>Grace. Yes, I would like to see this simplified, but that’s not the scope of the current discussion. Although the </div><div>very fact that we have to have this discussion ought to indicate that the current design is unnecessarily complex. </div><div><br><blockquote type="cite">I get the impression from this that you saw enabling this sort of<br>approach as a deliberate part of the design,<br></blockquote><br><div>Yes, I certainly see sharing of code between objects as a fundamental part of the design of inheritance in Grace.</div><div>And I think that we support sharing of pure code quite well. Where it gets unreasonably complicated is in sharing </div><div>initialization — which doesn’t come up in this example.</div><div><br></div><div>The complexity that started this email chain comes from having a special mechanism for parameterization </div><div>by types, which has never been completely designed. Marco asked, quite pertinently, whether we are sure that </div><div>having such a mechanism in a language for novices is a good idea. I think that we should pay attention to this question! </div><div><br></div><div>Tim, I did reply to James’s email. To recap for the list:</div><div><br></div><div><blockquote type="cite">class collectionFactory.trait {<br> // requires withAll(elts : Collection<T>) -> Collection<T><br> method with(*a) { self.withAll(a) }<br> method empty { self.with() }<br> }<br><br>Are you proposing to add the generic parameter to the trait? Why can it not just<br>be on the methods? (with<T>(*a : T), empty<T>)</blockquote><br></div><div>In this example, the type parameters <i>can</i> be on the methods. I feel that this looses some expressivity,</div><div>namely, that with and empty both take the same type parameters. Maybe I should just move them to the methods. I added in the type </div></div><div>parameters because the context-sensitive syntax checking that’s going on in the dupDecls branch was complaining (quite correctly) that there</div><div>were undeclared `T`s in the previous version of the code.</div><div><br></div><div>The “method or def” question came up when adding stuff to the symbol table. When I process a class declaration, </div><div>I have to decide whether to treat the class name as being a def or a method. Some of the considerations are:</div><div><br></div><div><span class="Apple-tab-span" style="white-space:pre"> </span>- defs are confidential by default, whereas methods are public by default. What about classes?</div><div><span class="Apple-tab-span" style="white-space:pre"> </span>- defs can’t be used to override inherited attributes, but methods can. What about classes?</div><div><span class="Apple-tab-span" style="white-space:pre"> </span>- def’s can’t have type parameters, whereas methods can. What about classes? </div><div> <span class="Apple-tab-span" style="white-space:pre"> </span>- def’s cache the object that they answer, whereas methods create it afresh each time. In the case of a class, </div><div> <span class="Apple-tab-span" style="white-space:pre"> </span> the object that they answer is a stateless object with a single method, so this difference is semantically invisible.</div><div><br></div><div>In the spec, §8.8.2 says: [Andrew] I don’t recall ever discussing the default encapsulation rules for classes. </div><div>Should the class declaration be treated like a def, making the class confidential, or like a method, making it public? </div><div><br></div><div>Can we at least decide on this?</div><div><br></div><div><span class="Apple-tab-span" style="white-space:pre"> </span>Andrew</div><div><br></div><div><br></div></body></html>