type parameter 'E' cannot be instantiated
_objects[i] = new E();
^
Is this a bug or by design? More importantly- How can I express this in Dart?
--
John McCutchan <jo...@johnmccutchan.com>
Am 05.05.2012 21:34 schrieb "Stephen Adams" <s...@google.com>:
>> class Table<E> {
>> ...
>> for (int i i = 0; i < maxObjects; i++) {
>> _objects[i] = new E(); /* ! */
> This is by design. I don't recall why.
Simple answer: Darts type system is an optional type system. Types are annotations and the runtime semantics don't change if you leave them away.
So leave <E> away. What shall be constructed?
Even more, E is a type _variable_ and thus can refer to any possible type depending on the call site. There's no guarantee that an empty constructor even exists for all possible types in E.
Simple answer: Darts type system is an optional type system. Types are annotations and the runtime semantics don't change if you leave them away.
So leave <E> away. What shall be constructed?
Even more, E is a type _variable_ and thus can refer to any possible type depending on the call site. There's no guarantee that an empty constructor even exists for all possible types in E.
Dirk, as I understand that's not actually true, dart's generics are reified (unlike in java); you can say "x is List<num>" which will be true if x was constructed with 'num' as the type parameter.
Dart also seems to have raw types for both values and type annotations (List x = new List()).
To me these combinations of features (optional typing + reified generics, reified generics + raw types) are pretty confusing!
You're right that the constructor can't be verified to exist, and this may be the reason you can't instantiate a type variable - constructors act like static methods and must be resolvable statically.
Am 06.05.2012 20:23 schrieb "Sam McCall" <samm...@google.com>:
>
> Dirk, as I understand that's not actually true, dart's generics are reified (unlike in java); you can say "x is List<num>" which will be true if x was constructed with 'num' as the type parameter.
Well, ok, I consider type and class to be not fully equivalent. So I supposed access to type _information_ (is List<num>) different from access to the _class_ that implements it.
That came from the fact that in List<E> the E could refer to an interface which not necessarily would be backed by a default class.
> Dart also seems to have raw types for both values and type annotations (List x = new List()).
> To me these combinations of features (optional typing + reified generics, reified generics + raw types) are pretty confusing!
>
I share this confusion.
> You're right that the constructor can't be verified to exist, and this may be the reason you can't instantiate a type variable - constructors act like static methods and must be resolvable statically.
>
That' what I thought.
Types are annotations and the runtime semantics don't change if you leave them away.
I think you guys have covered all of the salient points in this thread. Thanks!One clarification:Types are annotations and the runtime semantics don't change if you leave them away.Types aren't always annotations. There are type annotations, but there are also places where types appear in code that are not annotations. For example:
// type annotations:int i;foo(int i) => ...class Foo {int bar;int baz() => ...}
i: intfoo(i: int)class Foo { bar: int; ... }
// types that are not annotations:foo is String;new Foo();
new (): Foo
if (foo: String)
new Foo<Bar>();class Foo extends Bar implements Baz { ... }catch (SomeException ex) { ... }
catch (ex: SomeException)
// types that are not annotations:foo is String;new Foo();new Foo<Bar>();class Foo extends Bar implements Baz { ... }catch (SomeException ex) { ... }
I think we need to be more clear and draw a distinction between "optional" and "has no runtime semantics in production mode". In the two cases you mention below, Foo<Bar> and catch(SomeException e), the program's runtime semantics are affected, even in production mode.
>> try {
>> doSomethingDangerous();
>> } except (e is SomeException) {
>
>
> This would make look good to me. File an issue and see what other people think?
I was thinking about it and concluded that in this edge case, it probably isn't worth losing the familiar syntax. This can cause other types of confusion -- are all bool-returning expressions allowed here, or only 'is'?
On the other hand, should this change happen, I wouldn't oppose it.
LT
Am 08.05.2012 21:38 schrieb "Ladislav Thon" <lad...@gmail.com>:
>
>
> >> try {
> >> doSomethingDangerous();
> >> } except (e is SomeException) {
> I was thinking about it and concluded that in this edge case, it probably isn't worth losing the familiar syntax. This can cause other types of confusion -- are all bool-returning expressions allowed here, or only 'is'?
>
That is the reason I long for pattern matching or the like:
} catch (e) {
case e is SomeException : ....
case e ..... : ....
Try-catch intermingled with some sort of switch mechanism, which btw works only for a catch (like with Java) was a bad idea in my eyes.
It may only be me, but my question is where it is worth to _keep_ the familiar syntax. (Where "familiar" seems implicitly to be "Java" quite often).
That is why I like Scala: Good separation of concerns paired with combinability of features. Feels so ... Unixy.
> > Agreed about that syntax looking like a boolean expression, and that
> > pattern matching would be better. I still think it's an improvement.
> >
> > I'll see if there's a pattern matching bug already...
> Filed http://code.google.com/p/dart/issues/detail?id=2949 on pattern-matching.
I'd love to have pattern matching in Dart, but I sincerely hope that it wouldn't be like a switch, its syntax (with breaks and fallthrough) is terrible. But I know that Dart people are aware of that, so I'm not worried :-)
LT