9/2 language meeting notes

[Bob Nystrom]

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]

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

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

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

[Patrice Chalin]

+1 on all counts!

--
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 email to core-dev+u...@dartlang.org.

--

Patrice   

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

--

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

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

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

--

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?

[Mark H]

Agree completely!

[Bob Nystrom]

On Thu, Sep 3, 2015 at 3:03 PM, Don Olmstead <don.j.o...@gmail.com> wrote:

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

[Bob Nystrom]

On Thu, Sep 3, 2015 at 3:10 PM, Don Olmstead <don.j.o...@gmail.com> wrote:

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. 

[John Messerly]

On Thu, Sep 3, 2015 at 3:07 PM, Kasper Peulen <kasper...@gmail.com> wrote:

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

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

Type annotations on the right

+10000 on this. 

+ 1 on all counts.And pls make semicolon optional,fix issue #10018 (Non-Uri Imports) in dart 2.0. Then dart's syntax will be cleaner and more consistent.

在 2015年9月4日星期五 UTC+8上午5:08:22，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

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

[Lasse R.H. Nielsen]

On Fri, Sep 4, 2015 at 12:24 AM, 'Bob Nystrom' via Dart Misc <mi...@dartlang.org> wrote:

On Thu, Sep 3, 2015 at 3:03 PM, Don Olmstead <don.j.o...@gmail.com> wrote:

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.

 

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 - l...@google.com  

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

[Lasse R.H. Nielsen]

On Fri, Sep 4, 2015 at 7:57 AM, Lasse R.H. Nielsen <l...@google.com> wrote:

On Fri, Sep 4, 2015 at 12:24 AM, 'Bob Nystrom' via Dart Misc <mi...@dartlang.org> wrote:

On Thu, Sep 3, 2015 at 3:03 PM, Don Olmstead <don.j.o...@gmail.com> wrote:

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

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

[Brian Slesinsky]

On Thu, Sep 3, 2015 at 9:47 PM, Arron Washington <l33...@gmail.com> wrote:

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

[Günter Zöchbauer]

+1

[Lasse R.H. Nielsen]

On Fri, Sep 4, 2015 at 10:09 AM, Günter Zöchbauer <gzo...@gmail.com> wrote:

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.

 

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.

 

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.

 

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.

 

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?

 

+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

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

On Thursday, September 3, 2015 at 11:08:22 PM UTC+2, Bob wrote:

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

I 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".

Parts

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

Yes please! To make it explicit what are mutable and will be changed should make the code easier to read.

Uniformity of reference

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

--
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 email to core-dev+u...@dartlang.org.

--

Rasmus Eneman

[Günter Zöchbauer]

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

On Fri, Sep 4, 2015 at 10:09 AM, Günter Zöchbauer <gzo...@gmail.com> wrote:

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.

 

 

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.

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.

 

 

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?

 

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

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

[Günter Zöchbauer]

On Friday, September 4, 2015 at 11:07:10 AM UTC+2, Robert Åkerblom-Andersson wrote:

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.

[kc]

On Thursday, September 3, 2015 at 11:35:56 PM UTC+1, John Messerly wrote:

On Thu, Sep 3, 2015 at 3:07 PM, Kasper Peulen <kasper...@gmail.com> wrote:

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

[Patrice Chalin]

On Fri, Sep 4, 2015 at 2:36 AM, Günter Zöchbauer <gzo...@gmail.com> wrote:

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

On Fri, Sep 4, 2015 at 10:09 AM, Günter Zöchbauer <gzo...@gmail.com> wrote:

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

[kc]

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

On Fri, Sep 4, 2015 at 12:24 AM, 'Bob Nystrom' via Dart Misc <mi...@dartlang.org> wrote:

On Thu, Sep 3, 2015 at 3:03 PM, Don Olmstead <don.j.o...@gmail.com> wrote:

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.

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.

 

 

[kc]

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

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.

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

K. 

[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
gue...@gzoechbauer.com
+43 (699) 10 18 87 15

[Patrice Chalin]

On Fri, Sep 4, 2015 at 6:53 AM, Günter Zöchbauer <gue...@gzoechbauer.com> wrote:

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

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]

--

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 email to core-dev+u...@dartlang.org.

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

[Rich Eakin]

On Thursday, September 3, 2015 at 6:24:50 PM UTC-4, Bob wrote:

On Thu, Sep 3, 2015 at 3:03 PM, Don Olmstead <don.j.o...@gmail.com> wrote:

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

 

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

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


 

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

[Florian Loitsch]

On Fri, Sep 4, 2015 at 6:47 AM, Arron Washington <l33...@gmail.com> wrote:

> 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 email to misc+uns...@dartlang.org.

--

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

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

[Bob Nystrom]

On Thu, Sep 10, 2015 at 11:24 AM, Mike <michael.s...@gmail.com> wrote:

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.

 

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.

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

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

--

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]

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]

On Fri, Sep 11, 2015 at 4:52 AM, tatumizer-v0.2 <tatu...@gmail.com> wrote:

> "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).

 

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

[Günter Zöchbauer]

I'm in :)

[Anders Holmgren]

+1

--

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

> I'd introduce ranges instead, then you could write:

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

[Randal L. Schwartz]

"You can't just assign the future to a thrown away variable since then
you get an unused variable hint. So we'll need to come up with some
little mechanism for this."

How about a method called on the future?

theFuture.discard()
--
Randal L. Schwartz - Stonehenge Consulting Services, Inc. - +1 503 777 0095
<mer...@stonehenge.com> <URL:http://www.stonehenge.com/merlyn/>
Perl/Unix consulting, Technical writing, Comedy, etc. etc.
Still trying to think of something clever for the fourth line of this .sig

[tatumizer-v0.2]

theFuture as void;

currently, it's not a valid expression, not clear why. 

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

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?

пятница, 4 сентября 2015 г., 1:08:22 UTC+4 пользователь Bob написал:

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.

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

 

[Andrew Skalkin]

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.

[tatumizer-v0.2]

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

[Lasse R.H. Nielsen]

On Sun, Sep 13, 2015 at 5:56 PM, tatumizer-v0.2 <tatu...@gmail.com> wrote:

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

[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());

[Günter Zöchbauer]

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

On Sun, Sep 13, 2015 at 5:56 PM, tatumizer-v0.2 <tatu...@gmail.com> wrote:

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

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

[Bob Nystrom]

On Fri, Sep 11, 2015 at 6:33 PM, tatumizer-v0.2 <tatu...@gmail.com> wrote:

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]

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

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

Thanks!

- bob

[tatumizer-v0.2]

@Lasse:

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

On Mon, Sep 14, 2015 at 8:05 PM, tatumizer-v0.2 <tatu...@gmail.com> wrote:

@Lasse:
> 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 (e.g. with @override annotation)?

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

[Bob Nystrom]

On Tue, Sep 15, 2015 at 1:21 AM, 'Lasse R.H. Nielsen' via Dart Misc <mi...@dartlang.org> wrote:

On Mon, Sep 14, 2015 at 8:05 PM, tatumizer-v0.2 <tatu...@gmail.com> wrote:

@Lasse:
> 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.

 

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.

 

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.

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.

вторник, 15 сентября 2015 г., 19:56:58 UTC+4 пользователь Bob написал:

[Bob Nystrom]

On Tue, Sep 15, 2015 at 2:28 PM, Alexey Knyazev <lexa.k...@gmail.com> wrote:

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, ...];

 

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

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

среда, 16 сентября 2015 г., 1:48:13 UTC+4 пользователь Bob написал:

среда, 16 сентября 2015 г., 1:48:13 UTC+4 пользователь Bob написал:

[Lasse R.H. Nielsen]

On Tue, Sep 15, 2015 at 5:56 PM, 'Bob Nystrom' via Dart Misc <mi...@dartlang.org> wrote:

On Tue, Sep 15, 2015 at 1:21 AM, 'Lasse R.H. Nielsen' via Dart Misc <mi...@dartlang.org> wrote:

On Mon, Sep 14, 2015 at 8:05 PM, tatumizer-v0.2 <tatu...@gmail.com> wrote:

@Lasse:
> 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.

 

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

 

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.

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

-- 

[Gen]

Static checking for dropped futures

I do not know. I guess Florian knows better.

Config-specific code

I do not understand.

Reified generics

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

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

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

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

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

Parts

Please remove parts.

Prefixes

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

Symbols

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

Fields final by default

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

I see no good reason to remove "break" and "continue".
I would keep them.

Assert

I do not know. I have never used it.

Uniformity of reference

I do not know and I do not care much.

Removing new

Of course.

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

Am Freitag, 11. September 2015 15:31:11 UTC+2 schrieb tatumizer-v0.2:

> I'd introduce ranges instead, then you could write:

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

[Bob Nystrom]

On Tue, Sep 15, 2015 at 11:24 PM, 'Lasse R.H. Nielsen' via Dart Misc <mi...@dartlang.org> wrote:

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.

 

 

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.

 

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.

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.

 

The member is only part of the class, not its interface - implementing the class won't include it, but extending it will.

+1.

 

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.

 

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]

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

--

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

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

[Gen]

Am Mittwoch, 16. September 2015 22:59:44 UTC+2 schrieb Jan Vladimir Mostert:

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

Removing new
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.
 

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]

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

[Anders Holmgren]

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

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

[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

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

[Günter Zöchbauer]

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

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.

[Günter Zöchbauer]

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

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.

[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

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

[Jan Mostert]

I agree, for fields this would be cumbersome but it would be convenient for variables and parameters.

+1 

--
Jan Vladimir Mostert
janvladimirmostert.com

[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 <george.mo...@gmail.com> wrote:

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

[Erik Ernst]

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.  ;-)

--

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

[Erik Ernst]

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?

[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

[John Messerly]

On Mon, Sep 21, 2015 at 10:10 AM, Alex Tatumizer <tatu...@gmail.com> wrote:

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.

 

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.

 

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

[Alex Tatumizer]

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

Yes, @protected / @private targets only DartAnalyzer, not the run-time.

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

[John Messerly]

definitely

--
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 email to core-dev+u...@dartlang.org.

[Bob Nystrom]

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