[Grace-core] Class syntax and type parameters

[Michael Homer]

On Wed, Nov 12, 2014 at 10:04 AM, Andrew P. Black <black at cs.pdx.edu> wrote:
> More on classes with type parameters.
>
> Here is the use case that prompted the question that I raised in the teleconference yesterday.
>
> factory method list<T> {
>     inherits collectionFactory.trait<T>
>
>     method withAll(a:Collection<T>) -> List<T> {
>         object {
>             inherits indexable.trait<T>
>             var inner := _prelude.PrimitiveArray.new(a.size * 2 + 1)
>             var size is public := 0
>             for (a) do {x->
>                 inner.at(size)put(x)
>                 size := size + 1
>             }
>                 …
>
> Notice that it’s necessary for the type parameter to go on the constructor object `list` rather than on the method `withAll()`: if the parameter is on `withAll()`, then it’s nor accessible on line 2 where it is needed to parameterize the inherited trait.
>
> So we have inconsistent naming:
>
>         list<T>.withAll
>
> but
>
>         collectionFactory.trait<T>
>
> because the latter is declared with the class syntax, and therefor can only — by virtue of Michael Homers pronouncement — be parameterized as above.
What you're doing is fundamentally unsupported by the inheritance
system, and so you can't expect it to flow. When you hack something
together consistency is a bonus if you can get it.
> This motivated by original question: does
>
>         class a.b { object constructor body }
>
> mean (1)
>
>         def a is public = object {
>                 method b {
>                         object { object constructor body }
>                 }
>         }
>
> or (2)
>
>         method a  {
>                 object {
>                         method b {
>                                 object { object constructor body }
>                         }
>                 }
>         }
>
> I had always assumed (1), but now (2) looks more reasonable.
#2 has all the disadvantages of both dotted and non-dotted classes
while managing to avoid picking up any of their advantages. (The same
applies to your original list at the top, in fact.)

There is a fundamental choice to be made about whether you want
classes to be first-class entities before or after generic
instantiation. You can't have both. I don't know what people want. If
you're programming without types then "after" is quite confusing.
"Neither" is non-dotted classes.
-Michael