[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