I thought about Remi’s argument a little more:
>
>> basically forcing me to write the code that the compiler generates for me
>> when i use an anonymous class.
>
And, it illustrates the danger of permitting syntactic shorthands out of
convenience — the user will not only not understand that the shorthand is
merely a convenience, but will develop a sense of entitlement in it, and wonder
why it won’t work everywhere.
Sealed types are SUMs; a sum should declare what it is a sum of. If we just
had the explicit syntax:
sum X = { A, B, C };
No one would be too bent out of shape that a sum can’t (directly) contain an
anonymous class or lambda, because OBVIOUSLY a sum has to name its parts. But,
because of two quirks of syntax, Remi (and millions of others, I’m sure) now
think I’m being gratuitously mean.
Quirk 1 is attaching the sum to the superclass being declared. This is
natural, in that we’re explicitly declaring it as a sum. Quirk 2 is the
shorthand form, where we are willing to infer the subtypes when it is
“obvious”, because we want to be nice. (Shame that our reward for being nice
is that people think we’re mean.)
If we think this is a problem, perhaps we should drop the short-form of
“permits” (though I think that would merely make people think we’re mean in
another way.) Or choose a short form that doesn’t seem to play into
all-too-easy misconceptions of what the feature is for. (Certainly, because we
can’t even come up with too good a short form right now, we should probably
leave it out for now, until we find something that doesn’t require three drinks
to seem sensible.)
At root, though, this disagreement over restrictions is really a disagreement
over what sealed types are. I want to say they are sums; Remi wants to say
they are really just access control lists for class extension. I think the sum
interpretation is more powerful and more grounded, so I lean that way.
