[Grace-core] Minutes of Teleconference 2013-07-24

James Noble kjx at ecs.vuw.ac.nz
Tue Jul 30 10:47:34 PDT 2013


> One of the nice things about allowing overloading by arty is that you don't need negative information.  It's _always_ possible to add a method m to an existing object (through inheritance).

well mostly yes  (assuming you don't have final) 

> If there is an existing m of a different arty, then now there are two methods m, but they are statically different.

yes, and it's important we call them *two different methods* answering two different requests. (*) 

> If  the new and old ms have the same arty, then th new one replaces the old one, and the type changes appropriately.  

indeed. 

> This isn't to say that they may not be software engineering arguments in favor of requiring explicit overriding annotations, or against overloading by arity.    I'm just pouting out that the formal system gets simpler without these features.

annotations are certainly a separate issue

J




PS (*)

Modulo another of my bad ideas, generalising method requests, perhaps including optional
parameters, certainly with optional "keywords" and perhaps even keywords without parameters.

This would allow match/case/case,  if/then/elsif etc to be defined in the language, but it's probably
most useful to support more flexible DSLs and object creation something like 

graphicsLIbrary.scrollBarWidget  
       named "foo"  
       colour "red" 
       background "blue" 
       dragAction {v -> print(v)} 
       noAutoScrolling
       dynamicAppearance 

as a *single* request, defined in a single method.  I don't think we should do this, but I'd rather not make any decisions that would preclude it


More information about the Grace-core mailing list