Gentle start with removing explicit interfaces

corelib/src/function.dart

Index: corelib/src/function.dart
===================================================================
--- corelib/src/function.dart	(revision 11079)
+++ corelib/src/function.dart	(working copy)
@@ -4,5 +4,5 @@
 
 // Dart core library.
 
-interface Function {
+class Function {

[sra1, 2012/08/21 18:31:39]

This should be abstract, otherwise it enables this nonsense:

  new Function();

[regis, 2012/08/21 19:13:22]

I agree with Stephen.

[hausner, 2012/08/23 00:25:06]

abstract does not prevent allocation of an instance. For that, we need to add a
private constructor so a default constructor does not get added.

Added abstract and private constructor.

[sra1, 2012/08/23 18:18:18]

Having to write constructors like this is ridiculous.
It is a lot of work.
And it adds very little value.

Making the class abstract does have one of the desired effects: dissuading

  new Function();

The spec says about abstract class: """
... If A is intended to be abstract, we want the static checker to warn
about any attempt to instantiate A, and we do not want the checker to complain
about unimplemented methods in A.
"""

And under "new":

"""It is a static warning if q is a constructor of an abstract class and q is
not a factory constructor."""



I had overlooked that we *may* also want to prevent 'class A extends Function',
and permit only
'class A implements Function'.

The library private constructor is ill-matched to this.  The constructor has the
wrong scope - being library private it enforces nothing within the same library.
 It also smacks of C++ - using some arcane implication of a constructor instead
of declaring intent.

There is almost no difference between

class B extends A {}
class B implements A {}

when A is 100% abstract (no implementations) and has no generative constructor.

So I would recommend removing all the private constructors at this point.
Let people write  'class Widget extends Hashable'.
The editor could have an optional warning that the 'extends' could be replaced
by 'implements' since Hashable has no non-abstract members.

[Ivan Posva, 2012/08/23 18:29:14]

It seems like this is mostly a discussion you should have with Gilad. For some
of the very basic pure interface like classes we need to ensure that they cannot
be instantiated, so we are working with the tools that have proven useful.

On 2012/08/23 18:18:18, sra1 wrote:

 }