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.
On Wednesday, August 1, 2012 12:07:07 PM UTC-5, Bob Nystrom wrote:
> 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.
On Wednesday, August 1, 2012 12:07:07 PM UTC-5, Bob Nystrom wrote:
> 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.
> It's very cool that you guys are keeping the development process
> transparent. Keep up the good work.
> w. brian
> On Wednesday, August 1, 2012 12:07:07 PM UTC-5, Bob Nystrom wrote:
>> 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.
> 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.
> On Wed, Aug 1, 2012 at 10:43 AM, W. Brian Gourlie <bgour...@gmail.com>wrote:
>> It's very cool that you guys are keeping the development process
>> transparent. Keep up the good work.
>> w. brian
>> On Wednesday, August 1, 2012 12:07:07 PM UTC-5, Bob Nystrom wrote:
>>> 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.
On Wed, Aug 1, 2012 at 11:23 AM, Seth Ladd <sethl...@google.com> wrote:
> 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.
> On Wed, Aug 1, 2012 at 11:18 AM, Don Olmstead <don.j.olmst...@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.
>> On Wed, Aug 1, 2012 at 10:43 AM, W. Brian Gourlie <bgour...@gmail.com>wrote:
>>> It's very cool that you guys are keeping the development process
>>> transparent. Keep up the good work.
>>> w. brian
>>> On Wednesday, August 1, 2012 12:07:07 PM UTC-5, Bob Nystrom wrote:
>>>> 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.
On Wed, Aug 1, 2012 at 11:18 AM, Don Olmstead <don.j.olmst...@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.
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.
On Thu, Aug 2, 2012 at 9:41 AM, Bob Nystrom <rnyst...@google.com> wrote:
> On Wed, Aug 1, 2012 at 11:18 AM, Don Olmstead <don.j.olmst...@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.
On Fri, Aug 3, 2012 at 11:42 AM, Don Olmstead <don.j.olmst...@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?
> On Thu, Aug 2, 2012 at 9:41 AM, Bob Nystrom <rnyst...@google.com> wrote:
>> On Wed, Aug 1, 2012 at 11:18 AM, Don Olmstead <don.j.olmst...@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.
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.
On Tue, Aug 7, 2012 at 4:18 PM, Bob Nystrom <rnyst...@google.com> wrote:
> On Fri, Aug 3, 2012 at 11:42 AM, Don Olmstead <don.j.olmst...@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
>> On Thu, Aug 2, 2012 at 9:41 AM, Bob Nystrom <rnyst...@google.com> wrote:
>>> On Wed, Aug 1, 2012 at 11:18 AM, Don Olmstead <don.j.olmst...@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.
> 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.
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.
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.
On Sat, Aug 11, 2012 at 6:09 AM, Ladislav Thon <ladi...@gmail.com> wrote:
> 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.
On Tue, Aug 7, 2012 at 5:04 PM, Don Olmstead <don.j.olmst...@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.
> 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.
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.
>> 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?
On Wednesday, August 15, 2012 12:49:37 PM UTC-7, Bob Nystrom wrote:
> On Mon, Aug 13, 2012 at 9:57 PM, Eric Leese <le...@google.com<javascript:> > > 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.
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.
On Wed, Aug 15, 2012 at 7:17 PM, Ross Smith <ross.m.sm...@gmail.com> wrote:
> >> 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?
> On Wednesday, August 15, 2012 12:49:37 PM UTC-7, Bob Nystrom wrote:
>> 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.
On Wednesday, August 15, 2012 7:25:30 PM UTC-7, Seth Ladd wrote:
> 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
> On Wed, Aug 15, 2012 at 7:17 PM, Ross Smith <ross.m...@gmail.com<javascript:> > > wrote:
>> >> 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?
>> On Wednesday, August 15, 2012 12:49:37 PM UTC-7, Bob Nystrom wrote:
>>> 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.
> 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."
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.
On 17 August 2012 05:25, Eric Leese <le...@google.com> wrote:
>> 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."
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."
