Could we allow abstract classes to be instantiated via reflection again?

[Justin Fagnani]

Recently a change went in that made instantiating abstract classes an error, to match the language.

I find instantiating abstract classes sometimes useful, and don't really see why there should be an error that's different from instantiating non-abstract classes with abstract members. What's the difference anyway? In Dado (a DI container) we instantiate abstract module classes via reflection to get the value of fields. We don't access abstract members, so we don't trigger errors.

Any chance of a change here?

Thanks,

  Justin

[Gilad Bracha]

We can discuss. We're trying to be consistent with the language semantics, but if it's a pain point, we could reconsider I suppose.

--
Cheers, Gilad

[Gilad Bracha]

The larger question here is how this fits in with VM and dart2js behavior. It is all too easy to see how, at some point, someone decides to rely on the fact that abstract classes are never instantiated without realizing that reflection could violate that assumption. This can lead to all kinds of problems, and that is one reason we try to stay consistent language semantics.

On Sun, Dec 22, 2013 at 7:58 PM, Justin Fagnani <justin...@google.com> wrote:

--
Cheers, Gilad

[Justin Fagnani]

On Thu, Dec 26, 2013 at 11:14 AM, Gilad Bracha <gbr...@google.com> wrote:

The larger question here is how this fits in with VM and dart2js behavior. It is all too easy to see how, at some point, someone decides to rely on the fact that abstract classes are never instantiated without realizing that reflection could violate that assumption. This can lead to all kinds of problems, and that is one reason we try to stay consistent language semantics.

Very good point.

I'm curious about the purpose of abstract classes in a language where a concrete class can have abstract members. The two main use-facing differences I see are warnings on abstract members for concrete classes, and abstract classes not being instantiable. Is there some other difference I'm missing, or some other reason to not allow instantiating abstract classes?

Cheers,

  Justin

[Gilad Bracha]

One issue is that the notion of abstract class serves as a surrogate for interfaces. Not having separate interface declarations simplified the language considerably, and abstract classes help enable that.

--
Cheers, Gilad

[Justin Fagnani]

True, but given that we only throw errors when actually accessing abstract members of a concrete class, not when constructing instances, what's the downside in allowing abstract classes to be instantiated? If instances of the class don't actually work, they don't work, but that's the same with concrete classes anyway.

[Gilad Bracha]

Justin,

At this point, such a change to the language semantics is matter for the standards committee (ECMA TC52).  In the meantime, we could meet and examine your use case and see if it justifies such a change being proposed to TC52.

--
Cheers, Gilad

[Justin Fagnani]

Yep, understood. I'm also interested in understanding the reasons for the current behavior and implications of changing it before proposing a change.

Thanks,

  Justin

[Lasse R.H. Nielsen]

On Fri, Dec 27, 2013 at 6:23 AM, mezoni <andrew...@gmail.com> wrote:

>> I'm curious about the purpose of abstract classes in a language where a concrete class can have abstract members.

Just tested, it works.

class A {

  abstract foo();

}

That syntax doesn't work any more. It's just:

  class A {

    foo();

  }

But I am confused because Dart Editor display this warning in two colors, Red and yellow colors used.

1. In red color "Members of classes cannot be declared to be 'abstract'".

That's because the "abstract" on foo isn't allowed any more. That's a syntax *error* (but we know what you mean, so the parser doesn't give up on parsing the rest and giving you more errors and warnings).

 

2. In yellow "'foo' must have a method body because 'A' is not abstract".

That's a static *warning*. You have a non-abstract class A that doesn't implement its own interface. That gives you a warning. You can choose to ignore that (it's just a warning), but it suggests that you may want to put "abstract" in front of the "class" to document that it is deliberate.

This warning can occur for real when you implement a super-interface, and the super-interface changes and adds an extra method. In that case, you will want to implement the method too to get rid of the warning.

 

I not understand the following.

1. Why different colors on the same "static warning"?

One is an error, and thus more important and red.

/L

 

2. Is the first warning more important the second?

3 Why both not in red color?

4 Why both not in yellow color?

Red color can means potential error (may be fatal).

Yellow color can means potential mistake (may be not fatal).

Is this means that the

1. "Members of classes cannot be declared to be 'abstract'" is fatal

2. "'foo' must have a method body because 'A' is not abstract" is not fatal.

I think they both lead to the same consequences.

But colors differs. Why?

P.S.

I think both colors must be yellow because this is allowed by languge declaration.

Even if it is unsafe.

This is the same as the following sample.

class Foo {

}

Foo foo = new Foo();

foo.callMissing();

In yellow "The method 'callMissing' is not defined for the class 'Foo'".

The same "foo' must have a method body because 'A' is not abstract" in yellow.

And "Members of classes cannot be declared to be 'abstract'" must be in yellow because this static warning not prevent program compilation and execution.

Also red color means "error" but "static warning" is not an error but the warning.

Is this means that Dart Editor can displays warnings in two colors?

As for me, I assume if color is red this is error and not allowed.

I this case I always think (because color is red) that this is not allowed by grammar.

That is, the wrong color is misleading.

Please don't display static warnings in red color in Dart Editor.

Or divide the static warnings on two kinds in the grammar.

But do not mix colors in Editor for warning. This confused.

P.S.

I want get answers here but not on Stackoverflow.

--
For other discussions, see https://groups.google.com/a/dartlang.org/
 
For HOWTO questions, visit http://stackoverflow.com/tags/dart
 
To file a bug report or feature request, go to http://www.dartbug.com/new

To unsubscribe from this group and stop receiving emails from it, send an email to misc+uns...@dartlang.org.

--
Lasse R.H. Nielsen - l...@google.com  

'Faith without judgement merely degrades the spirit divine'
Google Denmark ApS - Frederiksborggade 20B, 1 sal - 1360 København K - Denmark - CVR nr. 28 86 69 84

[Peter Ahé]

@mezoni:

We do test all our products for conformance to the language
specification. However, we're not passing all tests yet or we might
have forgotten to test something. You can see our "conformance" tests
here (https://code.google.com/p/co19/).

It actually looks like the co19 test suite doesn't test for this
particular case, and it would be really great if you could report it
at https://code.google.com/p/co19/issues/entry.

Cheers,
Peter

PS: As far as I know, co19 has no meaning and was a random sequence of
letters and numbers.

On Sun, Dec 29, 2013 at 6:44 AM, mezoni <andrew...@gmail.com> wrote:
> void main() {
> new Foo();
> }
>
> class Foo {
> abstract a;
> }
>
> +++++++++++++++++++++++
> Output:
> Unhandled exception:
> No constructor 'Foo' declared in class 'Foo'.
>
> NoSuchMethodError : method not found: 'Foo'
> Receiver: Type: class 'Foo'
> +++++++++++++++++++++++
>
> I think that this looks like you not tested compiler (and parser) for
> conformance to the language specification.
>
> I expect here see error about "It is a compile-time error to use a built-in
> identifier other than dynamic as a type annotation."
>
> P.S.
> Please not delete this message. I do not want ask this question on
> stackoverflow.com,