Notes from 7/30 language design meeting

[Bob Nystrom]

Here's my notes from this Monday's meeting. I'm not good at taking notes while people talk, so let me know if anything needs clarification. :)

New getter and setter syntax

We heard lots of feedback from users that they don't like the new setter syntax. Instead, we'll keep the current syntax, so no more "=" after the setter name. Instead, just:

    set blah(value) => ...

We will go ahead with the getter changes (removing ()).

Ryan Dahl's thread on misc

Go's syntax for loops and stuff versus Dart's is really just a matter of taste. Dart tries harder to be similar to other languages to make it easier for users to get comfortable and to make porting code easier.

We talked a bit about optional semicolons. There is some vague worry that we could end up with some of the problems that JavaScript has. For now, we don't have any plans to make them optional. But, since doing so wouldn't be a breaking change, we can always decide to do that later.

Lots of people don't like "&" for export. Message received: we'll do something different. Not sure what yet.

Parameter lists

We have a design for a modification to parameter lists that lets you define optional positional parameters that are not also named. Sometime soon, I'll see if I can get a document out that explains it.

We won't know how well this works until we port code to use it. We aren't sure how many of the current APIs are using optional parameters positionally or by name. So we'll try it out and see if we need to iterate on it again.

Cascades

Are implemented everywhere now (VM, dart2js, editor). Users can start playing with them!

Non-const statics

These are coming soon. This means you'll be able to initialize top-level final variables, and static final fields using non-const initializers. They will be lazily evaluated the first time the variable is accessed.

As always, thank you all very much for the constructive, detailed feedback. As you can see, it directly affects the course of the language. Dart wouldn't be what it is without you.

Cheers!

- bob

[W. Brian Gourlie]

It's very cool that you guys are keeping the development process transparent.  Keep up the good work.

w. brian

[Eric J. Smith]

This is awesome!  Thanks for listening!

On Wednesday, August 1, 2012 12:07:07 PM UTC-5, Bob Nystrom wrote:

[Don Olmstead]

Thanks for the update Bob!

What was the consensus on doing the C# blocked getter/setter? I still think that's the best way to do it as it simplifies the setters greatly.

--
Consider asking HOWTO questions at Stack Overflow: http://stackoverflow.com/tags/dart
 
 

[Seth Ladd]

Hi Don,

I remember there was a bit of a concern that there are cases where the getter type and the setter return type might be different.

[Don Olmstead]

Yep I remember those conversations I just think they're such a corner case that it shouldn't be used as a reason to make the syntax poorer.

So if you want that behavior var should be the type.

var foo

{
   get => _foo;

   set

   {
      if (foo is String)
      {
         // Do something
      }
      else if (foo is ...)
      {

      }

     _foo = value;
  }
}

As I've said the setter syntax is clearer, and you have one point of entry to document. Both big wins.

[Bob Nystrom]

On Wed, Aug 1, 2012 at 11:18 AM, Don Olmstead <don.j.o...@gmail.com> wrote:

Thanks for the update Bob!

What was the consensus on doing the C# blocked getter/setter? I still think that's the best way to do it as it simplifies the setters greatly.

We didn't discuss that option. I can try to bring it up, but I believe Lars and Gilad are of the opinion that getters and setters should be defined separately, for a couple of reasons:

1. Like Seth pointed it, it allows their types to vary. (Though, personally, I think that's a negative anyway.)

2. It's closer to Dart's internal semantics where getters and setters are just separate methods that aren't related to each other.

3. It makes it clearer that you can do things like override a getter without overriding the corresponding setter or vice versa.

- bob

[Don Olmstead]

Thanks for bringing it up Bob. Its not the end of the world if they keep the getter/setter stuff as is, but I personally think the semantics are helpful when programming. Its one of the things I really liked when I did some C# work, and wished was around when programming in C++, so apologies if I'm harping on this a bunch.

[Bob Nystrom]

On Fri, Aug 3, 2012 at 11:42 AM, Don Olmstead <don.j.o...@gmail.com> wrote:

Thanks for bringing it up Bob. Its not the end of the world if they keep the getter/setter stuff as is, but I personally think the semantics are helpful when programming. Its one of the things I really liked when I did some C# work, and wished was around when programming in C++, so apologies if I'm harping on this a bunch.

I'm not a huge fan of the current declaration syntax either, so I don't mind you harping. However, Dart's getters and setters do have the semantics that I like. Is there something you see missing there?

- bob

[Don Olmstead]

Hey Bob,

I've probably mangled my terms here. The implied meaning of the syntax of properties chosen in Dart is what I was taking issue with. Semantics was probably not the best word to use there, since this is still a syntax issue, but let me explain what I meant.

So with the C# style declaration its blocked thus showing there's an association between the getter and setter. As I've mentioned having value passed implicitly to the setter, and having a definitive place to comment are big wins from this declaration style. There's also the weirdness for those who are typing everything that the get has a return type but the set does not, so the pairing of the two looks odd.

It also bugs me that with how they're declared currently resembles how a method is declared. By not having () or (Foo value) within the getter/setter to me there is an implication that this is not a method but something different. Yes it might just be syntatic sugar around a getFoo/setFoo combo under the hood, but I feel as though having a property syntax that is different reinforces that they are something semantically different than a method.

[Ladislav Thon]

It also bugs me that with how they're declared currently resembles how a method is declared. By not having () or (Foo value) within the getter/setter to me there is an implication that this is not a method but something different. Yes it might just be syntatic sugar around a getFoo/setFoo combo under the hood, but I feel as though having a property syntax that is different reinforces that they are something semantically different than a method.

But they are not.

LT

[Don Olmstead]

I know under the hood they aren't, hence the syntatic sugar comment. If you look at the following for examples of the syntax used for properties used in different language you'll see some hide this fact more than others.

http://en.wikipedia.org/wiki/Property_(programming)#Example_syntax 

C# has the syntax that hides this fact the best, which I like because a property is emulating a field. It also has the most concise syntax for properties.

If you're going to steal, steal from the best.

--

[Bob Nystrom]

On Tue, Aug 7, 2012 at 5:04 PM, Don Olmstead <don.j.o...@gmail.com> wrote:

Hey Bob,

I've probably mangled my terms here. The implied meaning of the syntax of properties chosen in Dart is what I was taking issue with. Semantics was probably not the best word to use there, since this is still a syntax issue, but let me explain what I meant.

So with the C# style declaration its blocked thus showing there's an association between the getter and setter. As I've mentioned having value passed implicitly to the setter, and having a definitive place to comment are big wins from this declaration style. There's also the weirdness for those who are typing everything that the get has a return type but the set does not, so the pairing of the two looks odd.

 I agree. I like C#'s syntax too.

 

It also bugs me that with how they're declared currently resembles how a method is declared.

This is actually a feature from the perspective of the language designers, I think. In Dart, getters and setters are just methods, and there's no actual relationship between a getter and setter that happen to have the same name. They're just two different unrelated methods.

 

By not having () or (Foo value) within the getter/setter to me there is an implication that this is not a method but something different. Yes it might just be syntatic sugar around a getFoo/setFoo combo under the hood, but I feel as though having a property syntax that is different reinforces that they are something semantically different than a method.

That's the balance they are trying to strike. Under the hood, methods aren't different from methods. But the syntax for using them is. So the declaration syntax has to try to span those two facts. It's tricky.

- bob

[Eric Leese]

This is actually a feature from the perspective of the language designers, I think. In Dart, getters and setters are just methods, and there's no actual relationship between a getter and setter that happen to have the same name. They're just two different unrelated methods.

It's the word "just" that I have trouble with.  Can we at least agree that we'd never let a coworker write a getter and setter that actually were unrelated to each other? 

That's the balance they are trying to strike. Under the hood, methods aren't different from methods. But the syntax for using them is. So the declaration syntax has to try to span those two facts. It's tricky.

What they are under the hood is an irrelevant implementation detail.  I'd imagine that's what they are under the hood in any language.  But there is more to the meaning of language constructs than what they mean to the compiler; language features are important for what they help us communicate to other programmers and as tools for thinking about the problems we're solving.  And properties have a different meaning from methods.  If you are writing code that is best thought of as a method, you should implement it as a method.  A property is best thought of as something like a field, but more flexible, and the syntax for using getters/setters reflects that; it isn't "balance" to make the syntax for defining them suggest something else.  Granted, a look around the Dart API suggests that the Dart team hasn't yet reached a consensus on what the difference is between properties and methods, but I'd imagine a lot of the API designers aren't used to programming in languages with properties.

I don't mind the syntax so much as the mindset behind it -- after all, if properties are "just two different unrelated methods," well then it makes perfect sense to propose that they should have distinct names, and I can imagine other proposals I wouldn't like following from that logic.  I actually think the Dart syntax looks cleaner when only defining a getter, but C# looks better when defining both.

[Bob Nystrom]

On Mon, Aug 13, 2012 at 9:57 PM, Eric Leese <le...@google.com> wrote:

This is actually a feature from the perspective of the language designers, I think. In Dart, getters and setters are just methods, and there's no actual relationship between a getter and setter that happen to have the same name. They're just two different unrelated methods.

It's the word "just" that I have trouble with.  Can we at least agree that we'd never let a coworker write a getter and setter that actually were unrelated to each other? 

We definitely agree that that's asking for trouble, but there are related things you could do that or reasonable. For example, you could define a getter in one class and add a setter in a subclass. Or have a field in a base class, and override its setter in a subclass to do some additional validation.

 

That's the balance they are trying to strike. Under the hood, methods aren't different from methods. But the syntax for using them is. So the declaration syntax has to try to span those two facts. It's tricky.

What they are under the hood is an irrelevant implementation detail.  I'd imagine that's what they are under the hood in any language.

No, in C#, properties are distinct from both fields and methods. This is visible in the reflection system and affects stuff that uses reflection. For example, if you ever used the PropertyGrid class in C#, it only showed the properties of your class, not its fields.

 

 But there is more to the meaning of language constructs than what they mean to the compiler; language features are important for what they help us communicate to other programmers and as tools for thinking about the problems we're solving.  And properties have a different meaning from methods.  If you are writing code that is best thought of as a method, you should implement it as a method.  A property is best thought of as something like a field, but more flexible, and the syntax for using getters/setters reflects that; it isn't "balance" to make the syntax for defining them suggest something else.

I agree. We have properties in Dart in part because they let us communicate something more clearly than just method syntax allows.

 

 Granted, a look around the Dart API suggests that the Dart team hasn't yet reached a consensus on what the difference is between properties and methods, but I'd imagine a lot of the API designers aren't used to programming in languages with properties.

This is true, although I believe consensus is emerging. The main problem is that much of the corelib is long overdue for an overhaul. Things like the collection types haven't been touched for almost a year.

 

I don't mind the syntax so much as the mindset behind it -- after all, if properties are "just two different unrelated methods,"

I think this mindset stems partially from the fact that many on the Dart team have a Smalltalk background where that is literally true. Smalltalk doesn't have getters and setters, just methods. There's no distinction between a property accessor method, and a method that just doesn't take any arguments.

Cheers!

- bob

[Ross Smith]

>>  Things like the collection types haven't been touched for almost a year. 

hmm, yeah - if it isn't too brazen of me to ask, what's up with that?!  I remember there was a lot of talk regarding that 6 months or so ago and we haven't heard much about it of late?

[Seth Ladd]

Hi Ross,

It didn't make sense to approach the libraries until we had a more stable language base. The M1 language spec will provide the foundation for future library refactorings.

Some good news in this area: the team is hard at work unifying the library files across the VM and dart2js. A common code base is an important first step. This is another prereq before we can perform library refactorings.

Hope that helps,

Seth

[Ross Smith]

Thanks for the update Seth - that is what I suspected but it is nice to hear some official word on it :)  Keep up the good work!

cheers

[Eric Leese]

No, in C#, properties are distinct from both fields and methods. This is visible in the reflection system and affects stuff that uses reflection. For example, if you ever used the PropertyGrid class in C#, it only showed the properties of your class, not its fields.

But these are choices of the language and of the reflection API.  They aren't so different to the runtime; the MSIL instructions for calling methods are the same used for calling getters and setters, but different from the ones used to access fields.

Dart improves on C# by eliminating the distinction between fields and properties when it comes to overrides; C# has dealt with this unhelpful distinction by evolving to make fields unnecessary.  What's weird about Dart is the choice to erase the distinction between fields and properties when it comes to use and overrides while maintaining a distinction between properties and methods, but at the same time blurring the distinction between properties and methods in the reflection API while making properties distinct from fields.

  

 Granted, a look around the Dart API suggests that the Dart team hasn't yet reached a consensus on what the difference is between properties and methods, but I'd imagine a lot of the API designers aren't used to programming in languages with properties.

This is true, although I believe consensus is emerging. The main problem is that much of the corelib is long overdue for an overhaul. Things like the collection types haven't been touched for almost a year.

Good to hear the issue hasn't dropped off the radar.  I'd suggest the golden rule for properties versus methods should be, "Is it obvious from the name you've chosen that this is a method, not a property?  If not, it's a property.  If in spite of this you still think it should be a method, change the name." 

[Christopher Wright]

Good points. Dart could choose to treat all fields as properties in the reflection API; the main difference that I can think of is if a final field can be set with reflection. You can't generate a meaningful setter for a property in the general case.

It would be annoying, though, to have two types for every field. On the other hand, that's what properties currently give us.

[Bob Nystrom]

On Thu, Aug 16, 2012 at 10:25 PM, Eric Leese <le...@google.com> wrote:

Good to hear the issue hasn't dropped off the radar.  I'd suggest the golden rule for properties versus methods should be, "Is it obvious from the name you've chosen that this is a method, not a property?  If not, it's a property.  If in spite of this you still think it should be a method, change the name." 

Actually, now that I think of it, this is actually already documented in the style guide: http://www.dartlang.org/articles/style-guide/#do-use-a-getter-for-operations-that-conceptually-access-a-property

Cheers!

- bob