[dart-misc] 9/2 language meeting notes

['Bob Nystrom' via Dart Misc]

Here's my notes from this week's now hour long meeting:

https://github.com/dart-lang/dart_enhancement_proposals/blob/master/Meetings/2015-09-02%20Language%20Meeting.md

I mention this in the notes, but I want to call it out here. We're starting
to discuss this vague notion of "Dart 2.0". We don't know what that means
yet, and that means we'll be talking about all kinds of crazy radical ideas
which may or may not come to pass.

I think it's really important for us to speak freely, and it's also
important to do this in the open so we can involve all of you. But the cost
is that you may hear ideas that seem scary or disruptive, or ideas that
sound awesome but don't pan out. Try not to freak out and understand that
we're just brainstorming at this point.

Cheers!

- bob

['Brian Slesinsky' via Dart Misc]

re: reified types, I'm no longer using them in the PbList class in the
protobuf library [1]. The problem was that when constructing a list, it's
difficult to pass in the list item type as a parameter to an overridable
method that calls the list constructor. So, the new plan is to pass in a
"check" function instead of a runtime type. A function is more flexible
anyway, since some checks aren't Dart type checks. (For example, some
PbLists only accept 32-bit integers.)

The main thing on my wishlist is some kind of "implemented by" clause on a
Dart class. For example, you should be able to do this:

abstract class HasIdAndName implemented by SomeProto, Proto2, Proto3 {
String get id;
String get name;
}

This would make it easy for teams to do their own thing instead of having
to file a feature request to get a new interface added to a lower-level
library, which results in unfortunate and unnecessary political discussions
and perhaps even changes to build tools (in the case of protobufs) to allow
adding new library dependencies in unlikely places.

It would also let you create your own union types, so some folks might like
that too.

[1]
https://github.com/dart-lang/dart-protobuf/commit/5e603aeebe39c85f3f077d5eec8e0c35f9265e0b


On Thu, Sep 3, 2015 at 2:07 PM, 'Bob Nystrom' via Dart Misc <

Post by 'Bob Nystrom' via Dart Misc
https://github.com/dart-lang/dart_enhancement_proposals/blob/master/Meetings/2015-09-02%20Language%20Meeting.md
I mention this in the notes, but I want to call it out here. We're
starting to discuss this vague notion of "Dart 2.0". We don't know what
that means yet, and that means we'll be talking about all kinds of crazy
radical ideas which may or may not come to pass.
I think it's really important for us to speak freely, and it's also
important to do this in the open so we can involve all of you. But the cost
is that you may hear ideas that seem scary or disruptive, or ideas that
sound awesome but don't pan out. Try not to freak out and understand that
we're just brainstorming at this point.
Cheers!
- bob
--
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

[Rasmus Eneman]

There are a lot of changes mentioned, and while I think an open discussion
is great I'm scared for the scenario of Python 3 in Dart.
Dart have a much smaller community and splitting it could nearly kill it.

Reified generics
I can't see the reason for removal of reified generics. I expect that is
has to do with performance, and have to ask, is the difference significant?
Can't that optimization be done at run-time when the VM figures out that
the type information wont be used?
The reason I ask is because reified generics do have use cases and type
erasure doesn't provide any other. I have always seen Dart as a fast
language that still preserve the cool-features like optional-typing,
reified generics. Removing reified generics would express that performance
now
is more important than a great language, which would be sad I think.
Type testsI like the is operator, but I can certainly see the use case
mentioned. What if is would be an overridable operator like == and similar?
Type annotations on the right

Sounds to me mostly as a change for the sake of not looking to Java-like.
Couldn't the function type be expressed like such?

class Observable {
void() observer;
}

Static methods
Wohoo! One step closer to the mantra "everything is an object".
PartsIf the proposal to remove the library name is accepted I very much
would like this to. Simplifying the language and the change can easily be
done with a tool (maybe except for private stuff, but the tool could
probably make them public and just not export them in the wrapper library)
Fields final by defaultYes please! To make it explicit what are mutable and
will be changed should make the code easier to read.
Uniformity of referenceWith generalized tear offs we don't need the without
parentheses syntax to tear off the method so this should make it easier to
change between a getter and a methods. How will it work with classes
implementing function though? Will they be called and the tear of syntax be
needed to get hold of the object?

On Thu, Sep 3, 2015 at 11:39 PM, 'Brian Slesinsky' via Dart Core

Post by 'Brian Slesinsky' via Dart Misc
re: reified types, I'm no longer using them in the PbList class in the
protobuf library [1]. The problem was that when constructing a list, it's
difficult to pass in the list item type as a parameter to an overridable
method that calls the list constructor. So, the new plan is to pass in a
"check" function instead of a runtime type. A function is more flexible
anyway, since some checks aren't Dart type checks. (For example, some
PbLists only accept 32-bit integers.)
The main thing on my wishlist is some kind of "implemented by" clause on a
abstract class HasIdAndName implemented by SomeProto, Proto2, Proto3 {
String get id;
String get name;
}
This would make it easy for teams to do their own thing instead of having
to file a feature request to get a new interface added to a lower-level
library, which results in unfortunate and unnecessary political discussions
and perhaps even changes to build tools (in the case of protobufs) to allow
adding new library dependencies in unlikely places.
It would also let you create your own union types, so some folks might
like that too.
[1]
https://github.com/dart-lang/dart-protobuf/commit/5e603aeebe39c85f3f077d5eec8e0c35f9265e0b
On Thu, Sep 3, 2015 at 2:07 PM, 'Bob Nystrom' via Dart Misc <

Post by 'Bob Nystrom' via Dart Misc
https://github.com/dart-lang/dart_enhancement_proposals/blob/master/Meetings/2015-09-02%20Language%20Meeting.md
I mention this in the notes, but I want to call it out here. We're
starting to discuss this vague notion of "Dart 2.0". We don't know what
that means yet, and that means we'll be talking about all kinds of crazy
radical ideas which may or may not come to pass.
I think it's really important for us to speak freely, and it's also
important to do this in the open so we can involve all of you. But the cost
is that you may hear ideas that seem scary or disruptive, or ideas that
sound awesome but don't pan out. Try not to freak out and understand that
we're just brainstorming at this point.
Cheers!
- bob
--
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

--
You received this message because you are subscribed to the Google Groups
"Dart Core Development" group.
To unsubscribe from this group and stop receiving emails from it, send an

--
Rasmus Eneman

[Patrice Chalin]

+1 on all counts!

On Thu, Sep 3, 2015 at 2:07 PM, 'Bob Nystrom' via Dart Core Development <

Post by 'Bob Nystrom' via Dart Misc
https://github.com/dart-lang/dart_enhancement_proposals/blob/master/Meetings/2015-09-02%20Language%20Meeting.md
I mention this in the notes, but I want to call it out here. We're
starting to discuss this vague notion of "Dart 2.0". We don't know what
that means yet, and that means we'll be talking about all kinds of crazy
radical ideas which may or may not come to pass.
I think it's really important for us to speak freely, and it's also
important to do this in the open so we can involve all of you. But the cost
is that you may hear ideas that seem scary or disruptive, or ideas that
sound awesome but don't pan out. Try not to freak out and understand that
we're just brainstorming at this point.
Cheers!
- bob
--
You received this message because you are subscribed to the Google Groups
"Dart Core Development" group.
To unsubscribe from this group and stop receiving emails from it, send an

--
Patrice [image: View my LinkedIn Profile.]
<http://www.linkedin.com/in/patricechalin> [image: Google+ Profile.]
<https://plus.google.com/+PatriceChalin>

[Don Olmstead]

I HATE HATE HATE this. It was actually a huge ick when looking at
TypeScript.

var name : String;final pi : int = 3; // Close enough.

hasTwo(elements : List) : bool => list.length == 2;

Post by Patrice Chalin
+1 on all counts!
On Thu, Sep 3, 2015 at 2:07 PM, 'Bob Nystrom' via Dart Core Development <

Post by 'Bob Nystrom' via Dart Misc
https://github.com/dart-lang/dart_enhancement_proposals/blob/master/Meetings/2015-09-02%20Language%20Meeting.md
I mention this in the notes, but I want to call it out here. We're
starting to discuss this vague notion of "Dart 2.0". We don't know what
that means yet, and that means we'll be talking about all kinds of crazy
radical ideas which may or may not come to pass.
I think it's really important for us to speak freely, and it's also
important to do this in the open so we can involve all of you. But the cost
is that you may hear ideas that seem scary or disruptive, or ideas that
sound awesome but don't pan out. Try not to freak out and understand that
we're just brainstorming at this point.
Cheers!
- bob
--
You received this message because you are subscribed to the Google Groups
"Dart Core Development" group.
To unsubscribe from this group and stop receiving emails from it, send an

--
Patrice [image: View my LinkedIn Profile.]
<http://www.linkedin.com/in/patricechalin> [image: Google+ Profile.]
<https://plus.google.com/+PatriceChalin>
--
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

[Kasper Peulen]

The portion of the Dart team that comes from a Smalltalk background has

long missed non-local returns. The stated reason for > not having them is
that no one knows how to efficiently compile them to a language like JS
which lacks them. **If our focus is*
*> moving off the web towards execution environments we control,** Gilad
would like to put them back on the table.

What do you guys mean with "dart moving off the web" ? Would this non local
returns also available when you compile to javascript ?

I HATE HATE HATE this. It was actually a huge ick when looking at
TypeScript.
var name : String;final pi : int = 3; // Close enough.
hasTwo(elements : List) : bool => list.length == 2;

Post by Patrice Chalin
+1 on all counts!
On Thu, Sep 3, 2015 at 2:07 PM, 'Bob Nystrom' via Dart Core Development <

Post by 'Bob Nystrom' via Dart Misc
https://github.com/dart-lang/dart_enhancement_proposals/blob/master/Meetings/2015-09-02%20Language%20Meeting.md
I mention this in the notes, but I want to call it out here. We're
starting to discuss this vague notion of "Dart 2.0". We don't know what
that means yet, and that means we'll be talking about all kinds of crazy
radical ideas which may or may not come to pass.
I think it's really important for us to speak freely, and it's also
important to do this in the open so we can involve all of you. But the cost
is that you may hear ideas that seem scary or disruptive, or ideas that
sound awesome but don't pan out. Try not to freak out and understand that
we're just brainstorming at this point.
Cheers!
- bob
--
You received this message because you are subscribed to the Google
Groups "Dart Core Development" group.
To unsubscribe from this group and stop receiving emails from it, send

--
Patrice [image: View my LinkedIn Profile.]
<http://www.linkedin.com/in/patricechalin> [image: Google+ Profile.]
<https://plus.google.com/+PatriceChalin>
--
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

--
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

--
Kasper

[Don Olmstead]

The only time I've used part is when I want internal privacy. What if that
was implied by the library path? Like if you had .src.foo and src.bar then
those two have internal privacy?

Post by Kasper Peulen

The portion of the Dart team that comes from a Smalltalk background has

long missed non-local returns. The stated reason for > not having them is
that no one knows how to efficiently compile them to a language like JS
which lacks them. **If our focus is*
*> moving off the web towards execution environments we control,** Gilad
would like to put them back on the table.
What do you guys mean with "dart moving off the web" ? Would this non
local returns also available when you compile to javascript ?

I HATE HATE HATE this. It was actually a huge ick when looking at
TypeScript.
var name : String;final pi : int = 3; // Close enough.
hasTwo(elements : List) : bool => list.length == 2;

Post by Patrice Chalin
+1 on all counts!
On Thu, Sep 3, 2015 at 2:07 PM, 'Bob Nystrom' via Dart Core Development

Post by 'Bob Nystrom' via Dart Misc
https://github.com/dart-lang/dart_enhancement_proposals/blob/master/Meetings/2015-09-02%20Language%20Meeting.md
I mention this in the notes, but I want to call it out here. We're
starting to discuss this vague notion of "Dart 2.0". We don't know what
that means yet, and that means we'll be talking about all kinds of crazy
radical ideas which may or may not come to pass.
I think it's really important for us to speak freely, and it's also
important to do this in the open so we can involve all of you. But the cost
is that you may hear ideas that seem scary or disruptive, or ideas that
sound awesome but don't pan out. Try not to freak out and understand that
we're just brainstorming at this point.
Cheers!
- bob
--
You received this message because you are subscribed to the Google
Groups "Dart Core Development" group.
To unsubscribe from this group and stop receiving emails from it, send

--
Patrice [image: View my LinkedIn Profile.]
<http://www.linkedin.com/in/patricechalin> [image: Google+ Profile.]
<https://plus.google.com/+PatriceChalin>
--
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

--
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

--
Kasper
--
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

['Bob Nystrom' via Dart Misc]

Post by Don Olmstead
The only time I've used part is when I want internal privacy. What if that
was implied by the library path? Like if you had .src.foo and src.bar then
those two have internal privacy?

We have informally batted around the idea of "friend libraries", some way
to share private access between libraries. I personally think it's a cool
idea, though there are a lot of devils in those details.

Cheers!

- bob

[Don Olmstead]

I didn't say it didn't solve a problem. I just find it less aesthetically
pleasing.

Been doing some Golang recently so if I spend enough time in that maybe my
brain will get rewired.

On Thu, Sep 3, 2015 at 3:24 PM, 'Bob Nystrom' via Dart Misc <

Post by 'Bob Nystrom' via Dart Misc

Post by Don Olmstead
The only time I've used part is when I want internal privacy. What if
that was implied by the library path? Like if you had .src.foo and src.bar
then those two have internal privacy?

We have informally batted around the idea of "friend libraries", some way
to share private access between libraries. I personally think it's a cool
idea, though there are a lot of devils in those details.
Cheers!
- bob
--
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

['John Messerly' via Dart Misc]

Post by Kasper Peulen

The portion of the Dart team that comes from a Smalltalk background has

long missed non-local returns. The stated reason for > not having them is
that no one knows how to efficiently compile them to a language like JS
which lacks them. **If our focus is*
*> moving off the web towards execution environments we control,** Gilad
would like to put them back on the table.
What do you guys mean with "dart moving off the web" ? Would this non
local returns also available when you compile to javascript ?

I think the idea is, if you're in an environment like Sky, Dart could have
support for cool features like non-local returns.

When targeting the web, it would either be unsupported, or would come with
a warning that there is a high performance cost.

(aside: there are some middle grounds, like having your
functions/methods/function types explicitly opt-in non-local returns
through them. That localizes the cost to only the methods that want to use
the feature. With dev_compiler enforcing "strong mode", we'd be able to
somewhat control the cost. But marking functions comes downsides. e.g.
http://journal.stuffwithstuff.com/2015/02/01/what-color-is-your-function/.
Still, it might be better than not supporting the feature at all.)

Post by Kasper Peulen

I HATE HATE HATE this. It was actually a huge ick when looking at
TypeScript.
var name : String;final pi : int = 3; // Close enough.
hasTwo(elements : List) : bool => list.length == 2;

Post by Patrice Chalin
+1 on all counts!
On Thu, Sep 3, 2015 at 2:07 PM, 'Bob Nystrom' via Dart Core Development

Post by 'Bob Nystrom' via Dart Misc
https://github.com/dart-lang/dart_enhancement_proposals/blob/master/Meetings/2015-09-02%20Language%20Meeting.md
I mention this in the notes, but I want to call it out here. We're
starting to discuss this vague notion of "Dart 2.0". We don't know what
that means yet, and that means we'll be talking about all kinds of crazy
radical ideas which may or may not come to pass.
I think it's really important for us to speak freely, and it's also
important to do this in the open so we can involve all of you. But the cost
is that you may hear ideas that seem scary or disruptive, or ideas that
sound awesome but don't pan out. Try not to freak out and understand that
we're just brainstorming at this point.
Cheers!
- bob
--
You received this message because you are subscribed to the Google
Groups "Dart Core Development" group.
To unsubscribe from this group and stop receiving emails from it, send

--
Patrice [image: View my LinkedIn Profile.]
<http://www.linkedin.com/in/patricechalin> [image: Google+ Profile.]
<https://plus.google.com/+PatriceChalin>
--
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

--
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

--
Kasper
--
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

[Arron Washington]

I think the idea is, if you're in an environment like Sky, Dart could have support for cool features like non-local returns.

I feel like "moving off the web" is a stronger statement than that. For people using Dart and targeting browsers, that is a pretty important phrase to just casually slip in there.

['Brian Slesinsky' via Dart Misc]

Post by 'John Messerly' via Dart Misc
I think the idea is, if you're in an environment like Sky, Dart could

have support for cool features like non-local returns.
I feel like "moving off the web" is a stronger statement than that. For
people using Dart and targeting browsers, that is a pretty important phrase
to just casually slip in there.

Yes, despite the disclaimers it's a bit disconcerting. Perhaps a better way
to put it might be that we (well, not me, but other people) want to add
some language features that won't work in a web browser?

I think it's fine for dart4web to be a different subset of all Dart
language features than dart4mobile or dart4servers, so long as the lines
are clearly drawn. It seems like the language spec should define subsets
and the analyzer should help you keep within whichever subset you're
working in. If you're writing portable Dart, it should help you keep within
the intersection of all three; that's what I would use for the protobuf
library.

It would also help if Dart libraries were clearly labelled with the
environments they support, both for finding an appropriate library and
making sure the author actually intends to maintain compatibility.

- Brian

[Günter Zöchbauer]

+1

Post by 'Brian Slesinsky' via Dart Misc

Post by 'John Messerly' via Dart Misc
I think the idea is, if you're in an environment like Sky, Dart could

have support for cool features like non-local returns.
I feel like "moving off the web" is a stronger statement than that. For
people using Dart and targeting browsers, that is a pretty important phrase
to just casually slip in there.

Yes, despite the disclaimers it's a bit disconcerting. Perhaps a better
way to put it might be that we (well, not me, but other people) want to add
some language features that won't work in a web browser?
I think it's fine for dart4web to be a different subset of all Dart
language features than dart4mobile or dart4servers, so long as the lines
are clearly drawn. It seems like the language spec should define subsets
and the analyzer should help you keep within whichever subset you're
working in. If you're writing portable Dart, it should help you keep within
the intersection of all three; that's what I would use for the protobuf
library.
It would also help if Dart libraries were clearly labelled with the
environments they support, both for finding an appropriate library and
making sure the author actually intends to maintain compatibility.
- Brian

['Florian Loitsch' via Dart Misc]

Post by 'John Messerly' via Dart Misc
I think the idea is, if you're in an environment like Sky, Dart could

have support for cool features like non-local returns.
I feel like "moving off the web" is a stronger statement than that. For
people using Dart and targeting browsers, that is a pretty important phrase
to just casually slip in there.

Quite a few design decisions were made under the assumption that Dart would
live in the browser. We did implement a server VM (dart:io ...), but it was
tainted by these design decisions. For example, we never had a long
discussion on Dart's concurrency model, since we had that one imposed by
the browser's asynchronous callback model.
Since Dart is not going into Chrome anymore we want to revisit some of the
decisions we made. That doesn't mean we will come to different conclusions,
but we want to spend some brain cycles on them. Note that some decisions
might not even have any impact on Dart for the Web. For example, changing
dart:io to use a different concurrency model wouldn't have any impact on
web-programs, since they never had access to dart:io anyway.
Non-local return is clearly something that would have a global effect, and
therefore would require more thoughts.

Also, our biggest and most important internal customer (the one who is
paying our bills) is using Dart for the Web. My job is to make Dart a great
language, but I really want to keep them happy, too :)

--
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

--
Give a man a fire and he's warm for the whole day,
but set fire to him and he's warm for the rest of his life. - Terry
Pratchett

[kc]

Post by 'John Messerly' via Dart Misc

Post by Kasper Peulen

The portion of the Dart team that comes from a Smalltalk background has

long missed non-local returns. The stated reason for > not having them is
that no one knows how to efficiently compile them to a language like JS
which lacks them. **If our focus is*
*> moving off the web towards execution environments we control,** Gilad
would like to put them back on the table.
What do you guys mean with "dart moving off the web" ? Would this non
local returns also available when you compile to javascript ?

I think the idea is, if you're in an environment like Sky, Dart could have
support for cool features like non-local returns.

This sounds good.

I'm interested in the core runtime semantics and how they would integrate
Google's own tech on mobile. I would like:

Dynamic Runtime
+ value objects/immutability
+ concurrency/non-local returns

Sky UI <-- mojo ipc --> Runtime (Biz logic) <--- gRPC/protobufs ---> Server

Using the React model the Sky UI is about fast diff-ing a tree of value
objects. So value objects built into the runtime/lang should (ideally) aid
performance and gc pressure. And efficient serialization/ipc.
Concurrency is great for interacting with the server (and UI).

So if the runtime + Sky offers lag free 60fps for Material Design apps and
an expressive, fun and toolable lang - goodbye Java/XML.

K.

[Mark H]

Agree completely!

Post by Don Olmstead
I HATE HATE HATE this. It was actually a huge ick when looking at
TypeScript.
var name : String;final pi : int = 3; // Close enough.
hasTwo(elements : List) : bool => list.length == 2;

['Bob Nystrom' via Dart Misc]

Post by Don Olmstead
I HATE HATE HATE this. It was actually a huge ick when looking at
TypeScript.
var name : String;final pi : int = 3; // Close enough.
hasTwo(elements : List) : bool => list.length == 2;

With the current Dart syntax, how would you declare a field whose type is a
function with some signature? How would you attach a metadata annotation to
the return type of a method, but not the method itself?

- bob

['Lasse R.H. Nielsen' via Dart Misc]

On Fri, Sep 4, 2015 at 12:24 AM, 'Bob Nystrom' via Dart Misc <

Post by 'Bob Nystrom' via Dart Misc

Post by Don Olmstead
I HATE HATE HATE this. It was actually a huge ick when looking at
TypeScript.
var name : String;final pi : int = 3; // Close enough.
hasTwo(elements : List) : bool => list.length == 2;

With the current Dart syntax, how would you declare a field whose type is
a function with some signature?

int->int x;
(int,int)->int x;

(int,int)->(int)->int foo(int->int f1, int->int f2) => (int x1, int x2) =>
(int x) => f1(x+x1) + f2(x+x2)

I don't think this is ambiguous in any way ('-' followed by '>' is
currently only possible using suffix '--'), but it will complicate the
parsers. My guess is that more look-ahead will likely be needed.

We have avoided introducing function type literals, but that's a choice,
not a necessity.

I'm sure other syntaxes are also possible, perhapse even ones that look
more "C like":
int(int)
int(int,int)
int(int)(int,int)

That said, ':' is just a much more convenient syntax.

Post by 'Bob Nystrom' via Dart Misc
How would you attach a metadata annotation to the return type of a method,
but not the method itself?

I'm not sure I know what that would even mean.

Why not just do:
@Returns(someAnnotation)

/L
--
Lasse R.H. Nielsen - ***@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

['Lasse R.H. Nielsen' via Dart Misc]

Post by 'Lasse R.H. Nielsen' via Dart Misc
On Fri, Sep 4, 2015 at 12:24 AM, 'Bob Nystrom' via Dart Misc <

Post by 'Bob Nystrom' via Dart Misc

Post by Don Olmstead
I HATE HATE HATE this. It was actually a huge ick when looking at
TypeScript.
var name : String;final pi : int = 3; // Close enough.
hasTwo(elements : List) : bool => list.length == 2;

With the current Dart syntax, how would you declare a field whose type is
a function with some signature?

I now see that you say "with the current Dart syntax", but that's a
strawman. The argument is not against adding a way to write function types,
but against the actual suggested syntax for doing it.

/L
--
Lasse R.H. Nielsen - ***@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

[kc]

On Friday, September 4, 2015 at 6:58:06 AM UTC+1, Lasse Reichstein Holst

Post by 'Lasse R.H. Nielsen' via Dart Misc
On Fri, Sep 4, 2015 at 12:24 AM, 'Bob Nystrom' via Dart Misc <

Post by 'Bob Nystrom' via Dart Misc

Post by Don Olmstead
I HATE HATE HATE this. It was actually a huge ick when looking at
TypeScript.
var name : String;final pi : int = 3; // Close enough.
hasTwo(elements : List) : bool => list.length == 2;

With the current Dart syntax, how would you declare a field whose type is
a function with some signature?

int->int x;
(int,int)->int x;
(int,int)->(int)->int foo(int->int f1, int->int f2) => (int x1, int x2)
=> (int x) => f1(x+x1) + f2(x+x2)
I don't think this is ambiguous in any way ('-' followed by '>' is
currently only possible using suffix '--'), but it will complicate the
parsers. My guess is that more look-ahead will likely be needed.
We have avoided introducing function type literals, but that's a choice,
not a necessity.
I'm sure other syntaxes are also possible, perhapse even ones that look
int(int)
int(int,int)
int(int)(int,int)
That said, ':' is just a much more convenient syntax.

I prefer rhs but fine with a lhs succinct syntax which enables more complex
type annotations. Christian had a Ceylon inspired take here:
https://groups.google.com/a/dartlang.org/d/msg/misc/pmDHuwLDfRU/DwkenaRFDQAJ

How about:

// Simple type
Point p = Point(1,1);

// Complex type - needs a leading var/const on locals only
var Point | Line x;
var int Call(int, int) fn;



Also protobufs and mojo ipc went lhs and I think it would be useful to have
straightforward interop here.

K.

[Rich Eakin]

Post by 'Bob Nystrom' via Dart Misc

Post by Don Olmstead
I HATE HATE HATE this. It was actually a huge ick when looking at
TypeScript.
var name : String;final pi : int = 3; // Close enough.
hasTwo(elements : List) : bool => list.length == 2;

I agree, I think it reads poorly and have always disliked having to write
both 'var' and what the type is afterwards. Just seems unnecessary when
coming from C / C++.

Post by 'Bob Nystrom' via Dart Misc
With the current Dart syntax, how would you declare a field whose type is
a function with some signature?

How about:

class Observable {
void() observer;

// or:
function<void()> observer;
}


The latter is how you'd do it in C++11 and I love it as it is very clear
for future users.

How would you attach a metadata annotation to the return type of a method,

Post by 'Bob Nystrom' via Dart Misc
but not the method itself?

I'm not sure I understand the problem with the current syntax, Why doesn't
it currently work like:

class X {
}


class Y {
@NonNull X someMethod();
}



Or perhaps the 'post arrow' (->) construct be used here.

[tatumizer-v0.2]

Post by 'Bob Nystrom' via Dart Misc
With the current Dart syntax, how would you declare a field whose type is

a function with some signature?
I think here we have a case where more mathematically consistent format
(var x: int) is inconvenient for the human programmer. In 99% cases, we
deal with simple situations where "int x" is all we need, it's fluent,
clear, readable... So for the sake of 1% of rare cases, we are ready to
make the rest 99% worse?
Maybe instead we can just look for the best variant of disambiguation that
resolves the rare cases?

To me, the proposed change looks disproportionately dramatic.

[Günter Zöchbauer]

Danny, AFAIR this is not the first time you HATE HATE HATE something and
then after a while you find it quite nice :P

I haven't used any language with this style except the first programming
course at university with Pascal and am therefore not too keen for this
change but the arguments are compelling. It would add some beauty to the
language even when it hurts a bit because the current style is already
ingrained into my genes.

Post by Don Olmstead
I HATE HATE HATE this. It was actually a huge ick when looking at
TypeScript.
var name : String;final pi : int = 3; // Close enough.
hasTwo(elements : List) : bool => list.length == 2;

Post by Patrice Chalin
+1 on all counts!
On Thu, Sep 3, 2015 at 2:07 PM, 'Bob Nystrom' via Dart Core Development <

Post by 'Bob Nystrom' via Dart Misc
https://github.com/dart-lang/dart_enhancement_proposals/blob/master/Meetings/2015-09-02%20Language%20Meeting.md
I mention this in the notes, but I want to call it out here. We're
starting to discuss this vague notion of "Dart 2.0". We don't know what
that means yet, and that means we'll be talking about all kinds of crazy
radical ideas which may or may not come to pass.
I think it's really important for us to speak freely, and it's also
important to do this in the open so we can involve all of you. But the cost
is that you may hear ideas that seem scary or disruptive, or ideas that
sound awesome but don't pan out. Try not to freak out and understand that
we're just brainstorming at this point.
Cheers!
- bob
--
You received this message because you are subscribed to the Google
Groups "Dart Core Development" group.
To unsubscribe from this group and stop receiving emails from it, send

--
Patrice [image: View my LinkedIn Profile.]
<http://www.linkedin.com/in/patricechalin> [image: Google+ Profile.]
<https://plus.google.com/+PatriceChalin>
--
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

[Matthew Butler]

There are so many aspects in this that I want to reply to individually. I
understand these are not even tentative, but purely speculative. Some of
them I think are great, some I'm indifferent on and some I really dislike.
But like many others, I'm opinionated and can't resist sharing my opinions
:P (I've omitted topics that don't specifically pertain to me or I'm
indifferent on).

*Static checking for dropped futures*


I'm pretty indifferent on this. It's a nice feature but nothing exciting.

*Type tests*


I'm okay, though rather than the specified method being added, I'd prefer
something with a fixed name that is on Object that receives the type as a
parameter that can be tested against. eg: Object.isType(Type type);

*Type annotations on the right*


I'm not as big a fan of this, but I could grow to get used to it. Though by
the looks of it, it means, typed or not, I'll always have to use 'var' (or
const/final). Whereas currently, when type is specified I don't need to
also indicate it's a var.

*Constructor initialization lists*


I can live without these.

*Parts*


Drop 'em! They were a good intention for tooling early on, but I've stopped
using them myself in lieu of libraries (originally I used large monolithic
libraries but eventually start using smaller libraries instead).

*Symbols*


Drop 'em! They never felt like they really belonged in Dart to me since
their inception. They're fun in Ruby and seem to be a good fit there, but
in practice in Dart, I rarely use them

*Fields final by default*


I'm not adverse to this, but not thrilled by it either. Of all the changes
I think this would be one of the hardest to get used it.

*non-local returns*


wow.. dropping break and continue (but especially break), would take some
time to get used to again.

*Uniformity of reference*


Nooo please don't. A nice benefit the empty parens is that it shows it's a
method, not just a getter. A method which may have side effects, where as a
getter can (though generally shouldn't).

And just for the record, I like 'new' as well. I won't debate it, I'm not
saying I can't live without out. Just a personal fondness for it.

Matt

[Matthew Butler]

I meant to mention this also. If the target platform is moving away from client side web, towards mobile client side, I'm good with relaxing the constraint on "familiarity". I wouldn't go to the extreme of Brainf*** or some such silliness. But I'm good with pushing more innovation at the cost of familiarity.

[Hoo Luu]

Post by Matthew Butler
Type annotations on the right

+10000. And pls make semicolon optional.
圚 2015幎9月4日星期五 UTC+8䞊午5:08:22Bob写道

Post by Matthew Butler
https://github.com/dart-lang/dart_enhancement_proposals/blob/master/Meetings/2015-09-02%20Language%20Meeting.md
I mention this in the notes, but I want to call it out here. We're
starting to discuss this vague notion of "Dart 2.0". We don't know what
that means yet, and that means we'll be talking about all kinds of crazy
radical ideas which may or may not come to pass.
I think it's really important for us to speak freely, and it's also
important to do this in the open so we can involve all of you. But the cost
is that you may hear ideas that seem scary or disruptive, or ideas that
sound awesome but don't pan out. Try not to freak out and understand that
we're just brainstorming at this point.
Cheers!
- bob

[Anders Holmgren]

My 2c

1/ What is the rationale for dropping reified generics? I don't think you'd find too many Java devs that think type erasure in Java is a positive. I always felt it made generics feel cobbled on in Java

2/ Like the metaclasses.

3/ I prefer the type annotations on the right but think this would be such a massive breaking change as to be impractical without tooling to convert existing code.

4/ constructor initialisation lists

I'm in 2 minds about this. On the one hand I like the separation between setting properties and the constructor body executing.

On the other hand I'm OC with immutable properties and minimise the use of factory constructors as they can't be called by subclasses.

This combination can lead to an explosion of constructors that chain together which gets ugly.


4b/ If you propose getting rid of const does that mean you propose removing annotations?

5/ I no longer use parts and see no great value in them.

6/ Given 4/ above you won't be surprised to learn that I LOVE final by default.
Non null and immutable by default == me very happy

7/ Like Uniformity of reference too. One thing I really liked about Eiffel when I played with it many many moons ago

[Günter Zöchbauer]

+1 *Static checking for dropped futures*
"_" should not cause unused variable hints anywhere (not only in arguments)
Doesn't work for inline calls though `print(asyncCall())`

*Reified generics*
I don't know the consequences but since Patrice explained to me that
`<TypeA,TypeB>{}` is not the same than `new Map<TypeA,TypeB>()` I don't
like reified generics much.

*Type tests*

while Objectautomatically gets one that returns false

I would expect object always to return `true` not `false`

*Type annotations on the right*
I'm not used to this style (never really developed in a language with this
style)
I feels quite cumbersome. Especially that `var` is necessary in addition to
the type everywhere.
Something like
var {
a : int;
b : String;
}
would easy this pain a lot.
This might even be a solution for (or instead of) final by default
var {
a: int;
b: String;
}

final {
c: num;
d: bol;
}

This is meant in addition to
var a: int;
not instead of.

*+10 Constructor initialization lists*
for moving `super` into the constructor block and treat the statements
before `super` like the initializer list but more powerful.

*Parts*
In my main project I use parts a lot but I could live without it.
I want to ensure private members are accessible within the code in the
whole library but the library is way to big for one file.
I don't care much about preventing developers accessing my private members
but the classes are quite complex and I don't want all of the internal
members to clutter the autocompletion list of developers.
Some scope name, where the members are listed when the caller is in the
same scope, would do it for me. The scope could be the library name if it
is allowed to load more than one file with the same library name or maybe
some declaration in addition to `library`;
I also would like a way to indicate that a member is "protected" (public
but should only be referenced from subclasses). Here also I mostly care
about the autocompletion list. A hint from the analyzer would be nice as
well for violations though.

+5 *Fields final by default*
See also my comment above about "*Type annotations on the right"*
I'm in favor for "final by default" but not only for fields
but *especially for function/method parameters*
and also for local variables.

*Remove break, continue, and labels in favor of non-local returns*
I don't need break, continue a lot and an if usually is enough for a
workaround but ugly.
Would be nice to hear more about the consequences
(advantages/disadvantages/alternative approaches).
AFAIK this is required for tail recursion which would allow Dart to perform
better in functional style programming.

*Assert*
One advantage of assert is that it has no runtime cost in production code.
I see this more like an inline unit test and "active" documentation of
intent.
I'm +5 for contracts or similar expressive ways but this might cost to much
performance for production.
But some checks should be active in production for input validation.

+5 for expressive checks/validation
+3 for still being able to define which checks should be executed only in
checked mode.


*Uniformity of reference*
I guess this would be harder to swallow than type annotations on the right.
How to differentiate between calling a function referenced by a field and
getting the reference to the function?

+1 *Removing new*
I don't care too much, but I find it often cumbersome to differentiate
between static methods returning an instance and (factory) constructors.
If `const` goes away `new` definitely has to go as well.

https://github.com/dart-lang/dart_enhancement_proposals/blob/master/Meetings/2015-09-02%20Language%20Meeting.md
I mention this in the notes, but I want to call it out here. We're
starting to discuss this vague notion of "Dart 2.0". We don't know what
that means yet, and that means we'll be talking about all kinds of crazy
radical ideas which may or may not come to pass.
I think it's really important for us to speak freely, and it's also
important to do this in the open so we can involve all of you. But the cost
is that you may hear ideas that seem scary or disruptive, or ideas that
sound awesome but don't pan out. Try not to freak out and understand that
we're just brainstorming at this point.
Cheers!
- bob

['Lasse R.H. Nielsen' via Dart Misc]

Post by Günter Zöchbauer
*Reified generics*
I don't know the consequences but since Patrice explained to me that
`<TypeA,TypeB>{}` is not the same than `new Map<TypeA,TypeB>()` I don't
like reified generics much.

I would like to see that explanation - it should be exactly the same.

Post by Günter Zöchbauer
*Type tests*

while Objectautomatically gets one that returns false

I would expect object always to return `true` not `false`

If the "is" method is on the object and takes the type as argument, then
the default method should use the type of the current object and see if it
implements the type represented by the argument. It should neither return
always true or always false.

I'd do:
bool operator is(Type type)
with a default that does exactly what "obj is TypeName" does now. The only
difference is that you can override it. The disadvantage is that now type
checks can have side-effects, including throwing.

Post by Günter Zöchbauer
*Type annotations on the right*
I'm not used to this style (never really developed in a language with this
style)
I feels quite cumbersome. Especially that `var` is necessary in addition
to the type everywhere.
Something like
var {
a : int;
b : String;
}
would easy this pain a lot.

var a: int = 42, b: String = "foo";

That seems like a direct extension of current syntax that I'd expect to
just work.

Post by Günter Zöchbauer
This might even be a solution for (or instead of) final by default
var {
a: int;
b: String;
}
final {
c: num;
d: bol;
}
This is meant in addition to
var a: int;
not instead of.
*+10 Constructor initialization lists*
for moving `super` into the constructor block and treat the statements
before `super` like the initializer list but more powerful.

But whyyy?!?

Having something that looks like normal code inside the body of the
constructor, but with some non-obvious restrictions, and then a super call
that looks like a super method call (in case of a named constructor), it's
going to be practically invisible that something different is going on.

I think initializer lists are great, and very, very readable.

Post by Günter Zöchbauer
*Uniformity of reference*
I guess this would be harder to swallow than type annotations on the right.
How to differentiate between calling a function referenced by a field and
getting the reference to the function?

Good point. If the "()" is optional, then you can call a nullary function
both as a getter "x.foo" and as a function "x.foo()". That means you have
two ways to write the same thing, which is not great. It makes "x.foo()"
ambiguous - is it calling a nullary function with no arguments and then
calling the result, or is it just calling a nullary function.
It'll likely be disambiguated to mean calling the method with no arguments,
and then you have to write (x.foo)() to call the result of a getter.

Also, should you be allowed to pass zero arguments to a getter?

Post by Günter Zöchbauer
+1 *Removing new*
I don't care too much, but I find it often cumbersome to differentiate
between static methods returning an instance and (factory) constructors.
If `const` goes away `new` definitely has to go as well.

+5.
It's still not perfect - a generative constructor is different from any
other member because it's necessary for extending a class.

Maybe we should drop "extends" from the language, and replace it with
auto-delegation.

Instead of "class C extends D { something(); }" you do:
class C implements D as _d {
final D _d;
something();
}
which automatically adds delegates for all members on D to call the same
method on _d.

Then you don't need to have publicly visible generative constructors at all.

/L
--
Lasse R.H. Nielsen - ***@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

[Günter Zöchbauer]

On Friday, September 4, 2015 at 10:35:43 AM UTC+2, Lasse Reichstein Holst

Post by 'Lasse R.H. Nielsen' via Dart Misc

Post by Günter Zöchbauer
*Reified generics*
I don't know the consequences but since Patrice explained to me that
`<TypeA,TypeB>{}` is not the same than `new Map<TypeA,TypeB>()` I don't
like reified generics much.

I would like to see that explanation - it should be exactly the same.

It's quite some time back, I guess it was a discussion on some Angular
issue.
AFAIR he mentioned `<TypeA,TypeB>{}` doesn't doesn't reify generic
arguments. If you say it's the same I believe you of course ;-) and will
have a better rest at night from now on.

Post by 'Lasse R.H. Nielsen' via Dart Misc

Post by Günter Zöchbauer
*Type tests*

while Objectautomatically gets one that returns false

I would expect object always to return `true` not `false`

If the "is" method is on the object and takes the type as argument, then
the default method should use the type of the current object and see if it
implements the type represented by the argument. It should neither return
always true or always false.

I see, didn't think it through properly. Thanks for clarification.

Post by 'Lasse R.H. Nielsen' via Dart Misc
bool operator is(Type type)
with a default that does exactly what "obj is TypeName" does now. The only
difference is that you can override it. The disadvantage is that now type
checks can have side-effects, including throwing.

Post by Günter Zöchbauer
*Type annotations on the right*
I'm not used to this style (never really developed in a language with
this style)
I feels quite cumbersome. Especially that `var` is necessary in addition
to the type everywhere.
Something like
var {
a : int;
b : String;
}
would easy this pain a lot.

var a: int = 42, b: String = "foo";
That seems like a direct extension of current syntax that I'd expect to
just work.

Post by Günter Zöchbauer
This might even be a solution for (or instead of) final by default
var {
a: int;
b: String;
}
final {
c: num;
d: bol;
}
This is meant in addition to
var a: int;
not instead of.
*+10 Constructor initialization lists*
for moving `super` into the constructor block and treat the statements
before `super` like the initializer list but more powerful.

But whyyy?!?
Having something that looks like normal code inside the body of the
constructor, but with some non-obvious restrictions, and then a super call
that looks like a super method call (in case of a named constructor), it's
going to be practically invisible that something different is going on.
I think initializer lists are great, and very, very readable.

The `super` would be distinguishing enough for me. I'd prefer to have
initialization code within a normal code block. I don't find initializer
list readable at all. To me it's a weird form to organize code which is
used nowhere else, and being able to use control structures like in normal
code would be nice.

I'm not super happy with the non-obvious restrictions above `super`. I was
thinking about another block instead like

class SomeClass {
SomeClass() {
// initalize finals here;
}
super() {
// further initialization
}
}

a while back, but wasn't super happy with this either.

Another idea:

class SomeClass {
SomeClass() {
final {
// initalize finals here;
}
super();
// further initialization
}
}

I just use `final` here because this is what I usually use initializer
lists for and I guess some keyword would be necessary to make its intent
clear.

I changed the scale of +x before I sent the mail and forgot to update it
for this point.
Should be *+2* instead of +10 to fit with the others. Seems I'm not yet
fully awake.

Post by 'Lasse R.H. Nielsen' via Dart Misc

Post by Günter Zöchbauer
*Uniformity of reference*
I guess this would be harder to swallow than type annotations on the right.
How to differentiate between calling a function referenced by a field and
getting the reference to the function?

Good point. If the "()" is optional, then you can call a nullary function
both as a getter "x.foo" and as a function "x.foo()". That means you have
two ways to write the same thing, which is not great. It makes "x.foo()"
ambiguous - is it calling a nullary function with no arguments and then
calling the result, or is it just calling a nullary function.
It'll likely be disambiguated to mean calling the method with no
arguments, and then you have to write (x.foo)() to call the result of a
getter.

I guess "x.foo()" would be fine. It is not really possible to disguise a
field referencing a function as a function anyway (for example for a user
of an API from within it's IDE).
I use this for example for default Grinder tasks where I can configure the
default behavior by passing different functions to fields (the
tasks-functions are acquired by Grinder using mirrors which limits the
options a bit).
But the functions are only called by my internal implementation anyway
which knows they are fields holding functions.

I really like the distinction between `xxx()` do something (even expensive,
and eventually return some result) and `xxx` give me the value you're
holding (even when behind the scenes it might do a bit more than just that).
I think without `()` it would be much harder to interpret code.

Also, should you be allowed to pass zero arguments to a getter?

Post by 'Lasse R.H. Nielsen' via Dart Misc

Post by Günter Zöchbauer
+1 *Removing new*
I don't care too much, but I find it often cumbersome to differentiate
between static methods returning an instance and (factory) constructors.
If `const` goes away `new` definitely has to go as well.

+5.
It's still not perfect - a generative constructor is different from any
other member because it's necessary for extending a class.
Maybe we should drop "extends" from the language, and replace it with
auto-delegation.
class C implements D as _d {
final D _d;
something();
}
which automatically adds delegates for all members on D to call the same
method on _d.
Then you don't need to have publicly visible generative constructors at all.

Doesn't look too bad, but my imagination doesn't reach far enough to see
how this would work out in different scenarios. You seem to be really adventurous
:)

Post by 'Lasse R.H. Nielsen' via Dart Misc
/L
--
'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

[Patrice Chalin]

Post by Günter Zöchbauer
On Friday, September 4, 2015 at 10:35:43 AM UTC+2, Lasse Reichstein Holst

Post by 'Lasse R.H. Nielsen' via Dart Misc

Post by Günter Zöchbauer
*Reified generics*
I don't know the consequences but since Patrice explained to me that
`<TypeA,TypeB>{}` is not the same than `new Map<TypeA,TypeB>()` I don't
like reified generics much.

I would like to see that explanation - it should be exactly the same.

It's quite some time back, I guess it was a discussion on some Angular
issue.
AFAIR he mentioned `<TypeA,TypeB>{}` doesn't doesn't reify generic
arguments. If you say it's the same I believe you of course ;-) and will
have a better rest at night from now on.

I'm afraid I may have been misunderstood at the time. For the record, the
discussion we had concerning the Angular Dart code base was about
declarations of the form:

Map<A,B> m = {}

vs


Map<A,B> m = <A,B>{}

My statement was that the type arguments to {} are necessary if you don't
want to end up with a runtime type of Map<dynamic,dynamic>. Some developers
objected to the apparent need to unnecessarily "repeat" the type arguments
when in fact they serve different purposes on the LHS vs. RHS. The type
arguments on the LHS are part of the (optional) static type annotation
whereas on the RHS they are part of the runtime call to the Map constructor.

Cheers,
Patrice

[Günter Zöchbauer]

In this case this makes sense of course.

I was quite confused about Dart type annotations back then - even more than
now ;-)
Thanks for clarification and sorry for accusing you of making invalid
statements!

I remember this discussion every time I write {}. Glad this finally is
resolved :)

Cheers,
GÃŒnter

Mit freundlichen GrÌßen

GÌnter Zöchbauer
***@gzoechbauer.com
[phone]

Post by Patrice Chalin

Post by Günter Zöchbauer
On Friday, September 4, 2015 at 10:35:43 AM UTC+2, Lasse Reichstein Holst

Post by 'Lasse R.H. Nielsen' via Dart Misc

Post by Günter Zöchbauer
*Reified generics*
I don't know the consequences but since Patrice explained to me that
`<TypeA,TypeB>{}` is not the same than `new Map<TypeA,TypeB>()` I don't
like reified generics much.

I would like to see that explanation - it should be exactly the same.

It's quite some time back, I guess it was a discussion on some Angular
issue.
AFAIR he mentioned `<TypeA,TypeB>{}` doesn't doesn't reify generic
arguments. If you say it's the same I believe you of course ;-) and will
have a better rest at night from now on.

I'm afraid I may have been misunderstood at the time. For the record, the
discussion we had concerning the Angular Dart code base was about
Map<A,B> m = {}
vs
Map<A,B> m = <A,B>{}
My statement was that the type arguments to {} are necessary if you don't
want to end up with a runtime type of Map<dynamic,dynamic>. Some developers
objected to the apparent need to unnecessarily "repeat" the type arguments
when in fact they serve different purposes on the LHS vs. RHS. The type
arguments on the LHS are part of the (optional) static type annotation
whereas on the RHS they are part of the runtime call to the Map constructor.
Cheers,
Patrice

[Patrice Chalin]

... I was quite confused about Dart type annotations back then - even more
than now ;-)
Thanks for clarification and sorry for accusing you of making invalid
statements!

No worries. Dart is quite novel in its support for optional types and
reified generics and, after years of programming in, say, Java, it takes
some conscious effort at times to remind ourselves of the differences.

Cheers,
Patrice

['Brian Wilkerson' via Dart Misc]

Re: Fields final by default

I would be curious to know what percentage of fields (in existing code
bases) are:
- explicitly marked as final
- implicitly treated like they were final
- not final

I know that we cannot get an accurate measure for the second item, but
perhaps we could get a proxy for it, such as only including library private
fields that are only assigned once.

Has anyone measured this?

Brian

[Rasmus Eneman]

On Fri, Sep 4, 2015 at 5:37 PM, 'Brian Wilkerson' via Dart Core Development

Post by 'Brian Wilkerson' via Dart Misc
Re: Fields final by default
I would be curious to know what percentage of fields (in existing code
- explicitly marked as final
- implicitly treated like they were final
- not final
I know that we cannot get an accurate measure for the second item, but
perhaps we could get a proxy for it, such as only including library private
fields that are only assigned once.
Has anyone measured this?
Brian
--
You received this message because you are subscribed to the Google Groups
"Dart Core Development" group.
To unsubscribe from this group and stop receiving emails from it, send an

Based on data from the 600 Dart repos with most stars on Github only 6,3%
of all variables are declared as final and only 2,4% as const.
--
Rasmus Eneman

[kc]

On Friday, September 4, 2015 at 9:35:43 AM UTC+1, Lasse Reichstein Holst

Post by 'Lasse R.H. Nielsen' via Dart Misc
Maybe we should drop "extends" from the language, and replace it with
auto-delegation.
class C implements D as _d {
final D _d;
something();
}
which automatically adds delegates for all members on D to call the same
method on _d.
Then you don't need to have publicly visible generative constructors at all.

This more compositional approach looks interesting. There has been a turn
against trad OO hierarchies.

K.

Post by 'Lasse R.H. Nielsen' via Dart Misc
/L
--
'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

[Robert Åkerblom-Andersson]

*Type annotations on the right*

I think that if Dart 2.0 would go in that direction, would the ":" really
be needed? I know Go is a different language in many ways but it works for
them...

Yes, I do understand that it's easier to parse of course, but I feel that
it could be parsed without the ":" as well... I can see that the "function
as a variable" example might benefit from the ":" for better readability,
but for variables (that are way more common), I find it somewhat in the
way. It looks almost cumbersome to add types because of the extra typing, I
might grow to like it, I don't know, but I don't really like looking at it
right now..

I would not go as far as to say that I "HATE HATE HATE this" hehe, but I
agree that it does look almost plain weird for normal vars and I think it
would be off putting to a lot of devs... Some of you core language people
might not really see this as you guys have seen so many different syntaxes,
it's not that different if you have seen it before yourself, but lots of
devs have never ever seen this type of syntax, where as I feel "just moving
the type to the right" is a lot less unfamiliar. Sure any dev could get
used to it, but Dart right now wants to add lots of new users not just
adapt the existing ones...

As alternatives, while still keeping type annotations on the right (I think
that alone is okay) I can think of three different ways to do it:

1. Simply remove the ":"
2. Make the ":" optional, then it can be added where needed for readability
(like the function case) but not for simple String and int vars
3. Make the ":" required only for function variables, I know adding special
cases might not be the "right way" in some sense, but it could maybe be a
compromise worth doing in this case

Something that was not mentioned in this meeting but that I read about
earlier, was the idea of maybe making ";" optional. I think it was Bob that
said basically that removing them completely might be a too big breaking
change, but making them optional could be done since existing code would
not break.

I feel that there are a lot of similarities between the existing use of ";"
and the proposed used of ":". It feels like both are added mostly to make
parsing easier, while the truth is that the code could still be parsed
quite good without them. I might be wrong, but it almost feel like a
premature optimization considering how fast computers are today (no offense
intended, I do way too much premature optimization myself as well).

I think the idea of making both ";" and ":" optional could be worth
considering as it would be simple to explain and understand... You can add
them if you want for readability where needed or simply not use them at
all. I understand the drawback of making something optional, it's not as
"clean", but in this case I feel the compromise might be worth more to
existing and new Dart developers.


*Removing new*

Yes, I was previously against this but after thinking some more and looking
at examples I have switched over to the "yes camp". I now feel it would be
a nice change if it was removed.

Post by 'Bob Nystrom' via Dart Misc
https://github.com/dart-lang/dart_enhancement_proposals/blob/master/Meetings/2015-09-02%20Language%20Meeting.md
I mention this in the notes, but I want to call it out here. We're
starting to discuss this vague notion of "Dart 2.0". We don't know what
that means yet, and that means we'll be talking about all kinds of crazy
radical ideas which may or may not come to pass.
I think it's really important for us to speak freely, and it's also
important to do this in the open so we can involve all of you. But the cost
is that you may hear ideas that seem scary or disruptive, or ideas that
sound awesome but don't pan out. Try not to freak out and understand that
we're just brainstorming at this point.
Cheers!
- bob

[Günter Zöchbauer]

On Friday, September 4, 2015 at 11:07:10 AM UTC+2, Robert

Post by Matthew Butler
*Type annotations on the right*
I think that if Dart 2.0 would go in that direction, would the ":" really
be needed? I know Go is a different language in many ways but it works for
them...
Yes, I do understand that it's easier to parse of course, but I feel that
it could be parsed without the ":" as well... I can see that the "function
as a variable" example might benefit from the ":" for better readability,
but for variables (that are way more common), I find it somewhat in the
way. It looks almost cumbersome to add types because of the extra typing, I
might grow to like it, I don't know, but I don't really like looking at it
right now..
I would not go as far as to say that I "HATE HATE HATE this" hehe, but I
agree that it does look almost plain weird for normal vars and I think it
would be off putting to a lot of devs... Some of you core language people
might not really see this as you guys have seen so many different syntaxes,
it's not that different if you have seen it before yourself, but lots of
devs have never ever seen this type of syntax, where as I feel "just moving
the type to the right" is a lot less unfamiliar. Sure any dev could get
used to it, but Dart right now wants to add lots of new users not just
adapt the existing ones...

While I have don't have a strong opinion for any way on this topic, from
many comments I saw, types on the left are hated by a lot of people not
coming from C-style languages. Can't say which side has more haters of the
"other side" though.

Post by Matthew Butler
As alternatives, while still keeping type annotations on the right (I
1. Simply remove the ":"
2. Make the ":" optional, then it can be added where needed for
readability (like the function case) but not for simple String and int vars
3. Make the ":" required only for function variables, I know adding
special cases might not be the "right way" in some sense, but it could
maybe be a compromise worth doing in this case
Something that was not mentioned in this meeting but that I read about
earlier, was the idea of maybe making ";" optional. I think it was Bob that
said basically that removing them completely might be a too big breaking
change, but making them optional could be done since existing code would
not break.
I feel that there are a lot of similarities between the existing use of
";" and the proposed used of ":". It feels like both are added mostly to
make parsing easier, while the truth is that the code could still be parsed
quite good without them. I might be wrong, but it almost feel like a
premature optimization considering how fast computers are today (no offense
intended, I do way too much premature optimization myself as well).
I think the idea of making both ";" and ":" optional could be worth
considering as it would be simple to explain and understand... You can add
them if you want for readability where needed or simply not use them at
all. I understand the drawback of making something optional, it's not as
"clean", but in this case I feel the compromise might be worth more to
existing and new Dart developers.
*Removing new*
Yes, I was previously against this but after thinking some more and
looking at examples I have switched over to the "yes camp". I now feel it
would be a nice change if it was removed.

Post by 'Bob Nystrom' via Dart Misc
https://github.com/dart-lang/dart_enhancement_proposals/blob/master/Meetings/2015-09-02%20Language%20Meeting.md
I mention this in the notes, but I want to call it out here. We're
starting to discuss this vague notion of "Dart 2.0". We don't know what
that means yet, and that means we'll be talking about all kinds of crazy
radical ideas which may or may not come to pass.
I think it's really important for us to speak freely, and it's also
important to do this in the open so we can involve all of you. But the cost
is that you may hear ideas that seem scary or disruptive, or ideas that
sound awesome but don't pan out. Try not to freak out and understand that
we're just brainstorming at this point.
Cheers!
- bob

[Benjamin Strauß]

*Reified generics*

I actually like this feature although i don't use it very often. So i guess
i won't miss it.

*Type annotations on the right*

I'm ok with this. Used ActionScript for years and recently started writing
TypeScript code. The ':' is one more button to push but i think it's more
readable.

*Static methods / meta classes*

Yes please! Leaning more towards metaclasses is always the right choice.

*Constructor initialization lists*

Never really used this just like *const*. Both can go away.

*Parts*

Completely useless in my opinion. Just use 'export'.

*Prefixes / implied first class libraries*

First class all the way!

*Symbols*

Again rarely used.

*Fields final by default*

I'm in.

*Remove break, continue, and labels in favor of non-local returns*

How about a compromise? Keep break, continue and labels but also add
non-local returns. Users who would like to use them, could use them.

// normal return
return 'foo';

// non-local return
^return 'foo';

*Uniformity of reference*

I'm not sure how usefull this is in a language without mixfix notation.
This has been mentioned before, but wouldn't this interfere with method
extraction?

*Removing new*

Yes please, my first reacting was against this. But now i'm all in.


*conclusion:*

I feel like these new meetings are going forward in the right direction.
Don't hesitate to innovate and take risks!

Post by 'Bob Nystrom' via Dart Misc
https://github.com/dart-lang/dart_enhancement_proposals/blob/master/Meetings/2015-09-02%20Language%20Meeting.md
I mention this in the notes, but I want to call it out here. We're
starting to discuss this vague notion of "Dart 2.0". We don't know what
that means yet, and that means we'll be talking about all kinds of crazy
radical ideas which may or may not come to pass.
I think it's really important for us to speak freely, and it's also
important to do this in the open so we can involve all of you. But the cost
is that you may hear ideas that seem scary or disruptive, or ideas that
sound awesome but don't pan out. Try not to freak out and understand that
we're just brainstorming at this point.
Cheers!
- bob

[Mike]

Thanks for that interesting post Bob. Lots of nice-to-have ideas spring to
mind! My preferences would be:

Types on right: No - keep them like they are please! For me "final pi :
int = 3" is hard to parse. But also, I don't really see the benefit that
would justify this change.
Parts: I agree that they don't bring a lot to the language.
String v string: I would capitalise int, bool etc.
Final by default: No.
Removing new: No.
More radical ideas like dropping optional types: No.


*But what about ... (yes I know some of this is just syntax)*

More useful isolates e.g. ones that can take and return objects by value.
Nested classes
More useful Enums (by which I mean ability to add values like
print(myEnum.ThirdPlanet); //earth
Tuples.
Functions able to return more than one result.
Ability to choose whether function parameters should be passed by value or
reference.
Ability to initialise class members from class functions (not just from
class constructors)
Structs.
Multi-dimensional array syntax (i.e. var myArray = new Array<int>(5,3);)

*Syntax tidy up:*

Swift's code looks cleaner than Dart's and avoids clutter. Notably, it
avoids semi-colons and doesn't use round brackets in for loops, switch
statements and if blocks. Swift also has some nice syntax sugar e.g. you
can say "for n in 0..<10 {" which in Dart is "for (int n=0;n<10;n++) {"

Any chance of some of that goodness?

*Nothing to do with Dart 2.0:*

Dart Editor: Why, oh why? What I really like about Dart is how easy it is
to use. Dropping Dart Editor (which I still use) was a mistake, in my
view. It was a great, free, easy to install and use, IDE and fantastic for
introducing people to the language. It improved hugely since it was first
introduced, to the point where I find it a pleasure to use. I have tried
Atom and Intellij CE but Atom doesn't run programs and Intellij CE is
overkill for what I want. Maybe Atom will become the answer - I hope so.

Post by 'Bob Nystrom' via Dart Misc
https://github.com/dart-lang/dart_enhancement_proposals/blob/master/Meetings/2015-09-02%20Language%20Meeting.md
I mention this in the notes, but I want to call it out here. We're
starting to discuss this vague notion of "Dart 2.0". We don't know what
that means yet, and that means we'll be talking about all kinds of crazy
radical ideas which may or may not come to pass.

['Bob Nystrom' via Dart Misc]

Post by Mike
More useful Enums (by which I mean ability to add values like
print(myEnum.ThirdPlanet); //earth

This comes up a lot. I would definitely like to do something better here.

Post by Mike
Swift's code looks cleaner than Dart's and avoids clutter. Notably, it
avoids semi-colons and doesn't use round brackets in for loops, switch
statements and if blocks. Swift also has some nice syntax sugar e.g. you
can say "for n in 0..<10 {" which in Dart is "for (int n=0;n<10;n++) {"
Any chance of some of that goodness?

I would be happy to see semicolons be optional in Dart. Most modern
languages don't require them. Other syntax changes related to core
statement forms are less likely. I think we get a lot of value out of
sticking with the imperative statements users are familiar with from
C/C++/JS/Java/C# and I don't think tweaking them adds *that* much value.

Now, adding new interesting statements is a different story. But for the
for(), while(), and if() stuff users know and love, I think there's real
value in familiarity.

Cheers!

- bob

[Daniel Joyce]

Well, if you liked the Dart Editor, the dartlang plugin for Atom is
becoming very nice and stable. Its much smoother than the eclipse based
ide, and has lots of other useful tools you can install.

On Thu, Sep 10, 2015 at 12:52 PM 'Bob Nystrom' via Dart Misc <

Post by 'Bob Nystrom' via Dart Misc

Post by Mike
More useful Enums (by which I mean ability to add values like
print(myEnum.ThirdPlanet); //earth

This comes up a lot. I would definitely like to do something better here.

Post by Mike
Swift's code looks cleaner than Dart's and avoids clutter. Notably, it
avoids semi-colons and doesn't use round brackets in for loops, switch
statements and if blocks. Swift also has some nice syntax sugar e.g. you
can say "for n in 0..<10 {" which in Dart is "for (int n=0;n<10;n++) {"
Any chance of some of that goodness?

I would be happy to see semicolons be optional in Dart. Most modern
languages don't require them. Other syntax changes related to core
statement forms are less likely. I think we get a lot of value out of
sticking with the imperative statements users are familiar with from
C/C++/JS/Java/C# and I don't think tweaking them adds *that* much value.
Now, adding new interesting statements is a different story. But for the
for(), while(), and if() stuff users know and love, I think there's real
value in familiarity.
Cheers!
- bob
--
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

--
Daniel Joyce

The meek shall inherit the Earth, for the brave will be among the stars.

[tatumizer-v0.2]

"for n in 0..<10"

Why not just
for (int n<10) {...}

The case is very common; if something deserves special syntax, this is the
first candidate. Will become an instant hit.
Current syntax (borrowed all the way from C) is error-prone, especially if
you have nested "for" loops: you copy&paste the first one and forget to
change i to j somewhere.
When you (rarely) need a general case, use full syntax - it will also serve
as indication that something unusual is going on here.

:

['Lasse R.H. Nielsen' via Dart Misc]

Post by 'Lasse R.H. Nielsen' via Dart Misc

"for n in 0..<10"

Why not just
for (int n<10) {...}
The case is very common; if something deserves special syntax, this is the
first candidate. Will become an instant hit.

I'd introduce ranges instead, then you could write:
for (int n in [:10]) { ... }
A "range expression" is [ expr_opt : expr_opt ] and it evaluates to an
iterable counting from the first value to (but not including) the last
value. Omitting the first defaults to 0 and omitting the last generates an
iterable counting towards infinity.
The compiler can recognize it when used as a literal in cases like this and
generate a normal for loop.

(But then, I'd introduce operator[:] as well and use that as a lazy
sublist/substring - and make the string version an efficient slice that
doesn't copy unnecessarily, that would allow us to not pass "start, end"
every place we want to pass a substring without creating the intermediate
value).

Post by 'Lasse R.H. Nielsen' via Dart Misc
Current syntax (borrowed all the way from C) is error-prone, especially if
you have nested "for" loops: you copy&paste the first one and forget to
change i to j somewhere.
When you (rarely) need a general case, use full syntax - it will also
serve as indication that something unusual is going on here.

I can sympathize with that. If you have large idiomatic code sequences,
then a shorthand makes sense.
for (int i = 0; i < x.length; i++) { }
is a prime example.

/L
--
Lasse R.H. Nielsen - ***@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

[Günter Zöchbauer]

I'm in :)

On Friday, September 11, 2015 at 8:08:02 AM UTC+2, Lasse Reichstein Holst

Post by 'Lasse R.H. Nielsen' via Dart Misc

Post by 'Lasse R.H. Nielsen' via Dart Misc

"for n in 0..<10"

Why not just
for (int n<10) {...}
The case is very common; if something deserves special syntax, this is
the first candidate. Will become an instant hit.

for (int n in [:10]) { ... }
A "range expression" is [ expr_opt : expr_opt ] and it evaluates to an
iterable counting from the first value to (but not including) the last
value. Omitting the first defaults to 0 and omitting the last generates an
iterable counting towards infinity.
The compiler can recognize it when used as a literal in cases like this
and generate a normal for loop.
(But then, I'd introduce operator[:] as well and use that as a lazy
sublist/substring - and make the string version an efficient slice that
doesn't copy unnecessarily, that would allow us to not pass "start, end"
every place we want to pass a substring without creating the intermediate
value).

Post by 'Lasse R.H. Nielsen' via Dart Misc
Current syntax (borrowed all the way from C) is error-prone, especially
if you have nested "for" loops: you copy&paste the first one and forget to
change i to j somewhere.
When you (rarely) need a general case, use full syntax - it will also
serve as indication that something unusual is going on here.

I can sympathize with that. If you have large idiomatic code sequences,
then a shorthand makes sense.
for (int i = 0; i < x.length; i++) { }
is a prime example.
/L
--
'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

[Anders Holmgren]

+1

Post by Günter Zöchbauer
I'm in :)
On Friday, September 11, 2015 at 8:08:02 AM UTC+2, Lasse Reichstein Holst

Post by 'Lasse R.H. Nielsen' via Dart Misc

Post by 'Lasse R.H. Nielsen' via Dart Misc

"for n in 0..<10"

Why not just
for (int n<10) {...}
The case is very common; if something deserves special syntax, this is
the first candidate. Will become an instant hit.

for (int n in [:10]) { ... }
A "range expression" is [ expr_opt : expr_opt ] and it evaluates to an
iterable counting from the first value to (but not including) the last
value. Omitting the first defaults to 0 and omitting the last generates an
iterable counting towards infinity.
The compiler can recognize it when used as a literal in cases like this
and generate a normal for loop.
(But then, I'd introduce operator[:] as well and use that as a lazy
sublist/substring - and make the string version an efficient slice that
doesn't copy unnecessarily, that would allow us to not pass "start, end"
every place we want to pass a substring without creating the intermediate
value).

Post by 'Lasse R.H. Nielsen' via Dart Misc
Current syntax (borrowed all the way from C) is error-prone, especially
if you have nested "for" loops: you copy&paste the first one and forget to
change i to j somewhere.
When you (rarely) need a general case, use full syntax - it will also
serve as indication that something unusual is going on here.

I can sympathize with that. If you have large idiomatic code sequences,
then a shorthand makes sense.
for (int i = 0; i < x.length; i++) { }
is a prime example.
/L
--

'Faith without judgement merely degrades the spirit divine'

Post by 'Lasse R.H. Nielsen' via Dart Misc
Google Denmark ApS - Frederiksborggade 20B, 1 sal - 1360 KÞbenhavn K
- Denmark - CVR nr. 28 86 69 84

--
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

[Andrew Skalkin]

Post by 'Lasse R.H. Nielsen' via Dart Misc
Why not just
for (int n<10) {...}

+1. This will make 99% of the "traditional" for loops much easier to read
and write.

[tatumizer-v0.2]

WRT "parts": FWIW, I think the problem was originally misdiagnosed. Access
to private variables of another library is often necessary. "part" feature
tries to address this, but it's too restrictive, so it doesn't really solve
the problem.
When libraries x and y reside in the same package, there's no justification
for imposing draconian restrictions on what each of them can see in a
sibling library.
Maybe this should require special "show" clause in import statement like:
import "my_sibling.dart" show _foo,_bar

BTW, we discussed this problem a couple of times on this forum already.
Some ugly workarounds were mentioned as possible solutions.



.

[Günter Zöchbauer]

Dart doesn't have a notion of "package", "package" is from pub instead.
I think there was something like `fried` mentioned recently.
IMHO it would be a good solution to declare in one library which other
libraries should be able to see private members (be a fried library). This
would make part redundant.
It would also fix the problem that unit tests can't access private members
which would be convenient for TDD.

Post by tatumizer-v0.2
WRT "parts": FWIW, I think the problem was originally misdiagnosed. Access
to private variables of another library is often necessary. "part" feature
tries to address this, but it's too restrictive, so it doesn't really solve
the problem.
When libraries x and y reside in the same package, there's no
justification for imposing draconian restrictions on what each of them can
see in a sibling library.
import "my_sibling.dart" show _foo,_bar
BTW, we discussed this problem a couple of times on this forum already.
Some ugly workarounds were mentioned as possible solutions.
.

[tatumizer-v0.2]

Post by Günter Zöchbauer
Dart doesn't have a notion of "package", "package" is from pub instead.

Effectively, there's a notion of package anyway. E.g. latest proposal on
"packages" config deals with instructions to compiler on how to locate ...
what?.

[Günter Zöchbauer]

That's only for interpreting package uris but you are right, there might be only a small step in using this to check whether two libs are in the same package at least as long as a package uri is used in the import.

Dart doesn't have a notion of "package", "package" is from pub instead. 

Effectively, there's a notion of package anyway. E.g. latest proposal on "packages" config deals with instructions to compiler on how to locate ... what?.

['Lasse R.H. Nielsen' via Dart Misc]

Post by tatumizer-v0.2

Post by Günter Zöchbauer
Dart doesn't have a notion of "package", "package" is from pub instead.

Effectively, there's a notion of package anyway. E.g. latest proposal on
"packages" config deals with instructions to compiler on how to locate ...
what?.

Dart doesn't have the notion of "same package". It resolves package: URIs
to something and loads the individual libraries, but it doesn't have a
concept of things being in the same package or not. That is, it doesn't
know what "a package" is, just that there is "something package related"
that it can load.

It's not hard to add - it's just checking whether the first path segment is
the same - so if it makes sense to add some kind of "package privacy" to
Dart, then it's definitely doable. It's just not necessarily a very good
design since it only works for packages, it depends on *how* a file is
imported (using a file: reference to a Dart file instead of a package:
reference would make things break?), and not all Dart files come from
packages (for example the dart: platform libraries don't).

A shared private namespace might make sense, but I don't think only
applying it to packages is a good idea.

/L 'And I want "protected" first!'
--
Lasse R.H. Nielsen - ***@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

[Günter Zöchbauer]

On Monday, September 14, 2015 at 9:08:46 AM UTC+2, Lasse Reichstein Holst

Post by 'Lasse R.H. Nielsen' via Dart Misc

Post by tatumizer-v0.2

Post by Günter Zöchbauer
Dart doesn't have a notion of "package", "package" is from pub instead.

Effectively, there's a notion of package anyway. E.g. latest proposal on
"packages" config deals with instructions to compiler on how to locate ...
what?.

Dart doesn't have the notion of "same package". It resolves package: URIs
to something and loads the individual libraries, but it doesn't have a
concept of things being in the same package or not. That is, it doesn't
know what "a package" is, just that there is "something package related"
that it can load.
It's not hard to add - it's just checking whether the first path segment
is the same - so if it makes sense to add some kind of "package privacy" to
Dart, then it's definitely doable. It's just not necessarily a very good
design since it only works for packages, it depends on *how* a file is
reference would make things break?), and not all Dart files come from
packages (for example the dart: platform libraries don't).
A shared private namespace might make sense, but I don't think only
applying it to packages is a good idea.
/L 'And I want "protected" first!'

Great to hear you want this, so there is still hope :)

Post by 'Lasse R.H. Nielsen' via Dart Misc
--
'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

[Mike]

@daniel
Yes, I do like Atom but I don't think it has any run/debug capability at the moment? If it could launch Dartium or Chrome with breakpoints and debugging enabled then it would be perfect.

[tatumizer-v0.2]

Post by 'Lasse R.H. Nielsen' via Dart Misc
for (int n in [:10]) { ... }

This is exactly what I tried to avoid in my bold proposal. 99+% of all uses
of ranges will likely occur in for statement anyway, just creating noise.
Ranges might be an orthogonal idea that is worth considering, but it's
(statistically) second or third tier feature IMO

I think this is another example of logic: I need feature X, but Y is more
general so I provide Y, thus killing two stones with one bird..
This reasoning doesn't account for statistics of usage.

[Gen]

Why not:
for (n < x.length) {...}

But iterators might be more efficient than using indexes because there is
one range check less.
Anyway, the "int" before x is rather usless.

Post by tatumizer-v0.2

Post by 'Lasse R.H. Nielsen' via Dart Misc
for (int n in [:10]) { ... }

This is exactly what I tried to avoid in my bold proposal. 99+% of all
uses of ranges will likely occur in for statement anyway, just creating
noise.
Ranges might be an orthogonal idea that is worth considering, but it's
(statistically) second or third tier feature IMO
I think this is another example of logic: I need feature X, but Y is more
general so I provide Y, thus killing two stones with one bird..
This reasoning doesn't account for statistics of usage.

['Lasse R.H. Nielsen' via Dart Misc]

On Thu, Sep 10, 2015 at 9:51 PM, 'Bob Nystrom' via Dart Misc <

Post by 'Bob Nystrom' via Dart Misc

Post by Mike
More useful Enums (by which I mean ability to add values like
print(myEnum.ThirdPlanet); //earth

This comes up a lot. I would definitely like to do something better here.

Post by Mike
Swift's code looks cleaner than Dart's and avoids clutter. Notably, it
avoids semi-colons and doesn't use round brackets in for loops, switch
statements and if blocks. Swift also has some nice syntax sugar e.g. you
can say "for n in 0..<10 {" which in Dart is "for (int n=0;n<10;n++) {"
Any chance of some of that goodness?

I would be happy to see semicolons be optional in Dart. Most modern
languages don't require them. Other syntax changes related to core
statement forms are less likely. I think we get a lot of value out of
sticking with the imperative statements users are familiar with from
C/C++/JS/Java/C# and I don't think tweaking them adds *that* much value.
Now, adding new interesting statements is a different story. But for the
for(), while(), and if() stuff users know and love, I think there's real
value in familiarity.

I would definitely vote for removing parentheses around while/if/switch
expression, but I fear it would complicate making semicolons optional - at
least as long as loop bodies don't need to be block statements.

(And, just once more (for now) I'll tout what I want loops to be like:

do {
body1;
} while (expression) {
body2;
} else {
afterwards;
}

That is, both a do and a while block in the same loop, fixing the fencepost
problem where you need to do some things n times and other things n-1 times.

It's basically equivalent to:

after: {
while (true) {
l1: {body1 [ break -> break after, continue -> break l1]}
if (!(expression)) break;
body2[break -> break after];
}
afterwards;
}

I have written code like that :)

My only problem is that I want variables declared in the do block to be
visible in the expression and while block, which breaks the normal scope
rules :(

Even just the "else" block, only executed when the condition fails, and not
if you break the loop (like in Python) would make some algorithms much
easier to do.

As it is, I either write more convoluted code or uses labeled breaks (which
seems to annoy the people reviewing my code).

/L
--
Lasse R.H. Nielsen - ***@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

[tatumizer-v0.2]

theFuture as void;
currently, it's not a valid expression, not clear why.

['Bob Nystrom' via Dart Misc]

Post by tatumizer-v0.2
theFuture as void;
currently, it's not a valid expression, not clear why.

"void" is not a type name in Dart. It's a reserved word that can only be
used in place of a return type for a method or function.

You could do theFuture as Null to accomplish the same thing.

Cheers!

- bob

[tatumizer-v0.2]

Post by 'Bob Nystrom' via Dart Misc
You could do theFuture as Null to accomplish the same thing

Well, it solves the problem then, right? For free!
Though, for aesthetic reasons, I would prefer "as void":).

['Bob Nystrom' via Dart Misc]

Post by tatumizer-v0.2

Post by 'Bob Nystrom' via Dart Misc
You could do theFuture as Null to accomplish the same thing

Well, it solves the problem then, right? For free!
Though, for aesthetic reasons, I would prefer "as void":).

Yup, "as dynamic" would work too. I think this is a good idea.

Thanks!

- bob

[tatumizer-v0.2]

Post by 'Lasse R.H. Nielsen' via Dart Misc
A shared private namespace might make sense

I looked into C# definition of namespaces
(https://msdn.microsoft.com/en-us/library/z2kcy19k.aspx plus links from
there) - it's complicated! (there are links from main page leading to
explanations of various aspects involved).

At some point, namespaces were all the rage, maybe because XML had them (it
was an important nail to the coffin of the concept)
Turning each package into de-facto namespace looks like much simpler
solution to me. Just remove "part" directive, let everything in the package
see everything else, this automatically allows access to private methods
from tests... It's much easier to formalize the notion of "package" than to
go into "namespaces" rat hole IMO.

For protected methods - I am not sure. Maybe, if B extends A, then B should
be able to *override* every method of B, including private ones (e.g. with
@override annotation)?

['Lasse R.H. Nielsen' via Dart Misc]

Post by 'Lasse R.H. Nielsen' via Dart Misc
A shared private namespace might make sense

I looked into C# definition of namespaces (
https://msdn.microsoft.com/en-us/library/z2kcy19k.aspx plus links from
there) - it's complicated! (there are links from main page leading to
explanations of various aspects involved).

Ack, yes. That's more complicated. All I intended was that two libraries
may be allowed to have compatible private names.
Dart private names are unique per library - it's not an access restriction
that prevents you from accessing "_foo" declared in a different library,
it's an expressibility restriction: You can't *write* the same _foo as the
other library.

If we had a way to link two libraries in such a way that their private
names were compatible, then writing "_foo" in either library refers to the
same name.

At some point, namespaces were all the rage, maybe because XML had them (it

was an important nail to the coffin of the concept)

XML or namespaces? :)
(XML started out as a relatively simple tree-structure language, but with
name spaces it became so horribly complicated that it paved the way for
JSON as a replacement).

Turning each package into de-facto namespace looks like much simpler
solution to me. Just remove "part" directive, let everything in the package
see everything else, this automatically allows access to private methods
from tests... It's much easier to formalize the notion of "package" than to
go into "namespaces" rat hole IMO.

Are you suggesting that "_foo" means the same for libraries loaded using a
package: URI if the first path segment of the path is the same?

I still have reservations against that, mainly that it only works for
packages, which isn't good enough. I'd rather be able to have any two(or
more) libraries able to opt into having a common privacy instead of
per-library privacy.

For protected methods - I am not sure. Maybe, if B extends A, then B
should be able to *override* every method of B, including private ones

I don't think that makes sense in Dart.

First of all, the problem I need to solve is the ability to call superclass
methods without exposing them in the public interface of the object.
Overloading wouldn't solve that.

Also library privacy prevents you from even expressing which superclass
method you are overriding. Just writing "@override int _foo() =>42;" won't
tell you which "_foo" it is. There may be two different private names
originally written "_foo" in the superclass chain, from different libraries.

To solve the problem, I think we need some kine of "object privacy" where
you can refer to such a name only on the same object (perhaps only through
"this." or "super."). It's a different kind of name from library private
and public names.

/L
--
Lasse R.H. Nielsen - ***@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

['Bob Nystrom' via Dart Misc]

On Tue, Sep 15, 2015 at 1:21 AM, 'Lasse R.H. Nielsen' via Dart Misc <

Post by 'Lasse R.H. Nielsen' via Dart Misc

Post by 'Lasse R.H. Nielsen' via Dart Misc
A shared private namespace might make sense

I looked into C# definition of namespaces (
https://msdn.microsoft.com/en-us/library/z2kcy19k.aspx plus links from
there) - it's complicated! (there are links from main page leading to
explanations of various aspects involved).

Ack, yes. That's more complicated. All I intended was that two libraries
may be allowed to have compatible private names.
Dart private names are unique per library - it's not an access restriction
that prevents you from accessing "_foo" declared in a different library,
it's an expressibility restriction: You can't *write* the same _foo as the
other library.
If we had a way to link two libraries in such a way that their private
names were compatible, then writing "_foo" in either library refers to the
same name.

I'd like something along these lines too. I talked about it with Leaf once,
and he brought up a tricky case. What would it mean to define a new top
level private name in the friend library? Would that name appear in the
source library too?

I think there probably is a clean solution, but it might be more complex
than I initially thought.

Post by 'Lasse R.H. Nielsen' via Dart Misc
Turning each package into de-facto namespace looks like much simpler

solution to me. Just remove "part" directive, let everything in the package
see everything else, this automatically allows access to private methods
from tests... It's much easier to formalize the notion of "package" than to
go into "namespaces" rat hole IMO.

Are you suggesting that "_foo" means the same for libraries loaded using a
package: URI if the first path segment of the path is the same?
I still have reservations against that, mainly that it only works for
packages, which isn't good enough. I'd rather be able to have any two(or
more) libraries able to opt into having a common privacy instead of
per-library privacy.

+1.

Post by 'Lasse R.H. Nielsen' via Dart Misc
Also library privacy prevents you from even expressing which superclass
tell you which "_foo" it is. There may be two different private names
originally written "_foo" in the superclass chain, from different libraries.
To solve the problem, I think we need some kine of "object privacy" where
you can refer to such a name only on the same object (perhaps only through
"this." or "super."). It's a different kind of name from library private
and public names.

I like Ruby's solution: private methods can only be invoked with the
implicit self receiver.

Cheers!

- bob

[tatumizer-v0.2]

I'd rather be able to have any two(or more) libraries able to opt into

having a common privacy instead of per-library privacy.
Yeah, that makes sense. +1

[Alexey Knyazev]

There is one more issue with removing 'part' directive. It will be
impossible to implement rather common Dart pattern (found in dart:io and
some pub packages e.g. crypto).
Let's say we've public interface and private implementation like this:

some_lib.dart
library some_lib;

part 'some_lib_impl.dart';
part 'some_lib_extra.dart';

/// Lots of comments, examples...

// Stable public interface
abstract class SomeClass {
factory SomeClass() => new _SomeClassImpl();
}

some_lib_impl.dart
part of some_lib

// implementation with lots of private functions,
// abstract private base classes, mixins, etc

class _SomeClassImpl extends _SomeClassBase implements SomeClass {
_SomeClassImpl();
}

abstract class _SomeClassBase {}

some_lib_extra.dart
part of some_lib

// several hundred of numbers such as primes, decode constants, etc
const List<int> _data = const [0x1, 0x3, 0x5, ...];

Moreover, I see no reason to call each of these three files a 'library',
because they are useless one by one.
At the same time it is convenient to have table data separated from
algorithms as well as documentation from internal implementation.

Post by 'Bob Nystrom' via Dart Misc
On Tue, Sep 15, 2015 at 1:21 AM, 'Lasse R.H. Nielsen' via Dart Misc <

Post by 'Lasse R.H. Nielsen' via Dart Misc

Post by 'Lasse R.H. Nielsen' via Dart Misc
A shared private namespace might make sense

I looked into C# definition of namespaces (
https://msdn.microsoft.com/en-us/library/z2kcy19k.aspx plus links from
there) - it's complicated! (there are links from main page leading to
explanations of various aspects involved).

Ack, yes. That's more complicated. All I intended was that two libraries
may be allowed to have compatible private names.
Dart private names are unique per library - it's not an access
restriction that prevents you from accessing "_foo" declared in a different
library, it's an expressibility restriction: You can't *write* the same
_foo as the other library.
If we had a way to link two libraries in such a way that their private
names were compatible, then writing "_foo" in either library refers to the
same name.

I'd like something along these lines too. I talked about it with Leaf
once, and he brought up a tricky case. What would it mean to define a new
top level private name in the friend library? Would that name appear in the
source library too?
I think there probably is a clean solution, but it might be more complex
than I initially thought.

Post by 'Lasse R.H. Nielsen' via Dart Misc
Turning each package into de-facto namespace looks like much simpler

solution to me. Just remove "part" directive, let everything in the package
see everything else, this automatically allows access to private methods
from tests... It's much easier to formalize the notion of "package" than to
go into "namespaces" rat hole IMO.

Are you suggesting that "_foo" means the same for libraries loaded using
a package: URI if the first path segment of the path is the same?
I still have reservations against that, mainly that it only works for
packages, which isn't good enough. I'd rather be able to have any two(or
more) libraries able to opt into having a common privacy instead of
per-library privacy.

+1.

Post by 'Lasse R.H. Nielsen' via Dart Misc
Also library privacy prevents you from even expressing which superclass
tell you which "_foo" it is. There may be two different private names
originally written "_foo" in the superclass chain, from different libraries.
To solve the problem, I think we need some kine of "object privacy" where
you can refer to such a name only on the same object (perhaps only through
"this." or "super."). It's a different kind of name from library private
and public names.

I like Ruby's solution: private methods can only be invoked with the
implicit self receiver.
Cheers!
- bob

['Bob Nystrom' via Dart Misc]

Post by Alexey Knyazev
There is one more issue with removing 'part' directive. It will be
impossible to implement rather common Dart pattern (found in dart:io and
some pub packages e.g. crypto).

Here's your example without using part:

// some_lib.dart
library some_lib;

*import* 'some_lib_impl.dart';
*import* 'some_lib_extra.dart';

/// Lots of comments, examples...

// Stable public interface
abstract class SomeClass {
factory SomeClass() => new *SomeClassImpl*();
}

// some_lib_impl.dart

// implementation with lots of private functions,
// abstract private base classes, mixins, etc

class *SomeClassImpl* extends _SomeClassBase implements SomeClass {
*SomeClassImpl*();
}

abstract class _SomeClassBase {}

// some_lib_extra.dart

// several hundred of numbers such as primes, decode constants, etc
const List<int> *data* = const [0x1, 0x3, 0x5, ...];

Post by Alexey Knyazev
Moreover, I see no reason to call each of these three files a 'library',
because they are useless one by one.

This is just a semantic argument. If you change your notion of "library" to
mean "file containing Dart code" instead of "reusable module", there's no
real issue here. Sure, *some* Dart libraries are meant to be reusable in
many contexts, but they don't all have to be.

Cheers!

- bob

[Anders Holmgren]

I've settled in the notion that packages are the reusable modules, plus
where things like circular refs are disallowed. Libraries are just an
implementation tool that helps for example hide code
On Wed, 16 Sep 2015 at 7:48 am, 'Bob Nystrom' via Dart Misc <

Post by 'Bob Nystrom' via Dart Misc

Post by Alexey Knyazev
There is one more issue with removing 'part' directive. It will be
impossible to implement rather common Dart pattern (found in dart:io and
some pub packages e.g. crypto).

// some_lib.dart
library some_lib;
*import* 'some_lib_impl.dart';
*import* 'some_lib_extra.dart';
/// Lots of comments, examples...
// Stable public interface
abstract class SomeClass {
factory SomeClass() => new *SomeClassImpl*();
}
// some_lib_impl.dart
// implementation with lots of private functions,
// abstract private base classes, mixins, etc
class *SomeClassImpl* extends _SomeClassBase implements SomeClass {
*SomeClassImpl*();
}
abstract class _SomeClassBase {}
// some_lib_extra.dart
// several hundred of numbers such as primes, decode constants, etc
const List<int> *data* = const [0x1, 0x3, 0x5, ...];

Post by Alexey Knyazev
Moreover, I see no reason to call each of these three files a 'library',
because they are useless one by one.

This is just a semantic argument. If you change your notion of "library"
to mean "file containing Dart code" instead of "reusable module", there's
no real issue here. Sure, *some* Dart libraries are meant to be reusable
in many contexts, but they don't all have to be.
Cheers!
- bob
--
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

[Alexey Knyazev]

If you change your notion of "library" to mean "file containing Dart

code" instead of "reusable module", there's no real issue here.
You're right, I should have been more open-minded about the notion of
"library".
Now the only thing about the future removal of "part" that bothers me is
the missing "protected"-like inheritance, but that issue has already got
attention.

Post by Alexey Knyazev
There is one more issue with removing 'part' directive. It will be
impossible to implement rather common Dart pattern (found in dart:io and
some pub packages e.g. crypto).

// some_lib.dart
library some_lib;
*import* 'some_lib_impl.dart';
*import* 'some_lib_extra.dart';
/// Lots of comments, examples...
// Stable public interface
abstract class SomeClass {
factory SomeClass() => new *SomeClassImpl*();
}
// some_lib_impl.dart
// implementation with lots of private functions,
// abstract private base classes, mixins, etc
class *SomeClassImpl* extends _SomeClassBase implements SomeClass {
*SomeClassImpl*();
}
abstract class _SomeClassBase {}
// some_lib_extra.dart
// several hundred of numbers such as primes, decode constants, etc
const List<int> *data* = const [0x1, 0x3, 0x5, ...];

Post by Alexey Knyazev
Moreover, I see no reason to call each of these three files a 'library',
because they are useless one by one.

This is just a semantic argument. If you change your notion of "library"
to mean "file containing Dart code" instead of "reusable module", there's
no real issue here. Sure, *some* Dart libraries are meant to be reusable
in many contexts, but they don't all have to be.
Cheers!
- bob

Post by Alexey Knyazev
There is one more issue with removing 'part' directive. It will be
impossible to implement rather common Dart pattern (found in dart:io and
some pub packages e.g. crypto).

// some_lib.dart
library some_lib;
*import* 'some_lib_impl.dart';
*import* 'some_lib_extra.dart';
/// Lots of comments, examples...
// Stable public interface
abstract class SomeClass {
factory SomeClass() => new *SomeClassImpl*();
}
// some_lib_impl.dart
// implementation with lots of private functions,
// abstract private base classes, mixins, etc
class *SomeClassImpl* extends _SomeClassBase implements SomeClass {
*SomeClassImpl*();
}
abstract class _SomeClassBase {}
// some_lib_extra.dart
// several hundred of numbers such as primes, decode constants, etc
const List<int> *data* = const [0x1, 0x3, 0x5, ...];

Post by Alexey Knyazev
Moreover, I see no reason to call each of these three files a 'library',
because they are useless one by one.

This is just a semantic argument. If you change your notion of "library"
to mean "file containing Dart code" instead of "reusable module", there's
no real issue here. Sure, *some* Dart libraries are meant to be reusable
in many contexts, but they don't all have to be.
Cheers!
- bob

['Lasse R.H. Nielsen' via Dart Misc]

On Tue, Sep 15, 2015 at 5:56 PM, 'Bob Nystrom' via Dart Misc <

Post by 'Bob Nystrom' via Dart Misc
On Tue, Sep 15, 2015 at 1:21 AM, 'Lasse R.H. Nielsen' via Dart Misc <

Post by 'Lasse R.H. Nielsen' via Dart Misc

Post by 'Lasse R.H. Nielsen' via Dart Misc
A shared private namespace might make sense

I looked into C# definition of namespaces (
https://msdn.microsoft.com/en-us/library/z2kcy19k.aspx plus links from
there) - it's complicated! (there are links from main page leading to
explanations of various aspects involved).

Ack, yes. That's more complicated. All I intended was that two libraries
may be allowed to have compatible private names.
Dart private names are unique per library - it's not an access
restriction that prevents you from accessing "_foo" declared in a different
library, it's an expressibility restriction: You can't *write* the same
_foo as the other library.
If we had a way to link two libraries in such a way that their private
names were compatible, then writing "_foo" in either library refers to the
same name.

I'd like something along these lines too. I talked about it with Leaf
once, and he brought up a tricky case. What would it mean to define a new
top level private name in the friend library? Would that name appear in the
source library too?

No, no more than if both libraries declared a public name like "foo".
It should still be two different libraries, it's just that the
name-mangling of private names creates the same mangled name for "_foo" in
both libraries, so if one does "otherLibraryClass._private", it actually
works.

Post by 'Bob Nystrom' via Dart Misc
I think there probably is a clean solution, but it might be more complex
than I initially thought.

I'm not sure the implementation is complex. Specifying it, and picking the
right restrictions on who can declare themselves friends, is harder. It
should be a mutual agreement between the libraries, so you can't just say
"I'm friends with that guy, so I get to look at his private stuff". It's an
agreement between cooperating libraries that they can access each other,
not a privacy override. At least, that's what I want :)

Post by 'Bob Nystrom' via Dart Misc

Post by 'Lasse R.H. Nielsen' via Dart Misc
Also library privacy prevents you from even expressing which superclass
tell you which "_foo" it is. There may be two different private names
originally written "_foo" in the superclass chain, from different libraries.
To solve the problem, I think we need some kine of "object privacy" where
you can refer to such a name only on the same object (perhaps only through
"this." or "super."). It's a different kind of name from library private
and public names.

I like Ruby's solution: private methods can only be invoked with the
implicit self receiver.

Yep, that's what I'd want too. In Dart, we'd need a third kind of
identifier for it.
It's a type of identifier that only makes sense for instance members, which
is new.
The member is only part of the class, not its interface - implementing the
class won't include it, but extending it will.

The question is whether we need variables that are both object-private and
library-private at the same time.
Something available only to subclasses in the same library.
I guess you could just use library-private in that case, since you are
assumed to trust your own library.

For API documentation, the "protected" members would need to be documented
- they are publicly visible, just only through this/super.

/L
--
Lasse R.H. Nielsen - ***@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

['Bob Nystrom' via Dart Misc]

On Tue, Sep 15, 2015 at 11:24 PM, 'Lasse R.H. Nielsen' via Dart Misc <

Post by 'Lasse R.H. Nielsen' via Dart Misc

Post by 'Bob Nystrom' via Dart Misc
I'd like something along these lines too. I talked about it with Leaf
once, and he brought up a tricky case. What would it mean to define a new
top level private name in the friend library? Would that name appear in the
source library too?

No, no more than if both libraries declared a public name like "foo".
It should still be two different libraries, it's just that the
name-mangling of private names creates the same mangled name for "_foo" in
both libraries, so if one does "otherLibraryClass._private", it actually
works.

OK, I *think* that makes sense, though I haven't really sat down to work
through all the implications.

Post by 'Lasse R.H. Nielsen' via Dart Misc

Post by 'Bob Nystrom' via Dart Misc
I think there probably is a clean solution, but it might be more complex
than I initially thought.

I'm not sure the implementation is complex. Specifying it, and picking the
right restrictions on who can declare themselves friends, is harder. It
should be a mutual agreement between the libraries, so you can't just say
"I'm friends with that guy, so I get to look at his private stuff". It's an
agreement between cooperating libraries that they can access each other,
not a privacy override. At least, that's what I want :)

I personally lean towards it being less restrictive. One use case for this
is tests, and I don't want non-test library code to mention its tests in
any way, even if just to say "I allow this test to access my private stuff."

Privacy is a developer productivity feature, not a security feature, so I
like "velvet rope" privacy. It tells you when you're going outside of the
bounds of the public API, but allows you to if you really know what you're
doing.

Being *too* restrictive can end up lowering productivity if you prevent a
user from doing something reasonable.

Post by 'Lasse R.H. Nielsen' via Dart Misc

Post by 'Bob Nystrom' via Dart Misc

Post by 'Lasse R.H. Nielsen' via Dart Misc
Also library privacy prevents you from even expressing which superclass
tell you which "_foo" it is. There may be two different private names
originally written "_foo" in the superclass chain, from different libraries.
To solve the problem, I think we need some kine of "object privacy"
where you can refer to such a name only on the same object (perhaps only
through "this." or "super."). It's a different kind of name from library
private and public names.

I like Ruby's solution: private methods can only be invoked with the
implicit self receiver.

Yep, that's what I'd want too. In Dart, we'd need a third kind of
identifier for it.
It's a type of identifier that only makes sense for instance members,
which is new.

I haven't put much thought into this, but I don't know if we need a
different identifier style that the user sees. I think we could just treat
self-sends as being implicitly name-mangled in some way.

Post by 'Lasse R.H. Nielsen' via Dart Misc
The member is only part of the class, not its interface - implementing the
class won't include it, but extending it will.

+1.

Post by 'Lasse R.H. Nielsen' via Dart Misc
The question is whether we need variables that are both object-private and
library-private at the same time.
Something available only to subclasses in the same library.
I guess you could just use library-private in that case, since you are
assumed to trust your own library.

Yeah, I think library private is perfectly adequate for this.

Post by 'Lasse R.H. Nielsen' via Dart Misc
For API documentation, the "protected" members would need to be documented
- they are publicly visible, just only through this/super.

Yup.

Cheers!

- bob

[Jan Mostert]

Post by Günter Zöchbauer
Remove break, continue, and labels in favor of non-local returns
I see no good reason to remove "break" and "continue".
I would keep them.

How do you jump out of a loop or continue to the next iteration without
break / continue ?
Typical Java example when polling something:

while (true) {
if (canDoSomething()){
break;
}
sleep(1000);
}

+1 for keeping them, unless the alternative is much much much better.

Parts

Post by Günter Zöchbauer
Please remove parts.

I can see the benefit of keeping parts, splitting a large file into
separate parts, but then one can also argue that those separate files
should be separate classes / libraries. Using parts is somewhat confusing
at times, especially when forgetting either the part section or importing
it in the main file and code misbehaving. How would the export alternative
work?


Removing new

Post by Günter Zöchbauer
Of course.

Making it optional would be much better, although deprecating the new
keyword would be less harsh if it is removed followed by permanent removal
at a later stage in Dart 3.

Removing Reified generics


What would be the reason for removing it?
I'm assuming reified generics has something to do with maintaining type
information after compilation as opposed to erasure.
Java is using TypeErasure for the sake of backwards compatibility, one
would assume that there are plenty of benefits for keeping type information?

Type annotations on the right


I can see the benefit of it after doing plenty of reading and it will
probably take a lot to get used to.
Seeing as other breaking changes are also being considered, may I suggest
that you rather go for deprecating the old syntax for Dart2, introducing
the new syntax in Dart2 and completely removing the deprecated syntax in
Dart3.
Also, if you're planning to go RHS, instead of *var pi : int = 3*, rather
make the var keyword optional, so if it's not supplied, it's implied that
it's a var.


Fields final by default


void updateABC(String abcNumber, SomeIdentifier abcIdentifier, e) { ...

If I understand this correctly, making fields final refers to making
parameters final in functions or does is spread wider?
If parameters are final, does that mean in the above example I can't go
abcNumber = "3" inside the function,
neither abcIdentifier = new SomeIdentifier(), but I can do abcIdentifier.a
= 1; abcIdentifer.b = 2; like in java as
if each variable was defined final String abcNumber, final SomeIdentifier
abcIdentifier.

Would there be use cases where params are expected not to be final for some
reason?

In Java projects I see people treat parameters as final in any case whether
they are marked as final or not.


Assert


I've never seen the benefit of assert in Java, assert is disabled by
default unless you enable it with special flags and unit tests have their
own
Assert.assertTrue, Assert.assertEquals, etc.
Writing my own assert function that behaves exactly as I want it sounds
much more useful.
+1 for deprecating assert unless it has some very useful usecase.

Uniformity of reference


Removing () for 0 param functions would make code very confusing to read, I
would not be sure whether I'm looking at variables or functions.

Take words that are nouns and verbs as example:

object. address <- is this the object's address or does it mean address the
issue
object.display <- does this mean display object or is it a boolean flag
being set for when the object can be displayed.

-1 for removing () from 0 param functions.












--
Jan Vladimir Mostert
janvladimirmostert.com


On Wed, Sep 16, 2015 at 9:37 PM, 'Bob Nystrom' via Dart Misc <

Post by Günter Zöchbauer
On Tue, Sep 15, 2015 at 11:24 PM, 'Lasse R.H. Nielsen' via Dart Misc <

Post by 'Lasse R.H. Nielsen' via Dart Misc

Post by 'Bob Nystrom' via Dart Misc
I'd like something along these lines too. I talked about it with Leaf
once, and he brought up a tricky case. What would it mean to define a new
top level private name in the friend library? Would that name appear in the
source library too?

No, no more than if both libraries declared a public name like "foo".
It should still be two different libraries, it's just that the
name-mangling of private names creates the same mangled name for "_foo" in
both libraries, so if one does "otherLibraryClass._private", it actually
works.

OK, I *think* that makes sense, though I haven't really sat down to work
through all the implications.

Post by 'Lasse R.H. Nielsen' via Dart Misc

Post by 'Bob Nystrom' via Dart Misc
I think there probably is a clean solution, but it might be more complex
than I initially thought.

I'm not sure the implementation is complex. Specifying it, and picking
the right restrictions on who can declare themselves friends, is harder. It
should be a mutual agreement between the libraries, so you can't just say
"I'm friends with that guy, so I get to look at his private stuff". It's an
agreement between cooperating libraries that they can access each other,
not a privacy override. At least, that's what I want :)

I personally lean towards it being less restrictive. One use case for this
is tests, and I don't want non-test library code to mention its tests in
any way, even if just to say "I allow this test to access my private stuff."
Privacy is a developer productivity feature, not a security feature, so I
like "velvet rope" privacy. It tells you when you're going outside of the
bounds of the public API, but allows you to if you really know what you're
doing.
Being *too* restrictive can end up lowering productivity if you prevent a
user from doing something reasonable.

Post by 'Lasse R.H. Nielsen' via Dart Misc

Post by 'Bob Nystrom' via Dart Misc

Post by 'Lasse R.H. Nielsen' via Dart Misc
Also library privacy prevents you from even expressing which superclass
tell you which "_foo" it is. There may be two different private names
originally written "_foo" in the superclass chain, from different libraries.
To solve the problem, I think we need some kine of "object privacy"
where you can refer to such a name only on the same object (perhaps only
through "this." or "super."). It's a different kind of name from library
private and public names.

I like Ruby's solution: private methods can only be invoked with the
implicit self receiver.

Yep, that's what I'd want too. In Dart, we'd need a third kind of
identifier for it.
It's a type of identifier that only makes sense for instance members,
which is new.

I haven't put much thought into this, but I don't know if we need a
different identifier style that the user sees. I think we could just treat
self-sends as being implicitly name-mangled in some way.

Post by 'Lasse R.H. Nielsen' via Dart Misc
The member is only part of the class, not its interface - implementing
the class won't include it, but extending it will.

+1.

Post by 'Lasse R.H. Nielsen' via Dart Misc
The question is whether we need variables that are both object-private
and library-private at the same time.
Something available only to subclasses in the same library.
I guess you could just use library-private in that case, since you are
assumed to trust your own library.

Yeah, I think library private is perfectly adequate for this.

Post by 'Lasse R.H. Nielsen' via Dart Misc
For API documentation, the "protected" members would need to be
documented - they are publicly visible, just only through this/super.

Yup.
Cheers!
- bob
--
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

[Gen]

Post by Jan Mostert
Parts

Post by Gen
Please remove parts.

I can see the benefit of keeping parts, splitting a large file into
separate parts, but then one can also argue that those separate files
should be separate classes / libraries. Using parts is somewhat confusing
at times, especially when forgetting either the part section or importing
it in the main file and code misbehaving. How would the export alternative
work?
I do not like the effort to declare the same relationship twice. Once in

the the importing file should be enough.
But I have not used Dart for many months. I do not remember anymore how
libraries worked and what has changed since then.
I remember problems with the identity of types when I used "export" the
last time.

Post by Jan Mostert
Removing new

Post by Gen
Of course.

Making it optional would be much better, although deprecating the new
keyword would be less harsh if it is removed followed by permanent removal
at a later stage in Dart 3.
Of course, optional is always a solution. Especially with regard to "new".

But in general I would avoid to delay language changes if possible.
The longer the delay the greater the harm and resistence to changes. It
would be unfortunate to enlarge a language unnecessarily.

Post by Jan Mostert
Fields final by default
void updateABC(String abcNumber, SomeIdentifier abcIdentifier, e) { ...
If I understand this correctly, making fields final refers to making
parameters final in functions or does is spread wider?
If parameters are final, does that mean in the above example I can't go
abcNumber = "3" inside the function,
neither abcIdentifier = new SomeIdentifier(), but I can do abcIdentifier.a
= 1; abcIdentifer.b = 2; like in java as
if each variable was defined final String abcNumber, final SomeIdentifier
abcIdentifier.
Would there be use cases where params are expected not to be final for
some reason?
In Java projects I see people treat parameters as final in any case
whether they are marked as final or not.
AFAIU, class fields are meant.

[Jan Mostert]

Post by Gen

Post by Matthew Butler
Fields final by default
void updateABC(String abcNumber, SomeIdentifier abcIdentifier, e) { ...
If I understand this correctly, making fields final refers to making
parameters final in functions or does is spread wider?
If parameters are final, does that mean in the above example I can't go
abcNumber = "3" inside the function,
neither abcIdentifier = new SomeIdentifier(), but I can do
abcIdentifier.a = 1; abcIdentifer.b = 2; like in java as
if each variable was defined final String abcNumber, final SomeIdentifier
abcIdentifier.
Would there be use cases where params are expected not to be final for
some reason?
In Java projects I see people treat parameters as final in any case
whether they are marked as final or not.
AFAIU, class fields are meant.

If all fields in a class are final, how do you modify those fields outside
the constructor ?
How would you make them non-final so you can actually use them ?




--
Jan Vladimir Mostert
janvladimirmostert.com

Post by Gen

Post by Matthew Butler
Parts

Post by Gen
Please remove parts.

I can see the benefit of keeping parts, splitting a large file into
separate parts, but then one can also argue that those separate files
should be separate classes / libraries. Using parts is somewhat confusing
at times, especially when forgetting either the part section or importing
it in the main file and code misbehaving. How would the export alternative
work?
I do not like the effort to declare the same relationship twice. Once in

the the importing file should be enough.
But I have not used Dart for many months. I do not remember anymore how
libraries worked and what has changed since then.
I remember problems with the identity of types when I used "export" the
last time.

Post by Matthew Butler
Removing new

Post by Gen
Of course.

Making it optional would be much better, although deprecating the new
keyword would be less harsh if it is removed followed by permanent removal
at a later stage in Dart 3.
Of course, optional is always a solution. Especially with regard to "new".

But in general I would avoid to delay language changes if possible.
The longer the delay the greater the harm and resistence to changes. It
would be unfortunate to enlarge a language unnecessarily.

Post by Matthew Butler
Fields final by default
void updateABC(String abcNumber, SomeIdentifier abcIdentifier, e) { ...
If I understand this correctly, making fields final refers to making
parameters final in functions or does is spread wider?
If parameters are final, does that mean in the above example I can't go
abcNumber = "3" inside the function,
neither abcIdentifier = new SomeIdentifier(), but I can do
abcIdentifier.a = 1; abcIdentifer.b = 2; like in java as
if each variable was defined final String abcNumber, final SomeIdentifier
abcIdentifier.
Would there be use cases where params are expected not to be final for
some reason?
In Java projects I see people treat parameters as final in any case
whether they are marked as final or not.
AFAIU, class fields are meant.

[Anders Holmgren]

Post by Jan Mostert
If all fields in a class are final, how do you modify those fields

outside the constructor ?

Post by Jan Mostert
How would you make them non-final so you can actually use them ?

Firstly, the proposal is to change the default, which today is mutable
(implicit var), to immutable (implicit final).

So today if you do

String foo = 'foo';

that is the same as

var String foo = 'foo';

This proposal would change that to being the same as

final String foo = 'foo';

So the answer to your second question is to declare any fields you want to
be mutable with a var.

If all your fields are immutable, then changing the values of the field
involves creating a new instance with the changes made. You can see
examples of this already all over dart, for example the Built collections.

A

Post by Jan Mostert

Post by Gen

Post by Matthew Butler
Fields final by default
void updateABC(String abcNumber, SomeIdentifier abcIdentifier, e) { ...
If I understand this correctly, making fields final refers to making
parameters final in functions or does is spread wider?
If parameters are final, does that mean in the above example I can't go
abcNumber = "3" inside the function,
neither abcIdentifier = new SomeIdentifier(), but I can do
abcIdentifier.a = 1; abcIdentifer.b = 2; like in java as
if each variable was defined final String abcNumber, final
SomeIdentifier abcIdentifier.
Would there be use cases where params are expected not to be final for
some reason?
In Java projects I see people treat parameters as final in any case
whether they are marked as final or not.
AFAIU, class fields are meant.

If all fields in a class are final, how do you modify those fields outside
the constructor ?
How would you make them non-final so you can actually use them ?
--
Jan Vladimir Mostert
janvladimirmostert.com

Post by Gen

Post by Matthew Butler
Parts

Post by Gen
Please remove parts.

I can see the benefit of keeping parts, splitting a large file into
separate parts, but then one can also argue that those separate files
should be separate classes / libraries. Using parts is somewhat confusing
at times, especially when forgetting either the part section or importing
it in the main file and code misbehaving. How would the export alternative
work?
I do not like the effort to declare the same relationship twice. Once in

the the importing file should be enough.
But I have not used Dart for many months. I do not remember anymore how
libraries worked and what has changed since then.
I remember problems with the identity of types when I used "export" the
last time.

Post by Matthew Butler
Removing new

Post by Gen
Of course.

Making it optional would be much better, although deprecating the new
keyword would be less harsh if it is removed followed by permanent removal
at a later stage in Dart 3.
Of course, optional is always a solution. Especially with regard to

"new".
But in general I would avoid to delay language changes if possible.
The longer the delay the greater the harm and resistence to changes. It
would be unfortunate to enlarge a language unnecessarily.

Post by Matthew Butler
Fields final by default
void updateABC(String abcNumber, SomeIdentifier abcIdentifier, e) { ...
If I understand this correctly, making fields final refers to making
parameters final in functions or does is spread wider?
If parameters are final, does that mean in the above example I can't go
abcNumber = "3" inside the function,
neither abcIdentifier = new SomeIdentifier(), but I can do
abcIdentifier.a = 1; abcIdentifer.b = 2; like in java as
if each variable was defined final String abcNumber, final
SomeIdentifier abcIdentifier.
Would there be use cases where params are expected not to be final for
some reason?
In Java projects I see people treat parameters as final in any case
whether they are marked as final or not.
AFAIU, class fields are meant.

--
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

[Jan Mostert]

What would be the reasoning to make all fields final by default?
Isn't that less efficient to create a new instance every time you want to
change a value?
99.99% of fields I create in a class I use in a non-final context, example,
using setters.





--
Jan Vladimir Mostert
janvladimirmostert.com

Post by Anders Holmgren

Post by Jan Mostert
If all fields in a class are final, how do you modify those fields

outside the constructor ?

Post by Jan Mostert
How would you make them non-final so you can actually use them ?

Firstly, the proposal is to change the default, which today is mutable
(implicit var), to immutable (implicit final).
So today if you do
String foo = 'foo';
that is the same as
var String foo = 'foo';
This proposal would change that to being the same as
final String foo = 'foo';
So the answer to your second question is to declare any fields you want to
be mutable with a var.
If all your fields are immutable, then changing the values of the field
involves creating a new instance with the changes made. You can see
examples of this already all over dart, for example the Built collections.
A

Post by Jan Mostert

Post by Matthew Butler
Fields final by default
void updateABC(String abcNumber, SomeIdentifier abcIdentifier, e) { ...
If I understand this correctly, making fields final refers to making
parameters final in functions or does is spread wider?
If parameters are final, does that mean in the above example I can't go
abcNumber = "3" inside the function,
neither abcIdentifier = new SomeIdentifier(), but I can do
abcIdentifier.a = 1; abcIdentifer.b = 2; like in java as
if each variable was defined final String abcNumber, final
SomeIdentifier abcIdentifier.
Would there be use cases where params are expected not to be final for
some reason?
In Java projects I see people treat parameters as final in any case
whether they are marked as final or not.
AFAIU, class fields are meant.

If all fields in a class are final, how do you modify those fields
outside the constructor ?
How would you make them non-final so you can actually use them ?
--
Jan Vladimir Mostert
janvladimirmostert.com

Post by Matthew Butler
Parts

Post by Gen
Please remove parts.

I can see the benefit of keeping parts, splitting a large file into
separate parts, but then one can also argue that those separate files
should be separate classes / libraries. Using parts is somewhat confusing
at times, especially when forgetting either the part section or importing
it in the main file and code misbehaving. How would the export alternative
work?
I do not like the effort to declare the same relationship twice. Once

in the the importing file should be enough.
But I have not used Dart for many months. I do not remember anymore how
libraries worked and what has changed since then.
I remember problems with the identity of types when I used "export" the
last time.

Post by Matthew Butler
Removing new

Post by Gen
Of course.

Making it optional would be much better, although deprecating the new
keyword would be less harsh if it is removed followed by permanent removal
at a later stage in Dart 3.
Of course, optional is always a solution. Especially with regard to

"new".
But in general I would avoid to delay language changes if possible.
The longer the delay the greater the harm and resistence to changes. It
would be unfortunate to enlarge a language unnecessarily.

Post by Matthew Butler
Fields final by default
void updateABC(String abcNumber, SomeIdentifier abcIdentifier, e) { ...
If I understand this correctly, making fields final refers to making
parameters final in functions or does is spread wider?
If parameters are final, does that mean in the above example I can't go
abcNumber = "3" inside the function,
neither abcIdentifier = new SomeIdentifier(), but I can do
abcIdentifier.a = 1; abcIdentifer.b = 2; like in java as
if each variable was defined final String abcNumber, final
SomeIdentifier abcIdentifier.
Would there be use cases where params are expected not to be final for
some reason?
In Java projects I see people treat parameters as final in any case
whether they are marked as final or not.
AFAIU, class fields are meant.

--
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

--
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

[Günter Zöchbauer]

On Thursday, September 17, 2015 at 7:28:57 AM UTC+2, Jan Vladimir Mostert

Post by Jan Mostert
What would be the reasoning to make all fields final by default?
Isn't that less efficient to create a new instance every time you want to
change a value?
99.99% of fields I create in a class I use in a non-final context,
example, using setters.

If you need to change a value you just make it mutable (var).

I find that in many cases I just assign a value to a variable to pass it to
one or more other functions without a need to change it in between.
I also usually avoid modifying function arguments. If they are final the
analyzer reminds me about the violation of my usual practice. If it is
intentional I change it to mutable.

I find it easier to reason about code when I see whether a variable is
declared mutable or immutable.
I like to get a warning from the analyzer when I assign a value to a final
variable. It reminds me that I had a different intention when I declared
the variable and that I need to reconsider whether it's a good idea to use
the same variable again (needs changing it to mutable) or introduce a new
variable instead.

Post by Jan Mostert
--
Jan Vladimir Mostert
janvladimirmostert.com

Post by Anders Holmgren

Post by Jan Mostert
If all fields in a class are final, how do you modify those fields

outside the constructor ?

Post by Jan Mostert
How would you make them non-final so you can actually use them ?

Firstly, the proposal is to change the default, which today is mutable
(implicit var), to immutable (implicit final).
So today if you do
String foo = 'foo';
that is the same as
var String foo = 'foo';
This proposal would change that to being the same as
final String foo = 'foo';
So the answer to your second question is to declare any fields you want
to be mutable with a var.
If all your fields are immutable, then changing the values of the field
involves creating a new instance with the changes made. You can see
examples of this already all over dart, for example the Built collections.
A

Post by Jan Mostert

Post by Matthew Butler
Fields final by default
void updateABC(String abcNumber, SomeIdentifier abcIdentifier, e) { ...
If I understand this correctly, making fields final refers to making
parameters final in functions or does is spread wider?
If parameters are final, does that mean in the above example I can't
go abcNumber = "3" inside the function,
neither abcIdentifier = new SomeIdentifier(), but I can do
abcIdentifier.a = 1; abcIdentifer.b = 2; like in java as
if each variable was defined final String abcNumber, final
SomeIdentifier abcIdentifier.
Would there be use cases where params are expected not to be final for
some reason?
In Java projects I see people treat parameters as final in any case
whether they are marked as final or not.
AFAIU, class fields are meant.

If all fields in a class are final, how do you modify those fields
outside the constructor ?
How would you make them non-final so you can actually use them ?
--
Jan Vladimir Mostert
janvladimirmostert.com

Post by Matthew Butler
Parts

Post by Gen
Please remove parts.

I can see the benefit of keeping parts, splitting a large file into
separate parts, but then one can also argue that those separate files
should be separate classes / libraries. Using parts is somewhat confusing
at times, especially when forgetting either the part section or importing
it in the main file and code misbehaving. How would the export alternative
work?
I do not like the effort to declare the same relationship twice. Once

in the the importing file should be enough.
But I have not used Dart for many months. I do not remember anymore how
libraries worked and what has changed since then.
I remember problems with the identity of types when I used "export" the
last time.

Post by Matthew Butler
Removing new

Post by Gen
Of course.

Making it optional would be much better, although deprecating the new
keyword would be less harsh if it is removed followed by permanent removal
at a later stage in Dart 3.
Of course, optional is always a solution. Especially with regard to

"new".
But in general I would avoid to delay language changes if possible.
The longer the delay the greater the harm and resistence to changes. It
would be unfortunate to enlarge a language unnecessarily.

Post by Matthew Butler
Fields final by default
void updateABC(String abcNumber, SomeIdentifier abcIdentifier, e) { ...
If I understand this correctly, making fields final refers to making
parameters final in functions or does is spread wider?
If parameters are final, does that mean in the above example I can't
go abcNumber = "3" inside the function,
neither abcIdentifier = new SomeIdentifier(), but I can do
abcIdentifier.a = 1; abcIdentifer.b = 2; like in java as
if each variable was defined final String abcNumber, final
SomeIdentifier abcIdentifier.
Would there be use cases where params are expected not to be final for
some reason?
In Java projects I see people treat parameters as final in any case
whether they are marked as final or not.
AFAIU, class fields are meant.

--
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

--
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

[Günter Zöchbauer]

On Thursday, September 17, 2015 at 6:59:26 AM UTC+2, Jan Vladimir Mostert

Post by Jan Mostert

Post by Gen

Post by Matthew Butler
Fields final by default
void updateABC(String abcNumber, SomeIdentifier abcIdentifier, e) { ...
If I understand this correctly, making fields final refers to making
parameters final in functions or does is spread wider?
If parameters are final, does that mean in the above example I can't go
abcNumber = "3" inside the function,
neither abcIdentifier = new SomeIdentifier(), but I can do
abcIdentifier.a = 1; abcIdentifer.b = 2; like in java as
if each variable was defined final String abcNumber, final
SomeIdentifier abcIdentifier.
Would there be use cases where params are expected not to be final for
some reason?
In Java projects I see people treat parameters as final in any case
whether they are marked as final or not.
AFAIU, class fields are meant.

If all fields in a class are final, how do you modify those fields outside
the constructor ?
How would you make them non-final so you can actually use them ?

It's not about *final only*, its about *final by default*.
There would be some keyword (var or whatever) that changes the default
behavior from *final* to "non-final".
Currently the default is non-final and you can make it final by adding the
final keyword.
I always add final until I encounter the requirement that I need to modify
a variable then I remove it. Therefore final by default would be very
convenient because I would only special case the exceptions not the common
case.

Post by Jan Mostert
--
Jan Vladimir Mostert
janvladimirmostert.com

Post by Gen

Post by Matthew Butler
Parts

Post by Gen
Please remove parts.

I can see the benefit of keeping parts, splitting a large file into
separate parts, but then one can also argue that those separate files
should be separate classes / libraries. Using parts is somewhat confusing
at times, especially when forgetting either the part section or importing
it in the main file and code misbehaving. How would the export alternative
work?
I do not like the effort to declare the same relationship twice. Once in

the the importing file should be enough.
But I have not used Dart for many months. I do not remember anymore how
libraries worked and what has changed since then.
I remember problems with the identity of types when I used "export" the
last time.

Post by Matthew Butler
Removing new

Post by Gen
Of course.

Making it optional would be much better, although deprecating the new
keyword would be less harsh if it is removed followed by permanent removal
at a later stage in Dart 3.
Of course, optional is always a solution. Especially with regard to

"new".
But in general I would avoid to delay language changes if possible.
The longer the delay the greater the harm and resistence to changes. It
would be unfortunate to enlarge a language unnecessarily.

Post by Matthew Butler
Fields final by default
void updateABC(String abcNumber, SomeIdentifier abcIdentifier, e) { ...
If I understand this correctly, making fields final refers to making
parameters final in functions or does is spread wider?
If parameters are final, does that mean in the above example I can't go
abcNumber = "3" inside the function,
neither abcIdentifier = new SomeIdentifier(), but I can do
abcIdentifier.a = 1; abcIdentifer.b = 2; like in java as
if each variable was defined final String abcNumber, final
SomeIdentifier abcIdentifier.
Would there be use cases where params are expected not to be final for
some reason?
In Java projects I see people treat parameters as final in any case
whether they are marked as final or not.
AFAIU, class fields are meant.

[Jan Mostert]

Sure I get that, just wondering what the use case is, the majority (as in
99.9%) of code I look at works under the assumption that fields are
non-final in order to use setters on them.
That's true for Java and Dart code.

--
Jan Vladimir Mostert
janvladimirmostert.com

Post by Günter Zöchbauer
On Thursday, September 17, 2015 at 6:59:26 AM UTC+2, Jan Vladimir Mostert

Post by Jan Mostert

Post by Matthew Butler
Fields final by default
void updateABC(String abcNumber, SomeIdentifier abcIdentifier, e) { ...
If I understand this correctly, making fields final refers to making
parameters final in functions or does is spread wider?
If parameters are final, does that mean in the above example I can't go
abcNumber = "3" inside the function,
neither abcIdentifier = new SomeIdentifier(), but I can do
abcIdentifier.a = 1; abcIdentifer.b = 2; like in java as
if each variable was defined final String abcNumber, final
SomeIdentifier abcIdentifier.
Would there be use cases where params are expected not to be final for
some reason?
In Java projects I see people treat parameters as final in any case
whether they are marked as final or not.
AFAIU, class fields are meant.

If all fields in a class are final, how do you modify those fields
outside the constructor ?
How would you make them non-final so you can actually use them ?

It's not about *final only*, its about *final by default*.
There would be some keyword (var or whatever) that changes the default
behavior from *final* to "non-final".
Currently the default is non-final and you can make it final by adding the
final keyword.
I always add final until I encounter the requirement that I need to modify
a variable then I remove it. Therefore final by default would be very
convenient because I would only special case the exceptions not the common
case.

Post by Jan Mostert
--
Jan Vladimir Mostert
janvladimirmostert.com

Post by Matthew Butler
Parts

Post by Gen
Please remove parts.

I can see the benefit of keeping parts, splitting a large file into
separate parts, but then one can also argue that those separate files
should be separate classes / libraries. Using parts is somewhat confusing
at times, especially when forgetting either the part section or importing
it in the main file and code misbehaving. How would the export alternative
work?
I do not like the effort to declare the same relationship twice. Once

in the the importing file should be enough.
But I have not used Dart for many months. I do not remember anymore how
libraries worked and what has changed since then.
I remember problems with the identity of types when I used "export" the
last time.

Post by Matthew Butler
Removing new

Post by Gen
Of course.

Making it optional would be much better, although deprecating the new
keyword would be less harsh if it is removed followed by permanent removal
at a later stage in Dart 3.
Of course, optional is always a solution. Especially with regard to

"new".
But in general I would avoid to delay language changes if possible.
The longer the delay the greater the harm and resistence to changes. It
would be unfortunate to enlarge a language unnecessarily.

Post by Matthew Butler
Fields final by default
void updateABC(String abcNumber, SomeIdentifier abcIdentifier, e) { ...
If I understand this correctly, making fields final refers to making
parameters final in functions or does is spread wider?
If parameters are final, does that mean in the above example I can't go
abcNumber = "3" inside the function,
neither abcIdentifier = new SomeIdentifier(), but I can do
abcIdentifier.a = 1; abcIdentifer.b = 2; like in java as
if each variable was defined final String abcNumber, final
SomeIdentifier abcIdentifier.
Would there be use cases where params are expected not to be final for
some reason?
In Java projects I see people treat parameters as final in any case
whether they are marked as final or not.
AFAIU, class fields are meant.

[Günter Zöchbauer]

The doc doesn't specify where exactly this should apply.
I agree, for fields this would be cumbersome but it would be convenient for
variables and parameters.

On Thursday, September 17, 2015 at 9:59:49 AM UTC+2, Jan Vladimir Mostert

Post by Jan Mostert
Sure I get that, just wondering what the use case is, the majority (as in
99.9%) of code I look at works under the assumption that fields are
non-final in order to use setters on them.
That's true for Java and Dart code.
--
Jan Vladimir Mostert
janvladimirmostert.com

Post by Günter Zöchbauer
On Thursday, September 17, 2015 at 6:59:26 AM UTC+2, Jan Vladimir Mostert

Post by Jan Mostert

Post by Matthew Butler
Fields final by default
void updateABC(String abcNumber, SomeIdentifier abcIdentifier, e) { ...
If I understand this correctly, making fields final refers to making
parameters final in functions or does is spread wider?
If parameters are final, does that mean in the above example I can't
go abcNumber = "3" inside the function,
neither abcIdentifier = new SomeIdentifier(), but I can do
abcIdentifier.a = 1; abcIdentifer.b = 2; like in java as
if each variable was defined final String abcNumber, final
SomeIdentifier abcIdentifier.
Would there be use cases where params are expected not to be final for
some reason?
In Java projects I see people treat parameters as final in any case
whether they are marked as final or not.
AFAIU, class fields are meant.

If all fields in a class are final, how do you modify those fields
outside the constructor ?
How would you make them non-final so you can actually use them ?

It's not about *final only*, its about *final by default*.
There would be some keyword (var or whatever) that changes the default
behavior from *final* to "non-final".
Currently the default is non-final and you can make it final by adding
the final keyword.
I always add final until I encounter the requirement that I need to
modify a variable then I remove it. Therefore final by default would be
very convenient because I would only special case the exceptions not the
common case.

Post by Jan Mostert
--
Jan Vladimir Mostert
janvladimirmostert.com

Post by Matthew Butler
Parts

Post by Gen
Please remove parts.

I can see the benefit of keeping parts, splitting a large file into
separate parts, but then one can also argue that those separate files
should be separate classes / libraries. Using parts is somewhat confusing
at times, especially when forgetting either the part section or importing
it in the main file and code misbehaving. How would the export alternative
work?
I do not like the effort to declare the same relationship twice. Once

in the the importing file should be enough.
But I have not used Dart for many months. I do not remember anymore how
libraries worked and what has changed since then.
I remember problems with the identity of types when I used "export" the
last time.

Post by Matthew Butler
Removing new

Post by Gen
Of course.

Making it optional would be much better, although deprecating the new
keyword would be less harsh if it is removed followed by permanent removal
at a later stage in Dart 3.
Of course, optional is always a solution. Especially with regard to

"new".
But in general I would avoid to delay language changes if possible.
The longer the delay the greater the harm and resistence to changes. It
would be unfortunate to enlarge a language unnecessarily.

Post by Matthew Butler
Fields final by default
void updateABC(String abcNumber, SomeIdentifier abcIdentifier, e) { ...
If I understand this correctly, making fields final refers to making
parameters final in functions or does is spread wider?
If parameters are final, does that mean in the above example I can't
go abcNumber = "3" inside the function,
neither abcIdentifier = new SomeIdentifier(), but I can do
abcIdentifier.a = 1; abcIdentifer.b = 2; like in java as
if each variable was defined final String abcNumber, final
SomeIdentifier abcIdentifier.
Would there be use cases where params are expected not to be final for
some reason?
In Java projects I see people treat parameters as final in any case
whether they are marked as final or not.
AFAIU, class fields are meant.

[Jan Mostert]

Post by Günter Zöchbauer
I agree, for fields this would be cumbersome but it would be convenient
for variables and parameters.

+1

--
Jan Vladimir Mostert
janvladimirmostert.com

Post by Günter Zöchbauer
The doc doesn't specify where exactly this should apply.
I agree, for fields this would be cumbersome but it would be convenient
for variables and parameters.
On Thursday, September 17, 2015 at 9:59:49 AM UTC+2, Jan Vladimir Mostert

Post by Jan Mostert
Sure I get that, just wondering what the use case is, the majority (as in
99.9%) of code I look at works under the assumption that fields are
non-final in order to use setters on them.
That's true for Java and Dart code.
--
Jan Vladimir Mostert
janvladimirmostert.com

Post by Günter Zöchbauer
On Thursday, September 17, 2015 at 6:59:26 AM UTC+2, Jan Vladimir

Post by Jan Mostert

Post by Matthew Butler
Fields final by default
void updateABC(String abcNumber, SomeIdentifier abcIdentifier, e) { ...
If I understand this correctly, making fields final refers to making
parameters final in functions or does is spread wider?
If parameters are final, does that mean in the above example I can't
go abcNumber = "3" inside the function,
neither abcIdentifier = new SomeIdentifier(), but I can do
abcIdentifier.a = 1; abcIdentifer.b = 2; like in java as
if each variable was defined final String abcNumber, final
SomeIdentifier abcIdentifier.
Would there be use cases where params are expected not to be final
for some reason?
In Java projects I see people treat parameters as final in any case
whether they are marked as final or not.
AFAIU, class fields are meant.

If all fields in a class are final, how do you modify those fields
outside the constructor ?
How would you make them non-final so you can actually use them ?

It's not about *final only*, its about *final by default*.
There would be some keyword (var or whatever) that changes the default
behavior from *final* to "non-final".
Currently the default is non-final and you can make it final by adding
the final keyword.
I always add final until I encounter the requirement that I need to
modify a variable then I remove it. Therefore final by default would be
very convenient because I would only special case the exceptions not the
common case.

Post by Jan Mostert
--
Jan Vladimir Mostert
janvladimirmostert.com

Post by Matthew Butler
Parts

Post by Gen
Please remove parts.

I can see the benefit of keeping parts, splitting a large file into
separate parts, but then one can also argue that those separate files
should be separate classes / libraries. Using parts is somewhat confusing
at times, especially when forgetting either the part section or importing
it in the main file and code misbehaving. How would the export alternative
work?
I do not like the effort to declare the same relationship twice. Once

in the the importing file should be enough.
But I have not used Dart for many months. I do not remember anymore
how libraries worked and what has changed since then.
I remember problems with the identity of types when I used "export"
the last time.

Post by Matthew Butler
Removing new

Post by Gen
Of course.

Making it optional would be much better, although deprecating the
new keyword would be less harsh if it is removed followed by permanent
removal at a later stage in Dart 3.
Of course, optional is always a solution. Especially with regard to

"new".
But in general I would avoid to delay language changes if possible.
The longer the delay the greater the harm and resistence to changes.
It would be unfortunate to enlarge a language unnecessarily.

Post by Matthew Butler
Fields final by default
void updateABC(String abcNumber, SomeIdentifier abcIdentifier, e) { ...
If I understand this correctly, making fields final refers to making
parameters final in functions or does is spread wider?
If parameters are final, does that mean in the above example I can't
go abcNumber = "3" inside the function,
neither abcIdentifier = new SomeIdentifier(), but I can do
abcIdentifier.a = 1; abcIdentifer.b = 2; like in java as
if each variable was defined final String abcNumber, final
SomeIdentifier abcIdentifier.
Would there be use cases where params are expected not to be final
for some reason?
In Java projects I see people treat parameters as final in any case
whether they are marked as final or not.
AFAIU, class fields are meant.

[Алексей Князев]

On removing parts:
My main project (server-side) has over 100 classes across 30 files.
I used to use small libraries at the beginning but end up combining all
code into one monolithic library, because there is no "protected" access
modifier and therefore many classes need to be in the same library to see
each other.
At the same time, it is convinient to have large (over 1000 LoC in my case)
classes in their own files while keeping the main library file with 'part'
directives clean.
Maybe C# approach with named namespaces would be more appropriate?

Post by 'Bob Nystrom' via Dart Misc
https://github.com/dart-lang/dart_enhancement_proposals/blob/master/Meetings/2015-09-02%20Language%20Meeting.md
I mention this in the notes, but I want to call it out here. We're
starting to discuss this vague notion of "Dart 2.0". We don't know what
that means yet, and that means we'll be talking about all kinds of crazy
radical ideas which may or may not come to pass.
I think it's really important for us to speak freely, and it's also
important to do this in the open so we can involve all of you. But the cost
is that you may hear ideas that seem scary or disruptive, or ideas that
sound awesome but don't pan out. Try not to freak out and understand that
we're just brainstorming at this point.
Cheers!
- bob

[tatumizer-v0.2]

Expression "e as void", naturally, should return null.
Then, we can simulate comma operator (currently missing from dart):
var x = e1 as void ?? e2 as void ?? e3;
What a beautiful way to obfuscate your code! Will become an instant hit!

[Tristan Caron]

It also could be nice to have something like this:

Map<String, StreamSubscription> subscriptions;

// Do something then instead of

// subscriptions.values.forEach((sub) => sub.cancel());

subscriptions.values.forEach(::cancel());

[Gen]

Static checking for dropped futuresI do not know. I guess Florian knows
better.

Config-specific codeI do not understand.

Reified genericsDo what you like best and minimize regrets now if you
intend to use Dart for decades.
But what makes you interested in removing them ?

Type testsI am against the removal of "is".
It should not be up to the object to claim or lie about what it is.
Besides in addition to your concerns:
- To avoid stupid and crazy is why I like static typing.
- It is simpler to write "is Foo" then "isFoo()".
- "isFoo()" could be part of some interface that is not related to a type
test in that sense.

Type annotations on the rightDo what you like best and minimize regrets now
if you intend to use Dart for decades.
Why not "x : int = 5;" instead of "var x : int = 5;" ?

Static methodsI do not know about meta classes and their use in Dart.
Do what you like best and minimize regrets now if you intend to use Dart
for decades.

Constructor initialization listsI do not know.
Do what you like best and minimize regrets now if you intend to use Dart
for decades.

PartsPlease remove parts.

PrefixesI see no problem with prefixes.
Do what you like best and minimize regrets now if you intend to use Dart
for decades.

SymbolsI do not know. Are Enums not a good substitute ?

Fields final by defaultDo what you like best and minimize regrets now if
you intend to use Dart for decades.
But do not have both "var" and "val" in the language because I can imagine
that they are easily confounded.

Remove break, continue, and labels in favor of non-local returnsI see no
good reason to remove "break" and "continue".
I would keep them.

AssertI do not know. I have never used it.

Uniformity of referenceI do not know and I do not care much.

Removing newOf course.

Post by 'Bob Nystrom' via Dart Misc
https://github.com/dart-lang/dart_enhancement_proposals/blob/master/Meetings/2015-09-02%20Language%20Meeting.md
I mention this in the notes, but I want to call it out here. We're
starting to discuss this vague notion of "Dart 2.0". We don't know what
that means yet, and that means we'll be talking about all kinds of crazy
radical ideas which may or may not come to pass.
I think it's really important for us to speak freely, and it's also
important to do this in the open so we can involve all of you. But the cost
is that you may hear ideas that seem scary or disruptive, or ideas that
sound awesome but don't pan out. Try not to freak out and understand that
we're just brainstorming at this point.
Cheers!
- bob

[George Moschovitis]

While we are talking about Dart 2.0 stuff, how about adding a @protected
(and @private instead of '_') annotation, honored by DartAnalyzer etc?

[Jan Mostert]

+1 for @protected and @private annotations, not a fan of the "_" for
private variables.
Does Dart currently have any notion of protected variables / way to
simulate protected variables?


On Sat, 19 Sep 2015 at 06:57 George Moschovitis <

Post by 'Bob Nystrom' via Dart Misc
--
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

['Erik Ernst' via Dart Misc]

About '_' as a prefix for private names: An important property of this
approach is that both usages and declarations of names starting with '_'
(that is, both "server" and "client" code using a private member)
explicitly indicate their status as private, which makes the design fit
well with the actual semantics of Dart, especially production mode.

If you wish to replace the '_' prefix by an annotation like `@private` on
declarations of private members (and make the status as private invisible
at usage sites) then the runtime must traverse a significantly larger
amount of data when executing code that uses members, such that we avoid
incorrectly granting access to a private member from a non-privileged
position (e.g., for `@private`: from a different library). We would have to
perform these checks with all usages of every member with a name which is
used in any private declaration, which might in practice mean "all the
time" (and which will certainly include all accesses to private members).

The checks would need to investigate the receiver object, find information
about the relevant member (which calls for a certain amount of reflection),
check whether that member has been declared as private (or protected, or
whatever we have), and then check whether the constraints for the given
level of protection are satisfied, and then throw some exception if they
haven't.

The current ('_' based) approach, where renaming is used to make private
names inaccessible outside their library, allows the runtime to simply
perform the lookup without any privacy related checks at all. If the
requested member is not present then we get a `noSuchMethod`, and this also
applies in the case where library L1 uses a private name `_x` from library
L2: The name `_x` was renamed to something secret (everywhere in L2), so
the usage in L1 will not match, and hence there is no `_x` as seen from L1.

In summary, the `@private` approach is inherently costly if your runtime is
powerful enough to support dynamic execution (which is required for Dart),
so you may want to tolerate all the '_'s at usage sites after all, whether
or not you find them ugly. ;-)

Post by Jan Mostert
private variables.
Does Dart currently have any notion of protected variables / way to
simulate protected variables?
On Sat, 19 Sep 2015 at 06:57 George Moschovitis <

Post by 'Bob Nystrom' via Dart Misc
--
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

--
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

--
Erik Ernst - Google Danmark ApS
Skt Petri Passage 5, 2 sal, 1165 KÞbenhavn K, Denmark
CVR no. 28866984

[Jan Mostert]

Unless the @private annotation is just a transformer converting @private
test; to _test, then there's only a penalty at compile time.

--
Jan Vladimir Mostert
janvladimirmostert.com


On Mon, Sep 21, 2015 at 10:39 AM, 'Erik Ernst' via Dart Misc <

Post by 'Erik Ernst' via Dart Misc
About '_' as a prefix for private names: An important property of this
approach is that both usages and declarations of names starting with '_'
(that is, both "server" and "client" code using a private member)
explicitly indicate their status as private, which makes the design fit
well with the actual semantics of Dart, especially production mode.
declarations of private members (and make the status as private invisible
at usage sites) then the runtime must traverse a significantly larger
amount of data when executing code that uses members, such that we avoid
incorrectly granting access to a private member from a non-privileged
perform these checks with all usages of every member with a name which is
used in any private declaration, which might in practice mean "all the
time" (and which will certainly include all accesses to private members).
The checks would need to investigate the receiver object, find information
about the relevant member (which calls for a certain amount of reflection),
check whether that member has been declared as private (or protected, or
whatever we have), and then check whether the constraints for the given
level of protection are satisfied, and then throw some exception if they
haven't.
The current ('_' based) approach, where renaming is used to make private
names inaccessible outside their library, allows the runtime to simply
perform the lookup without any privacy related checks at all. If the
requested member is not present then we get a `noSuchMethod`, and this also
applies in the case where library L1 uses a private name `_x` from library
L2: The name `_x` was renamed to something secret (everywhere in L2), so
the usage in L1 will not match, and hence there is no `_x` as seen from L1.
is powerful enough to support dynamic execution (which is required for
Dart), so you may want to tolerate all the '_'s at usage sites after all,
whether or not you find them ugly. ;-)

Post by Jan Mostert
private variables.
Does Dart currently have any notion of protected variables / way to
simulate protected variables?
On Sat, 19 Sep 2015 at 06:57 George Moschovitis <

Post by 'Bob Nystrom' via Dart Misc
--
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

--
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

--
Erik Ernst - Google Danmark ApS
Skt Petri Passage 5, 2 sal, 1165 KÞbenhavn K, Denmark
CVR no. 28866984
--
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

['Erik Ernst' via Dart Misc]

How should that transformer (which would be a compiler transformation
implementing `@private` as syntactic sugar) be able to find the correct
name _applications_ (aka usages, client sites, lookups, as opposed to
declarations) using the name `test`, and transform them? For any given
usage of `test` it might resolve (at runtime) to the `test` which is
renamed to `_test`, or it might resolve to some other (public) `test` which
will not be renamed. We must know with certainty that renaming is performed
on the usages resolving to private members, and it is not performed on
usages resolving to public members, but we don't always know the result of
the dynamic lookups; and what do you want to do in the cases where it will
actually resolve to a private member in some cases and a public member in
other cases?

Post by Jan Mostert
test; to _test, then there's only a penalty at compile time.
--
Jan Vladimir Mostert
janvladimirmostert.com
On Mon, Sep 21, 2015 at 10:39 AM, 'Erik Ernst' via Dart Misc <

Post by 'Erik Ernst' via Dart Misc
About '_' as a prefix for private names: An important property of this
approach is that both usages and declarations of names starting with '_'
(that is, both "server" and "client" code using a private member)
explicitly indicate their status as private, which makes the design fit
well with the actual semantics of Dart, especially production mode.
declarations of private members (and make the status as private invisible
at usage sites) then the runtime must traverse a significantly larger
amount of data when executing code that uses members, such that we avoid
incorrectly granting access to a private member from a non-privileged
perform these checks with all usages of every member with a name which is
used in any private declaration, which might in practice mean "all the
time" (and which will certainly include all accesses to private members).
The checks would need to investigate the receiver object, find
information about the relevant member (which calls for a certain amount of
reflection), check whether that member has been declared as private (or
protected, or whatever we have), and then check whether the constraints for
the given level of protection are satisfied, and then throw some exception
if they haven't.
The current ('_' based) approach, where renaming is used to make private
names inaccessible outside their library, allows the runtime to simply
perform the lookup without any privacy related checks at all. If the
requested member is not present then we get a `noSuchMethod`, and this also
applies in the case where library L1 uses a private name `_x` from library
L2: The name `_x` was renamed to something secret (everywhere in L2), so
the usage in L1 will not match, and hence there is no `_x` as seen from L1.
is powerful enough to support dynamic execution (which is required for
Dart), so you may want to tolerate all the '_'s at usage sites after all,
whether or not you find them ugly. ;-)

Post by Jan Mostert
private variables.
Does Dart currently have any notion of protected variables / way to
simulate protected variables?
On Sat, 19 Sep 2015 at 06:57 George Moschovitis <

Post by George Moschovitis
While we are talking about Dart 2.0 stuff, how about adding a
@protected (and @private instead of '_') annotation, honored by
DartAnalyzer etc?
--
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

--
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

--
Erik Ernst - Google Danmark ApS
Skt Petri Passage 5, 2 sal, 1165 KÞbenhavn K, Denmark
CVR no. 28866984
--
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

--
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

--
Erik Ernst - Google Danmark ApS
Skt Petri Passage 5, 2 sal, 1165 KÞbenhavn K, Denmark
CVR no. 28866984

[George Moschovitis]

Personally, I am not interested in run-time privacy, '_' is OK for that.
I would like to use @protected, @private annotations at compile time, i.e.
in the IDE. Just a hint for Dart Analyzer.

-g.

[Alex Tatumizer]

Frankly, I don't understand the rationale for "protected" methods. If you
want something to be part of public interface- use public methods.
Otherwise make them private. The notion of something accessible only from
subclasses looks arbitrary. What about mixins? Can mixin access protected
method from its host? What about delegation?

Further, if you make anything "protected", Alice can always extend your
class with the only goal of effectively making your protected method freely
available to all her code, e.g. via a method with different name.

Anyway, if someone knows a use case for @protected, it can be done via
annotation for *public* method - this annotation can be interpreted by
human, and/or tools outside of compiler. For compiler, it's a normal public
method IMO.

P.S. See discussion here
<http://programmers.stackexchange.com/questions/162643/why-is-clean-code-suggesting-avoiding-protected-variables>

['John Messerly' via Dart Misc]

Post by Alex Tatumizer
Frankly, I don't understand the rationale for "protected" methods. If you
want something to be part of public interface- use public methods.
Otherwise make them private. The notion of something accessible only from
subclasses looks arbitrary. What about mixins? Can mixin access protected
method from its host? What about delegation?

Protected is about shaping APIs. The base class may want to provide methods
for the subclass implementer, but not feel they're necessary to expose to
the whole world.

Consider someone typing:

FancyButton f = ...;
f. <-- autocomplete popup here


It's helpful if the drop down list only shows the interesting methods. It
shouldn't show a bunch of methods that are only interesting to the
implementer of FancyButton.

Post by Alex Tatumizer
Further, if you make anything "protected", Alice can always extend your
class with the only goal of effectively making your protected method freely
available to all her code, e.g. via a method with different name.

That's totally fine. If Alice chooses to do that in a derived class, well,
it only affects the API of that derived class. "protected methods" are an
API design feature, not a security feature.

Post by Alex Tatumizer
annotation for *public* method - this annotation can be interpreted by
human, and/or tools outside of compiler. For compiler, it's a normal public
method IMO.
P.S. See discussion here
<http://programmers.stackexchange.com/questions/162643/why-is-clean-code-suggesting-avoiding-protected-variables>
--
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

[Alex Tatumizer]

Post by 'John Messerly' via Dart Misc
It's helpful if the drop down list only shows the interesting methods. It

shouldn't show a bunch of methods that are only interesting to the
implementer of FancyButton.
Fine, I concede that. But then, annotation @ptotected only affects tools,
not compiler. Support for it can be added in IDE at any time. I would also
welcome @rarelyUsed annotation for methods and classes. There are many
possible tool-specific annotations (e.g. intellij and eclipse each support
a bunch of their specific annotations for java) - @protected can be treated
as one of this kind.

[George Moschovitis]

Post by 'John Messerly' via Dart Misc
It's helpful if the drop down list only shows the interesting methods.

It shouldn't show a bunch of methods that are only interesting to the
implementer of FancyButton.
not compiler. Support for it can be added in IDE at any time. I would also
possible tool-specific annotations (e.g. intellij and eclipse each support
as one of this kind.

[George Moschovitis]

"protected methods" are an API design feature, not a security feature.

Exactly!

[Benjamin Strauß]

Will these language meetings also get public notes, now that the DEP and
languages meetings are two different events?

Post by 'Bob Nystrom' via Dart Misc
https://github.com/dart-lang/dart_enhancement_proposals/blob/master/Meetings/2015-09-02%20Language%20Meeting.md
I mention this in the notes, but I want to call it out here. We're
starting to discuss this vague notion of "Dart 2.0". We don't know what
that means yet, and that means we'll be talking about all kinds of crazy
radical ideas which may or may not come to pass.
I think it's really important for us to speak freely, and it's also
important to do this in the open so we can involve all of you. But the cost
is that you may hear ideas that seem scary or disruptive, or ideas that
sound awesome but don't pan out. Try not to freak out and understand that
we're just brainstorming at this point.
Cheers!
- bob

['John Messerly' via Dart Misc]

definitely

Post by Benjamin Strauß
Will these language meetings also get public notes, now that the DEP and
languages meetings are two different events?

Post by 'Bob Nystrom' via Dart Misc
https://github.com/dart-lang/dart_enhancement_proposals/blob/master/Meetings/2015-09-02%20Language%20Meeting.md
I mention this in the notes, but I want to call it out here. We're
starting to discuss this vague notion of "Dart 2.0". We don't know what
that means yet, and that means we'll be talking about all kinds of crazy
radical ideas which may or may not come to pass.
I think it's really important for us to speak freely, and it's also
important to do this in the open so we can involve all of you. But the cost
is that you may hear ideas that seem scary or disruptive, or ideas that
sound awesome but don't pan out. Try not to freak out and understand that
we're just brainstorming at this point.
Cheers!
- bob

--
You received this message because you are subscribed to the Google Groups
"Dart Core Development" group.
To unsubscribe from this group and stop receiving emails from it, send an

['Bob Nystrom' via Dart Misc]

Like John says, I certainly *hope* we share them widely.

But, at the same time, we haven't at all figured out any kind of venue or
format for them, so it isn't clear what will get written down. I think a
lot of this will end up being informal watercooler conversation kind of
stuff in the different offices.

Cheers!

– bob

On Mon, Sep 21, 2015 at 1:35 PM, 'John Messerly' via Dart Core Development <

Post by Günter Zöchbauer
definitely

Post by Benjamin Strauß
Will these language meetings also get public notes, now that the DEP and
languages meetings are two different events?

Post by 'Bob Nystrom' via Dart Misc
https://github.com/dart-lang/dart_enhancement_proposals/blob/master/Meetings/2015-09-02%20Language%20Meeting.md
I mention this in the notes, but I want to call it out here. We're
starting to discuss this vague notion of "Dart 2.0". We don't know what
that means yet, and that means we'll be talking about all kinds of crazy
radical ideas which may or may not come to pass.
I think it's really important for us to speak freely, and it's also
important to do this in the open so we can involve all of you. But the cost
is that you may hear ideas that seem scary or disruptive, or ideas that
sound awesome but don't pan out. Try not to freak out and understand that
we're just brainstorming at this point.
Cheers!
- bob

--
You received this message because you are subscribed to the Google Groups
"Dart Core Development" group.
To unsubscribe from this group and stop receiving emails from it, send an

--
You received this message because you are subscribed to the Google Groups
"Dart Core Development" group.
To unsubscribe from this group and stop receiving emails from it, send an

[Rasmus Eneman]

It would be interesting if they were recorded or performed via hangout.

On Mon, Sep 21, 2015 at 10:42 PM, 'Bob Nystrom' via Dart Core Development <

Post by 'Bob Nystrom' via Dart Misc
Like John says, I certainly *hope* we share them widely.
But, at the same time, we haven't at all figured out any kind of venue or
format for them, so it isn't clear what will get written down. I think a
lot of this will end up being informal watercooler conversation kind of
stuff in the different offices.
Cheers!
– bob
On Mon, Sep 21, 2015 at 1:35 PM, 'John Messerly' via Dart Core Development

Post by Günter Zöchbauer
definitely

Post by Benjamin Strauß
Will these language meetings also get public notes, now that the DEP and
languages meetings are two different events?

Post by 'Bob Nystrom' via Dart Misc
https://github.com/dart-lang/dart_enhancement_proposals/blob/master/Meetings/2015-09-02%20Language%20Meeting.md
I mention this in the notes, but I want to call it out here. We're
starting to discuss this vague notion of "Dart 2.0". We don't know what
that means yet, and that means we'll be talking about all kinds of crazy
radical ideas which may or may not come to pass.
I think it's really important for us to speak freely, and it's also
important to do this in the open so we can involve all of you. But the cost
is that you may hear ideas that seem scary or disruptive, or ideas that
sound awesome but don't pan out. Try not to freak out and understand that
we're just brainstorming at this point.
Cheers!
- bob

--
You received this message because you are subscribed to the Google
Groups "Dart Core Development" group.
To unsubscribe from this group and stop receiving emails from it, send

--
You received this message because you are subscribed to the Google Groups
"Dart Core Development" group.
To unsubscribe from this group and stop receiving emails from it, send an

--
You received this message because you are subscribed to the Google Groups
"Dart Core Development" group.
To unsubscribe from this group and stop receiving emails from it, send an

--
Rasmus Eneman