Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Propose enhancement of field initializers #1038

Closed
DartBot opened this issue Jan 4, 2012 · 15 comments
Closed

Propose enhancement of field initializers #1038

DartBot opened this issue Jan 4, 2012 · 15 comments
Assignees
Milestone

Comments

@DartBot
Copy link

@DartBot DartBot commented Jan 4, 2012

This issue was originally filed by prujoh...@gmail.com


Propose that this:

class Foo{
final myOtherClass;

Foo()
: myOtherClass = new myOtherClass()

}

also allow this:

class Foo{
final myOtherClass = new myOtherClass();

Foo();
}

See: https://groups.google.com/a/dartlang.org/group/misc/browse_thread/thread/32998e270e3cb57b/ec5cfe02c5acfee5#ec5cfe02c5acfee5

@munificent
Copy link
Member

@munificent munificent commented Jan 4, 2012

More specifically, I believe John's proposal is to allow non-constant initializer expressions for final non-static fields. Java and C# allow this and, as far as I know, it doesn't have any of the hairy implications that static initializations have. It's basically syntactic sugar for running an initializer expression at the beginning of the constructor body.

@DartBot
Copy link
Author

@DartBot DartBot commented Jan 4, 2012

This comment was originally written by prujohn...@gmail.com


Yes. Thanks for putting a finer point on it. :)

@jtmcdole
Copy link
Contributor

@jtmcdole jtmcdole commented Jan 4, 2012

Added Area-Language, Triaged labels.

@jtmcdole
Copy link
Contributor

@jtmcdole jtmcdole commented Jan 4, 2012

Set owner to @gbracha.

@gbracha
Copy link
Contributor

@gbracha gbracha commented Jan 10, 2012

Added Accepted label.

@gbracha
Copy link
Contributor

@gbracha gbracha commented Jan 24, 2012

We are looking at changes to initialization.


Removed Type-Defect label.
Added Type-Enhancement label.

@DartBot
Copy link
Author

@DartBot DartBot commented Mar 26, 2012

This comment was originally written by pr...@gmail.com


Glad to see this is v.08. Thanks!

@gbracha
Copy link
Contributor

@gbracha gbracha commented Mar 26, 2012

Don't thank us yet!

a. The change only applies to static variables. We're still thinking about the implications for instance variables. That's a lot harder.

b. As the spec notes, the changes aren't implemented yet. But they will be.

And thank you for bearing with us.

@DartBot
Copy link
Author

@DartBot DartBot commented Mar 26, 2012

This comment was originally written by prujohn...@gmail.com


Excellent progress though. I still applaud it.

@anders-sandholm
Copy link
Contributor

@anders-sandholm anders-sandholm commented May 8, 2012

Always executed before any expression in the constructors' initializer list. 'this' must not be in scope for the expression. In addition, this prevents setting the final field in any other part of the code.


Added this to the M1 milestone.

@gbracha
Copy link
Contributor

@gbracha gbracha commented Jun 22, 2012

Spec version 0.11 allows arbitrary code in an instance initializer, provided "this" is not used.


Added Done label.

@DartBot
Copy link
Author

@DartBot DartBot commented Jun 22, 2012

This comment was originally written by pr...@gmail.com


Excellent!

@DartBot
Copy link
Author

@DartBot DartBot commented Jun 23, 2012

This comment was originally written by @seaneagan


in the following:

var c = 'c';

class A {
  var c = 'd';
  var b = c;
}

main() => print(new A().b);

I assume it will print 'c', but it could be surprising since normally instance variables can be accessed without "this." in class bodies.

@DartBot
Copy link
Author

@DartBot DartBot commented Jun 23, 2012

This comment was originally written by ladicek@gmail.com


Sean: I think that your example will fail (compile-time error?), because in the initializer of 'b', you implicitly access 'this'. The access to 'c' in this initializer is actually an access to 'this.c', because the 'c' inside the class shadows outer 'c'.

I don't think that scoping rules are changed by this, and it would be really confusing if they were (as you note).

@gbracha
Copy link
Contributor

@gbracha gbracha commented Aug 29, 2012

Changed the title to: "Propose enhancement of field initializers".

This issue was closed.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Linked pull requests

Successfully merging a pull request may close this issue.

None yet
7 participants
You can’t perform that action at this time.